Amazon EKS API サーバーに接続したときに表示される「サーバーにログインする必要があります (不正) というエラーを解決する方法を教えてください。
kubectl コマンドを使用して、Amazon Elastic Kubernetes Service (Amazon EKS) アプリケーションプログラミングインターフェイス (API) サーバーに接続しています。「エラー: サーバーへのログインが必要です (不正)」というメッセージが表示されました。
簡単な説明
このエラーは、kubectl に設定されている AWS Identity and Access Management (IAM) エンティティが Amazon EKS によって認証されていない場合に発生します。
Amazon EKS クラスターへのアクセスは、使用する IAM エンティティ (ユーザーまたはロール) に基づいて、認証され、承認されます。ここでは、次の点を確認してください:
- IAM ユーザーまたはロールを使用するように kubectl ツールを設定した。
- IAM エンティティは aws-auth ConfigMap にマッピングされる。
この問題を解決するには、ユースケースに応じて以下のいずれかのセクションの手順を完了する必要があります:
- クラスター作成者の場合
- クラスター作成者ではない場合
解決策
AWS コマンドラインインターフェイス (AWS CLI) のコマンドの実行中にエラーが発生した場合は、実行しているのが最新バージョンの AWS CLI であることを確認してください。
クラスター作成者の場合
あなたの IAM エンティティが Amazon EKS クラスターの作成に使用された場合は、あなたがクラスター作成者です。
1.Amazon CloudWatch Logs Insights で次のクエリを実行して、クラスター作成者の ARN を特定します。
まず、Amazon EKS クラスターのロググループ (例:/aws/eks/my-cluster/cluster) を選択します。次のクエリを実行します。
fields @logstream, @timestamp, @message | sort @timestamp desc | filter @logStream like /authenticator/ | filter @message like "username=kubernetes-admin" | limit 50
**注:**Amazon EKS 認証ログは必ず有効にしてください。
このクエリは、クラスター作成者としてマッピングされた IAM エンティティを返します:
@message time="2022-05-26T18:55:30Z" level=info msg="access granted" arn="arn:aws:iam::123456789000:user/testuser" client="127.0.0.1:57586" groups="[system:masters]" method=POST path=/authenticate uid="aws-iam-authenticator:123456789000:AROAFFXXXXXXXXXX" username=kubernetes-admin
2. 必ずクラスター作成者の IAM エンティティを使用して AWS CLI を設定しておいてください。IAM エンティティがシェル環境で AWS CLI 用に設定されているかどうかを確認するには、次のコマンドを実行します:
$ aws sts get-caller-identity
このコマンドは、特定のプロファイルを使用して実行することもできます。
$ aws sts get-caller-identity --profile MY-PROFILE
出力で、AWS CLI 用に設定された IAM エンティティの Amazon リソースネーム (ARN) が返ります。
例:
{ "UserId": "XXXXXXXXXXXXXXXXXXXXX", "Account": "XXXXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser" }
返された IAM エンティティがクラスター作成者の IAM エンティティと一致することを確認します。返された IAM エンティティがクラスター作成者でない場合は、クラスター作成者の IAM エンティティを使用するように AWS CLI 設定を更新します。
3. 次のコマンドを使用して、kubeconfig ファイルを更新するか、生成します。
$ aws eks update-kubeconfig --name eks-cluster-name --region aws-region
注:
- eks-cluster-name は、使用しているクラスターの名前に置き換えます。
- aws-region は、使用している AWS リージョンの名前に置き換えます。
AWS CLI プロファイルを指定するには、次のコマンドを実行します。
$ aws eks update-kubeconfig --name eks-cluster-name —region aws-region —profile my-profile
注:
- eks-cluster-name は、使用しているクラスターの名前に置き換えます。
- aws-region は、使用しているリージョンの名前に置き換えます。
- my-profile は、使用しているプロファイルの名前に置き換えます。
4.次のコマンドを実行して、**kubeconfig ** ファイルが更新されたことを確認します。
$ kubectl config view --minify
5.次のコマンドを実行して、IAM エンティティが認証され、EKS クラスターにアクセスできることを確認します。
$ kubectl get svc
次の例のような出力が表示されます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 77d
クラスター作成者ではない場合
あなたの IAM エンティティがクラスターの作成に使用されなかった場合、あなたはクラスターの作成者ではありません。その場合は、IAM エンティティを aws-auth ConfigMap にマッピングして、クラスターへのアクセスを許可する必要があります。
1. 必ず IAM エンティティで AWS CLI を設定しておいてください。シェル環境で AWS CLI 用に設定された IAM エンティティを確認するには、次のコマンドを実行します。
$ aws sts get-caller-identity
このコマンドは、特定のプロファイルを使用して実行することもできます。
$ aws sts get-caller-identity --profile my-profile
出力で、AWS CLI 用に設定された IAM エンティティの ARN が返ります。
例:
{ "UserId": "XXXXXXXXXXXXXXXXXXXXX", "Account": "XXXXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser" }
返された IAM エンティティが、使用している IAM エンティティであることを確認します。返された IAM エンティティがクラスターとのやり取りに使用されたものでない場合は、まず AWS CLI 設定を更新して正しい IAM エンティティを使用してください。次に、kubectl を使用してクラスターへのアクセスを再試行します。問題が解決しない場合は、手順 2 に進んでください。
2. 返された IAM エンティティがクラスター作成者でない場合は、IAM エンティティを aws-auth ConfigMap に追加します。これにより、その IAM エンティティからクラスターにアクセスできます。
aws-auth ConfigMap を変更できるのは、クラスター管理者のみです。そのため、次のいずれかを実行してください。
- 「クラスター作成者」セクションの手順に従って、クラスター作成者の IAM エンティティを使用してクラスターにアクセスします。
- クラスター管理者にこのアクションの実行を依頼してください。
次のコマンドを実行して、IAM エンティティが aws-auth ConfigMap にあるかどうかを確認してください。
eksctl get iamidentitymapping --cluster cluster-name
-or-
kubectl describe configmap aws-auth -n kube-system
IAM エンティティが aws-auth ConfigMap にある場合は、ステップ 3 にスキップできます。
以下のコマンドを実行して、IAM エンティティを自動的にマッピングします:
eksctl create iamidentitymapping \ --cluster $CLUSTER-NAME \ --region $REGION \ --arn arn:aws:iam::XXXXXXXXXXXX:user/testuser \ --group system:masters \ --no-duplicate-arns \ --username admin-user1
または、aws-auth ConfigMap を編集して、IAM エンティティを手動でマッピングすることも可能です。
$ kubectl edit configmap aws-auth --namespace kube-system
IAM ユーザーを追加するには、IAM ユーザー ARN を mapUsersに追加します。
例:
mapUsers: | - userarn: arn:aws:iam::XXXXXXXXXXXX:user/testuser username: testuser groups: - system:masters
IAM ロールを追加するには、IAM ロール ARN を mapRoleに追加します。
例:
mapRoles: | - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testrole username: testrole groups: - system:masters
重要:
- IAM ロールはパスなしでマッピングしてください。rolearn のパス要件の詳細については、「IAM のトラブルシューティング」の「aws-auth ConfigMap がクラスターへのアクセスを許可しない」セクションを参照してください。
- AWS IAM アイデンティティセンター (AWS シングルサインオンの後継) の IAM ロールに rolearn を指定するには、ロール ARN からパス「/aws-reserved/sso.amazonaws.com/REGION」を削除します。そうしないと、ConfigMap のエントリで有効なユーザーとして承認されません。
- system:masters グループでは、スーパーユーザーは任意のリソースに任意のアクションを実行できます。詳細については、「Default roles and role bindings」を参照してください。このユーザーのアクセスを制限するには、Amazon EKS ロールとロールバインディングリソースを作成します。Amazon EKS コンソールでリソースを表示するユーザーの制限付きアクセスの例については、「必要なアクセス許可」のステップ 2 と 3 に従ってください。
3. 次のコマンドを実行して、kubeconfig ファイルを更新するか生成します。ステップ 1 で返された IAM エンティティで AWS CLI が設定されていることを確認します。
$ aws eks update-kubeconfig --name eks-cluster-name --region aws-region
注:
- eks-cluster-name は、使用しているクラスターの名前に置き換えます。
- aws-region は、使用している AWS リージョンの名前に置き換えます。
このコマンドは、特定のプロファイルを使用して実行することもできます。
$ aws eks update-kubeconfig --name eks-cluster-name —region aws-region —profile my-profile
注:
- eks-cluster-name は、使用しているクラスターの名前に置き換えます。
- aws-region は、使用している AWS リージョンの名前に置き換えます。
- my-profile は、使用しているプロファイルの名前に置き換えます。
4.次のコマンドを実行して、**kubeconfig ** ファイルが更新されたことを確認します。
$ kubectl config view --minify
5.IAM ユーザーまたはロールが認証されたことを確認するには、クラスターに再度アクセスします。たとえば、次のコマンドを実行すれば、エラーが解決されたことを確認できます。
$ kubectl get svc
次の例のような出力が表示されます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 77d
その他のトラブルシューティングのヒント
それでもエラーが解決されない場合は、次のトラブルシューティングのヒントを参考にして問題を特定してください。
kubectl コマンドを実行すると、リクエストが Amazon EKS クラスター API サーバーに送信されます。次に、Amazon EKS 認証システムで、このリクエストの認証が試みられます。そのため、CloudWatch の EKS 認証ログを確認して問題を特定してください。
1.Amazon EKS クラスターのログ記録を有効にしておいてください。。
2.CloudWatch Logs Insights を開きます。
3.クラスターのロググループを選択します。例:「/aws/eks/example-cluster/cluster」。
4.次のクエリを実行します。
fields @timestamp, @message | filter @logStream like /authenticator/ | sort @timestamp desc | limit 1000
kubectl コマンドを実行して、エラーが発生したときと同じ時間間隔のログ行を特定します。エラーの原因の詳細については、Amazon EKS 認証ログを確認してください。
- 正しくない IAM エンティティを kubectl に使用しているのが問題の原因である場合は、kubectl kubeconfig と AWS CLI の設定を確認してください。正しい IAM ロールを使用していることを確認してください。たとえば、ログが次のようになっているとします。この出力は、kubectl が使用する IAM エンティティを検証できないことを意味します。kubectl が使用する IAM エンティティが IAM に存在し、エンティティのプログラムによるアクセスが有効になっていることを確認してください。
time="2022-12-26T20:46:48Z" level=warning msg="access denied" client="127.0.0.1:43440" error="sts getCallerIdentity failed: error from AWS (expected 200, got 403). Body: {\"Error\":{\"Code\":\"InvalidClientTokenId\",\"Message\":\"The security token included in the request is invalid.\",\"Type\":\"Sender\"},\"RequestId\":\"a9068247-f1ab-47ef-b1b1-cda46a27be0e\"}" method=POST path=/authenticate
- IAM エンティティが aws-auth ConfigMap にマッピングされていないか、マッピングが不適切であることが問題の原因の場合は、aws-auth ConfigMap を確認してください。IAM エンティティが正しくマッピングされ、「クラスター作成者ではない場合」セクションに記載されている要件を満たしていることを確認してください。この場合、EKS 認証ログは次のようになります。
time="2022-12-28T15:37:19Z" level=warning msg="access denied" arn="arn:aws:iam::XXXXXXXXXX:role/admin-test-role" client="127.0.0.1:33384" error="ARN is not mapped" method=POST path=/authenticate
- aws-auth ConfigMap が更新されて、クラスターにアクセスできなくなった場合は、クラスター作成者の IAM エンティティでクラスターにアクセスできます。これは、クラスター作成者は aws-auth ConfigMap にマッピングする必要がないためです。
- クラスター作成者の IAM エンティティが削除された場合は、まず同じ IAM ユーザーまたはロールを再度作成します。次に、「クラスター作成者の場合」セクションの手順に従って、この IAM エンティティでクラスターにアクセスします。
- クラスター作成者が、削除された SSO ユーザー用に作成された IAM ロールの場合、この IAM ロールは再度作成することはできません。その場合は、AWS サポートにお問い合わせください。
関連情報
あなたのクラスターへの IAM ユーザーおよびロールアクセスを有効にする
Amazon EKS でクラスターを作成した後、他の IAM ユーザーやロールにアクセス権を与える方法を教えてください。
Using RBAC authorization (Kubernetes ウェブサイト)
関連するコンテンツ
- 質問済み 5ヶ月前lg...
- 質問済み 1年前lg...
- 質問済み 4年前lg...
- AWS公式更新しました 1年前
- AWS公式更新しました 1年前