Amazon EKS API サーバーに接続したときに「You must be logged in to the server (Unauthorized)」(サーバーにログインする必要があります (未承認)) というエラーを解決する方法を教えてください。
kubectl コマンドを使用して、Amazon Elastic Kubernetes Service (Amazon EKS) アプリケーションプログラミングインターフェイス (API) サーバーに接続しています。「エラー:"エラー: サーバーへのログインが必要です (Unauthorized)"」というメッセージが表示されました。
簡単な説明
このエラーは、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 Log 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. AWS CLI はクラスター作成者の IAM エンティティで設定してください。シェル環境で 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. AWS CLI は IAM エンティティで設定してください。シェル環境で 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 エンティティがクラスターとのやり取りに使用されたものでない場合は、正しい IAM エンティティを使用するように AWS CLI 設定を更新します。次に、kubectl を使用してクラスターへのアクセスを再試行します。問題が解決しない場合は、ステップ 2 に進みます。
2. 返された IAM エンティティがクラスター作成者でない場合は、IAM エンティティを aws-auth ConfigMap に追加します。これで IAM エンティティがクラスターにアクセスできるようになります。
aws-auth ConfigMap を変更できるのはクラスター管理者のみです。したがって、次のいずれかを行います。
- 「クラスター作成者の場合」セクションの手順を使用して、クラスター作成者の IAM エンティティを使用してクラスターにアクセスします。
- このアクションを実行するようクラスター管理者に依頼します。
次のコマンドを実行して、自分の IAM エンティティが aws-auth ConfigMap にあるかどうかを確認します。
eksctl get iamidentitymapping --cluster cluster-name
-または-
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 を mapRoles に追加します。
例:
mapRoles: | - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testrole username: testrole groups: - system:masters
重要:
- IAM ロールはパスなしでマッピングする必要があります。rolean パス要件の詳細については、「IAM のトラブルシューティング」の「aws-auth ConfigMap がクラスターへのアクセスを許可しない」セクションを展開します。
- AWS IAM アイデンティティセンター (AWS Single Sign-On の後継) IAM ロールの rolearn を指定するには、ロール ARN からパス「/aws-reserved/sso.amazonaws.com/REGION」を削除します。そうしないと、ConfigMap のエントリで有効なユーザーとして認証されません。
- system:masters グループを使用すると、スーパーユーザーが任意のリソースで任意のアクションを実行できます。詳細については、「デフォルトのロールとロールのバインディング」を参照してください。このユーザーのアクセスを制限するには、Amazon EKS ロールとロールバインディングリソースを作成します。Amazon EKS コンソールでリソースを表示するユーザーに対する制限付きアクセスの例については、「必要なアクセス許可」のステップ 2 と 3 に従います。
3. 次のコマンドを実行して、kubeconfig ファイルを更新または生成します。AWS CLI が、ステップ 1 で返された IAM エンティティで設定されていることを確認してください。
$ 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 Log 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 ユーザーおよびロールにアクセス権を付与するにはどうすればよいですか?
RBAC 承認の使用に関する Kubernetes のドキュメンテーション
関連するコンテンツ
- 質問済み 5年前lg...
- 質問済み 4年前lg...
- AWS公式更新しました 4ヶ月前
- AWS公式更新しました 3ヶ月前