のトラブルシューティングIAM - Amazon EKS

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

のトラブルシューティングIAM

このトピックでは、Amazon EKS での IAM の使用中に表示される一般的なエラーとその回避方法について説明します。

AccessDeniedException

AccessDeniedException API オペレーションの呼び出し時に AWS を受け取った場合、使用している AWS Identity and Access Management (IAM) ユーザーまたはロールの認証情報には、その呼び出しに必要なアクセス許可がありません。

An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:iam::<111122223333>:user/<user_name> is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks<:region>:<111122223333>:cluster/<cluster_name>

上記のメッセージ例では、ユーザーは Amazon EKS DescribeCluster API オペレーションを呼び出す権限を持っていません。ユーザーに Amazon EKS 管理権限を付与するには、Amazon EKS アイデンティティベースのポリシーの例.を参照してください。

の一般的な情報についてはIAM、の「 ポリシーを使用したアクセスの制御」を参照してくださいIAM ユーザーガイド

ワークロードまたはノードを確認して、 でエラーを受け取ることができない AWS マネジメントコンソール

「」というコンソールエラーメッセージが表示されることがありますYour current user or role does not have access to Kubernetes objects on this EKS cluster。 にサインインしている IAM エンティティ (ユーザーまたはロール) が、以下のAWS マネジメントコンソールすべての要件を満たしていることを確認します。

  • IAM アクションを含む eks:AccessKubernetesApi ポリシーがアタッチされています。IAM ポリシーの例については、「」ですべてのクラスターのノードとワークロードを表示する AWS マネジメントコンソールを参照してください。でIAMポリシービジュアルエディタを使用してAWS マネジメントコンソールいてeks:AccessKubernetesApi、[Permission] がリストに表示されない場合、ポリシーの JSON を編集し、JSON の eks:AccessKubernetesApiActionリストに を追加します。

  • aws-auth configmap 内の Kubernetes ユーザーまたはグループへのマッピングがあります。IAM ユーザーまたはロールを aws-auth configmap に追加する方法の詳細についてはクラスターのユーザーまたは IAM ロールの管理、「」を参照してください。ユーザーまたはロールがマッピングされていない場合、コンソールエラーには Unauthorized: Kubernetes クラスターにアクセスできることを確認する が含まれる場合があります。

  • IAM アカウントまたはロールが configmap でマッピングされている Kubernetes ユーザーまたはグループは、Kubernetes にバインドsubjectrolebindingされている clusterrolebinding または role clusterrole であるか、Kubernetes リソースを表示するために必要なアクセス許可を持つ である必要があります。ユーザーまたはグループに必要なアクセス許可がない場合、コンソールエラーに「Unauthorized: Verify you has access to the Kubernetes cluster (Kubernetes クラスターにアクセスできることを確認してください)」が含まれることがあります。ロールとバインドを作成するには、Kubernetes ドキュメントの「RBAC 認証https://kubernetes.io/docs/reference/access-authn-authz/rbac/の使用」を参照してください。および clusterrole または clusterrolebinding と を作成する次のマニフェスト例をダウンロードできますrolerolebinding

aws-auth ConfigMap はクラスターへのアクセスを許可しません

AWS IAM Authenticator は、設定マップで使用されるロール ARN でパスを許可しません。したがって、rolearn を指定する前に、パスを削除してください。たとえば、 arn:aws:iam::<123456789012>:role/<team>/<developers>/<eks-admin> を に変更しますarn:aws:iam::<123456789012>:role/<eks-admin>

iam:PassRole を実行する権限がない

iam:PassRole アクションを実行する権限がないというエラーが表示された場合、管理者に問い合わせ、サポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。Amazon EKS にロールを渡すことができるようにポリシーを更新するよう、管理者に依頼します。

一部の AWS サービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。

以下の例のエラーは、marymajor という IAM ユーザーがコンソールを使用して Amazon EKS でアクションを実行しようする場合に発生します。ただし、アクションでは、サービスロールによって付与されたアクセス許可がサービスにある必要があります。メアリーには、ロールをサービスに渡すアクセス許可がありません。

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

この場合、メアリーは担当の管理者に iam:PassRole アクションを実行できるようにポリシーの更新を依頼します。

アクセスキーを表示する場合

IAM ユーザーアクセスキーを作成した後は、いつでもアクセスキー ID を表示できます。ただし、シークレットアクセスキーをもう一度表示することはできません。シークレットアクセスキーを紛失した場合は、新しいキーペアを作成する必要があります。

アクセスキーは、アクセスキー ID (例: AKIAIOSFODNN7EXAMPLE) とシークレットアクセスキー (例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) の 2 つの部分から構成されます。ユーザー名とパスワードと同様に、リクエストを認証するために、アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユーザー名とパスワードと同様に、アクセスキーをしっかり管理してください。

重要

正規ユーザー ID を確認するためであっても、アクセスキーをサードパーティーに提供しないでください。提供すると、第三者がアカウントへの永続的アクセスを取得する場合があります。

アクセスキーペアを作成する場合、アクセスキー ID とシークレットアクセスキーを安全な場所に保存するように求めるプロンプトが表示されます。このシークレットアクセスキーは、作成時にのみ使用できます。シークレットアクセスキーを紛失した場合、新しいアクセスキーを IAM ユーザーに追加する必要があります。最大 2 つのアクセスキーを持つことができます。すでに 2 つある場合は、新しいキーペアを作成する前に、いずれかを削除する必要があります。手順を確認するには、IAM ユーザーガイドの「アクセスキーの管理」を参照してください。

管理者として へのアクセスを他のユーザーに許可するAmazon EKS

Amazon EKS へのアクセスを他のユーザーに許可するには、アクセスを必要とする人またはアプリケーションの IAM エンティティ (ユーザーまたはロール) を作成する必要があります。ユーザーは、このエンティティの認証情報を使用して AWS にアクセスします。次に、Amazon EKS の適切なアクセス許可を付与するポリシーを、そのエンティティにアタッチする必要があります。

すぐに開始するには、IAM ユーザーガイドの「IAM が委任した最初のユーザーおよびグループの作成」を参照してください 。

自分の AWS アカウント以外のユーザーに Amazon EKS リソースへのアクセスを許可する場合

他のアカウントのユーザーや組織外のユーザーが、リソースへのアクセスに使用できるロールを作成できます。ロールを引き受けるように信頼されたユーザーを指定することができます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。

詳細については、以下を参照してください。