AWS Builder Center: Learn, Build and Connect with builders in the AWS community
AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
Amazon EKS ポッドでサービスアカウントに IAM ロールを使用できない理由を知りたいです。
サービス AWS アカウント (IRSA) で AWS Identity and Access Management (IAM) ロールを使用したいのですが、Amazon Elastic Kubernetes Service (Amazon EKS) ポッドが割り当てられた IAM ロールを引き受けられなかったり、ポッドがそのロールを使用せず、Amazon EKS ノードに割り当てられたデフォルト IAM ロールを使用したりします。
解決策
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。
Amazon EKS クラスター用の IAM OIDC ID プロバイダーがあることを確認する
クラスター用の IAM OpenID Connect (OIDC) プロバイダーを作成済みでない場合は、作成します。IRSA を使用するには、クラスター用の OIDC プロバイダーが必要です。
次に以下の手順を実行し、OIDC プロバイダーが正しく設定されていることを確認します。
- IAM コンソールを開きます。
- ナビゲーションペインから [ID プロバイダー] を選択します。
- [プロバイダー] で OIDC プロバイダーの URL を特定して書き留めます。
- 別のタブまたはウィンドウで Amazon EKS コンソールを開きます。
- ナビゲーションペインで [クラスター] を選択します。
- 該当するクラスターを選択し、[構成] タブを選択します。
- [詳細] で [OpenID Connect プロバイダーの URL] の値を確認します。IAM コンソールの OIDC プロバイダー URL と一致することを確認します。
- URL が一致しない場合は、新しい IAM OIDC プロバイダーを作成する必要があります。
IAM ロールポリシーと信頼ポリシーの設定を検証する
IAM の問題は、IAM ロールに必要なアクセス許可が全て揃っていない場合に発生します。または、AWS マネジメントコンソールまたは AWS CLI で IAM ロールを作成した場合は、IAM ロールの信頼関係ポリシーに構文エラーがある可能性があります。
IAM ロールポリシーを検証し、信頼ポリシーに構文エラーがないかどうかを確認するには、次の手順を実行します。
- IAM コンソールを開きます。
- ナビゲーションペインで [ロール] を選択し、該当するロールを選択します。
- [アクセス許可] タブを選択し、使用する構成に必要なすべてのアクセス許可がロールに割り当てられていることを確認します。
- [信頼関係] タブを選択し、[信頼関係の編集] を選択します。
- 信頼関係のポリシードキュメントで、ポリシーの形式が次の JSON ポリシーの形式と一致していることを確認します。
JSON ポリシーで、Federated プロパティ行と StringEquals プロパティ行の形式を確認します。Federated において、AWS リージョンコード、AWS アカウント ID、一意の OIDC 識別子の形式が適切であることを確認します。StringEquals において、リージョンコード、OIDC ユニーク識別子、Kubernetes 名前空間、Kubernetes サービスアカウント名の形式が適切であることを確認します。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::your-account-id:oidc-provider/oidc.eks.your-region-code.amazonaws.com/id/EXAMPLE_OIDC_IDENTIFIER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.your-region-code.amazonaws.com/id/EXAMPLE_OIDC_IDENTIFIER:sub": "system:serviceaccount:your-namespace:your-service-account", "oidc.eks.your-region-code.amazonaws.com/id/EXAMPLE_OIDC_IDENTIFIER:aud": "sts.amazonaws.com" } } } ] } - ポリシードキュメントを編集して形式のエラーを修正する場合は、[信頼ポリシーの更新] を選択します。
サービスアカウントが存在し、IAM ロールの Amazon リソースネーム (ARN) のアノテーションが適切な形式であることを確認します。
次の手順を実行します。
- Kubernetes サービスアカウントが存在することを確認するには、次のコマンドを実行します。
注: 実際のものでそれぞれ、YOUR_ACCOUNT_NAME をアカウント名に、YOUR_NAMESPACE を名前空間に置き換えます。kubectl get serviceaccount YOUR_ACCOUNT_NAME -n YOUR_NAMESPACE -o yaml
上記のコマンドでサービスアカウント名が返されない場合は、サービスアカウントを作成します。詳細については、Kubernetes のウェブサイトで「複数の ServiceAccount を使用する」を参照してください。 - サービスアカウントが使用する名前が想定通りであることを確認します。さらに、role-arn アノテーションが適切な形式であることを確認します。例:
apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::012345678912:role/my-example-iam-role name: my-example-serviceaccount namespace: my-test-namespace
テストポッドを使用してサービスアカウントが機能することを確認する
テストポッドを実行し、サービスアカウントが正しく機能しており、環境変数をマウント可能であり、指定された IAM ロールを引き受けられることを確認します。次の手順を実行します。
-
awscli-pod.yaml というローカルの YAML ファイルを作成します。例:
apiVersion: v1 kind: Pod metadata: name: awscli labels: app: awscli spec: serviceAccountName: YOUR_SERVICE_ACCOUNT containers: - image: amazon/aws-cli command: - "sleep" - "604800" imagePullPolicy: IfNotPresent name: awscli restartPolicy: Always注: YOUR_SERVICE_ACCOUNT を実際の Kubernetes サービスアカウント名に置き換えます。
-
名前空間の YAML ファイルからテストポッドを作成するには、次のコマンドを実行します。
kubectl apply -f ./awscli-pod.yaml -n YOUR_NAMESPACE注: YOUR_NAMESPACE を実際の名前空間に置き換えます。
-
awscli ポッドに AWS_ROLE_ARN と AWS_WEB_IDENTITY_TOKEN_FILE という環境変数があることを確認するには、次のコマンドを実行します。
kubectl exec -n YOUR_NAMESPACE awscli -- env | grep AWS出力例:
AWS_ROLE_ARN=arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token -
テストポッドが正しい IAM ロールを使用していることを確認するには、次のコマンドを実行します。
kubectl exec -it awscli -n YOUR_NAMESPACE -- aws sts get-caller-identity出力例:
{ "UserId": "REDACTEDY471234567890:botocore-session-1632772568", "Account": "012345678912", "Arn": "arn:aws:sts::012345678912:assumed-role/your-iam-role/botocore-session-1632772568" }Arn の値を書き留めておきます。IAM ロールがポッドで使用するロールであることを確認します。
-
awscli ポッドを削除するには、次のコマンドを実行します。
kubectl delete -f ./awscli-pod.yaml -n YOUR_NAMESPACE注: YOUR_NAMESPACE を実際の名前空間に置き換えます。
awscli ポッドに正しい IAM ロールが表示されている場合は、サービスアカウント機能用の IAM ロールは期待通りに動作しています。上記の手順により、IAM トークンがポッドに正しくマウントされていることが検証されます。それでもアプリケーションがトークンファイルを使用できない場合は、アプリケーションレベルまたは SDK レベルでの問題がある可能性があります。たとえば、アプリケーションの AWS 認証情報の使用方法に問題があったり、SDK バージョンがサポートされていなかったりする場合があります。詳細については、「デフォルトの認証情報プロバイダーチェーンを使用する」および「AWS SDK で IRSA を使用する」を参照してください。
- トピック
- Containers
- 言語
- 日本語
