プロファイル適用性: レベル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を通じてアクセスおよびイベントのログ記録が可能で、事後監査を確実に行うことができます。