このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
EKS Pod Identity のターゲット IAM ロールを使用して AWS リソースにアクセスする
Amazon Elastic Kubernetes Service (Amazon EKS) でアプリケーションを実行する場合、同じまたは異なる AWS アカウントに存在する AWS リソースへのアクセスが必要になることがあります。このガイドでは、EKS Pod Identity を使用してこれらのアカウント間のアクセスを設定する方法を示します。これにより、Kubernetes ポッドから他の AWS リソースにアクセスできるようになります。
前提条件
作業を開始する前に、次の手順が完了していることを確認してください。
仕組み
Pod Identity を使用すると、EKS クラスター内のアプリケーションから、ロールチェーンと呼ばれるプロセスを通じてアカウント間の AWS リソースにアクセスできます。Pod Identity の関連付けを作成する際は、EKS クラスターと同じアカウント内にある EKS Pod Identity ロールと、ユーザーの AWS リソース (S3 バケットや DynamoDB テーブルなど) が含まれたアカウントのターゲット IAM ロールという 2 つの IAM ロールを指定できます。IAM PassRole の要件により、EKS Pod Identity ロールは EKS クラスターのアカウント内に存在する必要がありますが、ターゲット IAM ロールは任意の AWS アカウントに存在できます。PassRole を使用すると、AWS エンティティはロールの引き受けを別のサービスに委任できます。EKS Pod Identity は PassRole を使用してロールを Kubernetes サービスアカウントに接続し、ロールとそれを渡す ID の両方が EKS クラスターと同じ AWS アカウントに存在する必要があります。アプリケーションポッドから AWS リソースにアクセスする必要がある場合、ポッドで Pod Identity の認証情報が要求されます。次に、Pod Identity は 2 つのロールの引き受けを順番に自動実行します。つまり、最初に EKS Pod Identity ロールを引き受け、次にその認証情報を使用してターゲット IAM ロールを引き受けます。このプロセスにより、ターゲットロールで定義されたアクセス許可を含む一時的な認証情報がポッドに提供され、他の AWS アカウントのリソースへの安全なアクセスが実現します。
キャッシュに関する考慮事項
キャッシュメカニズムにより、既存の Pod Identity の関連付けで IAM ロールを更新しても、EKS クラスターで実行されているポッドですぐに有効にならない場合があります。Pod Identity エージェントは、認証情報の取得時に関連付けの設定に基づいて IAM 認証情報をキャッシュします。関連付けに EKS Pod Identity ロール ARN のみが含まれ、ターゲット IAM ロールが含まれていない場合、キャッシュされた認証情報は 6 時間有効となります。関連付けに EKS Pod Identity ロール ARN とターゲット IAM ロールの両方が含まれている場合、キャッシュされた認証情報は 59 分間有効です。EKS Pod Identity ロール ARN の更新やターゲット IAM ロールの追加など、既存の関連付けを変更しても、既存のキャッシュはリセットされません。その結果、エージェントはキャッシュされた認証情報が更新されるまで更新を認識しません。変更をより迅速に適用するには、既存のポッドを再作成できます。再作成しない場合は、キャッシュの有効期限が切れるまで待機する必要があります。
ステップ 1: ターゲット IAM ロールを作成して関連付ける
このステップでは、ターゲット IAM ロールを作成して設定することで、安全な信頼チェーンを確立します。デモンストレーションでは、2 つの AWS アカウント間で信頼チェーンを確立するための新しいターゲット IAM ロールを作成します。EKS クラスターの AWS アカウント内にある EKS Pod Identity ロール (例: eks-pod-identity-primary-role
) で、ターゲットアカウントでターゲット IAM ロール (例:eks-pod-identity-aws-resources
) を引き受ける権限を取得し、Amazon S3 バケットなどの AWS リソースへのアクセスを有効にします。
ターゲット IAM ロールを作成する
-
Amazon IAM コンソール
を開きます。 -
上部のナビゲーションバーで、ターゲット IAM ロールの AWS リソース (S3 バケットや DynamoDB テーブルなど) を含むアカウントにサインインしていることを確認します。
-
左のナビゲーションペインで、[ロール] を選択してください。
-
[ロールの作成] ボタンを選択し、「信頼できるエンティティタイプ」の下にある AWS アカウントを選択します。
-
別の AWS アカウントを選択し、AWS のアカウント番号 (EKS Pod Identity ロールが存在するアカウント) を入力し、[次へ] を選択します。
-
ロールに関連付けるアクセス許可ポリシー (AmazonS3FullAccess など) を追加し、[次へ] を選択します。
-
「
MyCustomIAMTargetRole
」などのロール名を入力し、[ロールの作成] を選択します。
ターゲット IAM ロールの信頼ポリシーを更新する
-
ロールを作成すると、[ロール] リストに戻ります。前の手順で作成した新規ロールを検索し、選択します (例:
MyCustomIAMTargetRole
)。 -
[信頼関係] タブを選択します。
-
右側の [信頼ポリシーを編集] をクリックします。
-
ポリシーエディタで、デフォルトの JSON を信頼ポリシーに置き換えます。IAM ロール ARN のロール名と
111122223333
のプレースホルダー値を、EKS クラスターをホストする AWS アカウント ID に置き換えます。例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" }, "Action": "sts:AssumeRole" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" }, "Action": "sts:TagSession" } ] }
EKS Pod Identity ロールのアクセス許可ポリシーを更新する
このステップでは、ターゲット IAM ロール ARN をリソースとして追加し、Amazon EKS クラスターに関連付けられた EKS Pod Identity ロールのアクセス許可ポリシーを更新します。
-
Amazon EKS コンソール
を開きます。 -
左のナビゲーションペインで [クラスター] を選択し、次に EKS クラスターの名前を選択します。
-
[リモートアクセス] タブを選択してください。
-
[Pod Identity の関連付け] で、[EKS Pod Identity ロール] を選択します。
-
[アクセス許可]、[許可を追加] を選択し、次に [インラインポリシーを作成] をクリックします。
-
右側で [JSON] を選択します。
-
ポリシーエディタで、デフォルトの JSON をアクセス許可ポリシーに置き換えます。IAM ロール ARN のロール名と
222233334444
のプレースホルダー値をターゲット IAM ロールに置き換えます。例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources" } ] }
ステップ 2: ターゲット IAM ロールを Kubernetes サービスアカウントに関連付ける
このステップでは、ターゲット IAM ロールと EKS クラスター内の Kubernetes サービスアカウントとの関連付けを作成します。
-
Amazon EKS コンソール
を開きます。 -
左のナビゲーションペインで [クラスター] を選択し、次に関連付けを追加するクラスター名を選択します。
-
[アクセス] タブを選択します。
-
[Pod Identity の関連付け] で [作成] を選択します。
-
ワークロードが引き受ける IAM ロールの EKS Pod Identity ロールを選択します。
-
EKS Pod Identity ロールが引き受けるターゲット IAM ロールを [ターゲット IAM ロール] で選択します。
-
[Kubernetes 名前空間] フィールドに、関連付けを作成する名前空間の名前を入力します (例:
my-app-namespace
)。これにより、サービスアカウントが存在する場所が定義されます。 -
[Kubernetes サービスアカウント] フィールドに、IAM 認証情報を使用するサービスアカウントの名前 (例:
my-service-account
) を入力します。これにより、IAM ロールがサービスアカウントにリンクされます。 -
[作成] を選択して関連付けを作成します。
(オプション) ステップ 3: IAM ターゲットロールに外部アクセス許可を追加する
お客様の AWS リソースへのアクセス権をサードパーティーに付与 (委任) することが必要になる場合があります。例えば、Example Corp という第三者企業を雇って、コストを最適化するために AWS アカウントをモニタリングする業務を依頼するとします。Example Corp がお客様の毎日の支出を追跡するには、お客様の AWS リソースにアクセスする必要があります。この場合、IAM ターゲットロールの信頼ポリシーに ExternalId
を追加して、混乱した代理の問題が発生する可能性を回避することをお勧めします。
信頼ポリシーを編集する
-
ロールを作成すると、[ロール] リストに戻ります。前のステップで作成した新しいロール (例:
MyCustomIAMTargetRole
) を検索し、クリックします。 -
[信頼関係] タブを選択します。
-
右側の [信頼ポリシーを編集] をクリックします。
-
ポリシーエディタで、デフォルトの JSON を信頼ポリシーに置き換えます。
aws-region/other-account/cluster-name/namespace/service-account-name
のExternalId
プレースホルダー値を置き換えます。ここで「region」はクラスターの AWS リージョン、「111122223333」は他の AWS アカウント ID、「cluster-name」は EKS クラスター名、「namespace」は Kubernetes 名前空間、「service-account-name」は Kubernetes サービスアカウント名です。例:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name" } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" }, "Action": "sts:TagSession" } ] }