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

マルチアカウント戦略

AWS では、マルチアカウント戦略と AWS 組織を使用して、ビジネスアプリケーションとデータを分離および管理することをお勧めします。マルチアカウント戦略を使用することには多くの利点があります。

以下のセクションでは、集中型または分散型の EKS クラスターアプローチを使用して EKS ワークロードにマルチアカウント戦略を実装する方法について説明します。

マルチテナントクラスターのマルチワークロードアカウント戦略の計画

マルチアカウント AWS 戦略では、S3 バケット、ElastiCache クラスター、DynamoDB テーブルなどの特定のワークロードに属するリソースはすべて、そのワークロードのすべてのリソースを含む AWS アカウントに作成されます。これらはワークロードアカウントと呼ばれ、EKS クラスターはクラスターアカウントと呼ばれるアカウントにデプロイされます。クラスターアカウントについては、次のセクションで説明します。専用ワークロードアカウントにリソースをデプロイすることは、kubernetes リソースを専用名前空間にデプロイする場合と似ています。

その後、ワークロードアカウントは、必要に応じてソフトウェア開発ライフサイクルやその他の要件別にさらに分類できます。たとえば、特定のワークロードには、本番稼働用アカウント、開発用アカウント、または特定のリージョンでそのワークロードのインスタンスをホストするためのアカウントを含めることができます。詳細については、この AWS ホワイトペーパーを参照してください。

EKS マルチアカウント戦略を実装するときは、次のアプローチを採用できます。

一元化された EKS クラスター

このアプローチでは、EKS クラスターは という単一の AWS アカウントにデプロイされますCluster Account。サービスアカウント (IRSA) または EKS Pod ID の IAM ロールを使用して一時的な AWS 認証情報を配信し、AWS Resource Access Manager (RAM) を使用してネットワークアクセスを簡素化することで、マルチテナント EKS クラスターにマルチアカウント戦略を採用できます。 https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.htmlクラスターアカウントには、VPC、サブネット、EKS クラスター、EC2/Fargate コンピューティングリソース (ワーカーノード）、および EKS クラスターの実行に必要な追加のネットワーク設定が含まれます。

マルチテナントクラスターのマルチワークロードアカウント戦略では、AWS アカウントは通常、リソースグループを分離するためのメカニズムとして kubernetes 名前空間と一致します。マルチテナント EKS クラスターにマルチアカウント戦略を実装する場合は、EKS クラスター内のテナント分離のベストプラクティスに従う必要があります。

AWS 組織Cluster Accountsには複数の を含めることができ、ソフトウェア開発ライフサイクルのニーズに合った複数の を持つことCluster Accountsがベストプラクティスです。非常に大規模なワークロードでは、すべてのワークロードCluster Accountsで使用できる十分な kubernetes と AWS サービスクォータを確保するために、複数の が必要になる場合があります。

|上記の図では、AWS RAM を使用してクラスターアカウントからワークロードアカウントにサブネットを共有しています。次に、EKS ポッドで実行されているワークロードは、IRSA または EKS ポッドアイデンティティとロールチェーンを使用してワークロードアカウントのロールを引き受け、AWS リソースにアクセスします。

マルチテナントクラスターのマルチワークロードアカウント戦略の実装

AWS Resource Access Manager とのサブネットの共有

AWS Resource Access Manager (RAM) を使用すると、AWS アカウント間でリソースを共有できます。

AWS Organization で RAM が有効になっている場合は、クラスターアカウントからワークロードアカウントに VPC サブネットを共有できます。これにより、Amazon ElastiCache クラスターや Amazon Relational Database Service (RDS) データベースなどのワークロードアカウントが所有する AWS リソースを EKS クラスターと同じ VPC にデプロイし、EKS クラスターで実行されているワークロードで使用できるようになります。

RAM 経由でリソースを共有するには、クラスターアカウントの AWS コンソールで RAM を開き、「リソース共有」と「リソース共有の作成」を選択します。リソース共有に名前を付け、共有するサブネットを選択します。次へを再度選択し、サブネットを共有するワークロードアカウントの 12 桁のアカウント IDs を入力し、次へを再度選択して、リソース共有の作成をクリックして終了します。このステップの後、ワークロードアカウントはそれらのサブネットにリソースをデプロイできます。

RAM 共有は、プログラムで作成することも、Infrastructure as Code を使用して作成することもできます。

EKS ポッド ID と IRSA の選択

re:Invent 2023 で、AWS は一時的な AWS 認証情報を EKS 上のポッドに配信する簡単な方法として EKS Pod ID を起動しました。IRSA と EKS Pod ID はどちらも、一時的な AWS 認証情報を EKS ポッドに配信するための有効な方法であり、引き続きサポートされます。ニーズに最適な配信方法を検討する必要があります。

EKS クラスターと複数の AWS アカウントを使用する場合、IRSA は EKS クラスターが直接ホストされているアカウント以外の AWS アカウントでロールを直接引き受けることができますが、EKS Pod ID ではロールの連鎖を設定する必要があります。詳細な比較については、EKS ドキュメントを参照してください。

サービスアカウントの IAM ロールを使用した AWS API リソースへのアクセス

サービスアカウントの IAM ロール (IRSA) を使用すると、EKS で実行されているワークロードに一時的な AWS 認証情報を配信できます。IRSA を使用して、クラスターアカウントからワークロードアカウントの IAM ロールの一時的な認証情報を取得できます。これにより、クラスターアカウントの EKS クラスターで実行されているワークロードは、ワークロードアカウントでホストされている S3 バケットなどの AWS API リソースをシームレスに消費し、Amazon RDS データベースや Amazon EFS FileSystems などのリソースに IAM 認証を使用できます。

ワークロードアカウントで IAM 認証を使用する AWS API リソースおよびその他のリソースには、クロスアカウントアクセスが可能であり、明示的が有効になっている場合を除き、同じワークロードアカウントの IAM ロールの認証情報でのみアクセスできます。

クロスアカウントアクセスの IRSA の有効化

クラスターアカウントのワークロードの IRSA がワークロードアカウントのリソースにアクセスできるようにするには、まずワークロードアカウントに IAM OIDC ID プロバイダーを作成する必要があります。これは、IRSA を設定するのと同じ手順で実行できます。ただし、ID プロバイダーはワークロードアカウントで作成されます。

次に、EKS でワークロードに IRSA を設定するときに、 ドキュメントと同じステップを実行できますが、「別のアカウントのクラスターから ID プロバイダーを作成する」セクションで説明されているように、ワークロードアカウントの 12 桁のアカウント ID を使用します。

これを設定すると、EKS で実行されているアプリケーションは、そのサービスアカウントを直接使用してワークロードアカウントのロールを引き受け、その中のリソースを使用できます。

EKS Pod ID を使用した AWS API リソースへのアクセス

EKS Pod Identity は、EKS で実行されているワークロードに AWS 認証情報を配信する新しい方法です。EKS ポッド ID は、EKS 上のポッドに AWS 認証情報を配信するために OIDC 設定を管理する必要がなくなるため、AWS リソースの設定を簡素化します。

クロスアカウントアクセスの EKS Pod ID の有効化

IRSA とは異なり、EKS ポッドアイデンティティは、EKS クラスターと同じアカウントのロールへのアクセスを直接付与するためにのみ使用できます。別の AWS アカウントのロールにアクセスするには、EKS Pod ID を使用するポッドがロールの連鎖を実行する必要があります。

ロールの連鎖は、さまざまな AWS SDKs で使用できる Process Credentials Provider を使用して、aws 設定ファイルを持つアプリケーションプロファイルで設定できます。 credential_processは、次のようなプロファイルを設定するときに認証情報ソースとして使用できます。

# Content of the AWS Config file
[profile account_b_role]
source_profile = account_a_role
role_arn = arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
credential_process = /eks-credential-processrole.sh

credentials_process によって呼び出されるスクリプトのソース:

#!/bin/bash
# Content of the eks-credential-processrole.sh
# This will retreive the credential from the pod identities agent,
# and return it to the AWS SDK when referenced in a profile
curl -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c '{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}'

上記のように、アカウント A ロールと B ロールの両方を使用して aws 設定ファイルを作成し、ポッド仕様で AWS_CONFIG_FILE および AWS_PROFILE env vars を指定できます。EKS Pod ID ウェブフックは、env vars がポッド仕様に既に存在する場合、上書きされません。

# Snippet of the PodSpec
containers:
  - name: container-name
    image: container-image:version
    env:
    - name: AWS_CONFIG_FILE
      value: path-to-customer-provided-aws-config-file
    - name: AWS_PROFILE
      value: account_b_role

EKS ポッドアイデンティティを使用してロールを連鎖させるロール信頼ポリシーを設定する場合、EKS 固有の属性をセッションタグとして参照し、属性ベースのアクセスコントロール (ABAC) を使用して、ポッドが属する Kubernetes サービスアカウントなどの特定の EKS Pod ID セッションにのみ IAM ロールへのアクセスを制限できます。

これらの属性の一部は汎用的に一意ではない場合があることに注意してください。たとえば、2 つの EKS クラスターが同じ名前空間を持ち、1 つのクラスターが名前空間間で同じ名前のサービスアカウントを持つ場合があります。したがって、EKS Pod ID と ABAC を介してアクセスを許可する場合は、サービスアカウントへのアクセスを許可するときにクラスター ARN と名前空間を常に考慮することをお勧めします。

クロスアカウントアクセス用の ABAC および EKS Pod ID

マルチアカウント戦略の一環として EKS Pod Identity を使用して他のアカウントのロール (ロールの連鎖) を引き受ける場合、別のアカウントにアクセスする必要があるサービスアカウントごとに一意の IAM ロールを割り当てるか、複数のサービスアカウントで共通の IAM ロールを使用して ABAC を使用してアクセスできるアカウントを制御できます。

ABAC を使用して、ロールチェーンを使用してロールを別のアカウントに引き受けることができるサービスアカウントを制御するには、ロール信頼ポリシーステートメントを作成します。このステートメントでは、想定値が存在する場合にのみ、ロールセッションでロールを引き受けることができます。次のロール信頼ポリシーでは、 eks-cluster-arnおよび kubernetes-namespace タグがすべて想定値を持つ場合にのみkubernetes-service-account、EKS クラスターアカウント (アカウント ID 111122223333) のロールがロールを引き受けることを許可します。

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "PayrollApplication",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

この戦略を使用する場合は、共通の IAM ロールに アクセスsts:AssumeRole許可のみがあり、他の AWS アクセスがないことを確認するのがベストプラクティスです。

ABAC を使用するときは、IAM ロールとユーザーを、厳密に必要なユーザーのみにタグ付けできるユーザーを制御することが重要です。IAM ロールまたはユーザーにタグを付けることができるユーザーは、EKS Pod Identity によって設定されるものと同じロール/ユーザーにタグを設定でき、権限をエスカレーションできる可能性があります。IAM ポリシー、またはサービスコントロールポリシー (SCP) を使用して、IAM ロールとユーザーにタグkubernetes-とeks-タグを設定するアクセス権を持つユーザーを制限できます。

分散型 EKS クラスター

このアプローチでは、EKS クラスターは各ワークロードの AWS アカウントにデプロイされ、Amazon S3 バケット、VPCs、Amazon DynamoDB テーブルなどの他の AWS リソースと一緒に動作します。各ワークロードアカウントは独立しており、自己完結しており、各ビジネスユニット/アプリケーションチームによって運用されています。このモデルでは、 AI/ML クラスター 、バッチ処理、汎用など、さまざまなクラスター機能の再利用可能なブループリントを作成し、アプリケーションチームの要件に基づいてクラスターを  供給できます。アプリケーションチームとプラットフォームチームの両方がそれぞれの GitOps リポジトリから運用され、ワークロードクラスターへのデプロイを管理します。

上記の図では、Amazon EKS クラスターおよびその他の AWS リソースがそれぞれのワークロードアカウントにデプロイされています。次に、EKS ポッドで実行されているワークロードは、IRSA または EKS Pod ID を使用して AWS リソースにアクセスします。

GitOps は、Git リポジトリでシステム全体が宣言的に記述されるように、アプリケーションとインフラストラクチャのデプロイを管理する方法です。これは、バージョン管理、イミュータブルアーティファクト、オートメーションのベストプラクティスを使用して、複数の Kubernetes クラスターの状態を管理する機能を提供する運用モデルです。このマルチクラスターモデルでは、各ワークロードクラスターは複数の Git リポジトリでブートストラップされるため、各チーム (アプリケーション、プラットフォーム、セキュリティなど) はそれぞれの変更をクラスターにデプロイできます。

各アカウントのサービスアカウント (IRSA) または EKS Pod ID の IAM ロールを使用して、EKS ワークロードが一時的な aws 認証情報を取得して他の AWS リソースに安全にアクセスできるようにします。 https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.htmlIAM ロールは、それぞれのワークロードの AWS アカウントで作成され、一時的な IAM アクセスを提供するために k8s サービスアカウントにマッピングされます。したがって、このアプローチではクロスアカウントアクセスは必要ありません。IRSA の各ワークロードで を設定する方法については、サービスアカウントの IAM ロールに関するドキュメント、各アカウントの EKS ポッド ID を設定する方法については、EKS ポッド ID に関するドキュメントを参照してください。

一元化されたネットワーク

AWS RAM を使用して VPC サブネットをワークロードアカウントと共有し、Amazon EKS クラスターやその他の AWS リソースを起動することもできます。これにより、一元化されたネットワーク管理、簡素化されたネットワーク接続、および分散された EKS クラスターが可能になります。このアプローチの詳細なウォークスルーと考慮事項については、この AWS ブログを参照してください。

上記の図では、AWS RAM を使用して、中央ネットワークアカウントからワークロードアカウントにサブネットを共有しています。次に、EKS クラスターおよびその他の AWS リソースが、それぞれのワークロードアカウントのサブネットで起動されます。EKS ポッドは、IRSA または EKS Pod ID を使用して AWS リソースにアクセスします。

一元化された EKS クラスターと分散された EKS クラスター

集中型または分散型で実行するかどうかは、要件によって異なります。この表は、各戦略の主な違いを示しています。