プロファイル適用性: レベル1
Kubernetesのワークロードは、Amazon EKS APIに認証するためにクラスターのノードサービスアカウントを使用すべきではありません。他のAWSサービスにAWS
IAMを使用して認証する必要がある各Kubernetesワークロードには、専用のサービスアカウントをプロビジョニングする必要があります。
Amazon EKSで実行されているKubernetesワークロードをAWS APIに対して認証するための手動アプローチには、サービスアカウントキーをKubernetesのシークレットとして保存する方法
(これにより手動でのキーのローテーションやキー漏洩の可能性が生じる) や、基盤となるノードのIAMサービスアカウントを使用する方法があります。これは、1つのポッドがサービスにアクセスする必要がある場合に、サービスアカウントを使用するノード上の他のすべてのポッドがアクセスする必要がない場合、マルチテナントノードでの最小特権の原則に違反します。
監査
クラスター内の各ネームスペースについて、デフォルトのサービスアカウントに割り当てられた権限を確認し、デフォルト以外のロールやクラスターロールがバインドされていないことを確認してください。
さらに、各デフォルトサービスアカウントに対して
automountServiceAccountToken: false設定が適用されていることを確認してください。修復
Amazon EKSクラスターのサービスアカウント用IAMロールを使用すると、IAMロールをKubernetesサービスアカウントに関連付けることができます。このサービスアカウントは、そのサービスアカウントを使用する任意のポッド内のコンテナにAWSの権限を提供できます。この機能により、そのノード上のポッドがAWS
APIを呼び出せるように、ワーカーノードIAMロールに拡張権限を付与する必要がなくなります。
アプリケーションはAWS認証情報でAWS APIリクエストに署名する必要があります。この機能は、Amazon EC2インスタンスプロファイルがAmazon EC2インスタンスに認証情報を提供する方法に似た、アプリケーションの認証情報を管理するための戦略を提供します。AWS認証情報をコンテナに作成して配布する代わりに、またはAmazon
EC2インスタンスのロールを使用する代わりに、IAMロールをKubernetesサービスアカウントに関連付けることができます。ポッドのコンテナ内のアプリケーションは、AWS
SDKまたはAWS CLIを使用して、認可されたAWSサービスにAPIリクエストを行うことができます。
サービスアカウントのIAMロール機能は次の利点を提供します。
- 最小特権: サービスアカウントのためのIAMロール機能を使用することで、ワーカーノードのIAMロールに拡張された権限を付与する必要がなくなり、そのノード上のポッドがAWS APIを呼び出せるようになります。IAM権限をサービスアカウントに限定でき、そのサービスアカウントを使用するポッドのみがその権限にアクセスできます。この機能により、kiamやkube2iamのようなサードパーティソリューションの必要性も排除されます。
- 認証情報の分離: コンテナは、所属するサービスアカウントに関連付けられたIAMロールの認証情報のみを取得できます。コンテナは、別のポッドに属する他のコンテナ用の認証情報にアクセスすることは決してありません。
- 監査可能性: CloudTrailを通じてアクセスとイベントのログが利用可能であり、事後監査を確実にするのに役立ちます。
開始するには、こちらのリストテキストを参照してください。クラスター上のサービスアカウントに対するIAMロールの有効化。
eksctlを使用したエンドツーエンドの手順については、Walkthrough: DaemonSetを更新してIAMをサービスアカウントに使用するを参照してください。