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

# クラスターアクセス管理
<a name="cluster-access-management"></a>

Amazon EKS クラスターのセキュリティと整合性を維持するには、効果的なアクセス管理が不可欠です。このガイドでは、AWS IAM Identity Center (以前の AWS SSO) の使用に焦点を当て、EKS アクセス管理のさまざまなオプションについて説明します。さまざまなアプローチを比較し、そのトレードオフについて話し合い、既知の制限と考慮事項を強調します。

## EKS アクセス管理オプション
<a name="_eks_access_management_options"></a>

**注記**  
ConfigMap ベースのアクセス管理 (aws-auth ConfigMap) は廃止され、Cluster Access Management (CAM) API に置き換えられます。新しい EKS クラスターの場合は、CAM API を実装してクラスターアクセスを管理します。aws-auth ConfigMap を使用する既存のクラスターの場合は、CAM API を使用して に移行します。

## オプション 1: クラスターアクセス管理 (CAM) API を使用する AWS IAM アイデンティティセンター
<a name="_option_1_aws_iam_identity_center_with_cluster_access_management_cam_api"></a>
+ 一元化されたユーザーとアクセス許可の管理
+ 既存の ID プロバイダーとの統合 (Microsoft AD、Okta、PingId など)
+ CAM API はアクセスエントリを使用して、AWS IAM プリンシパル (ユーザーまたはロール) を EKS クラスターにリンクします。これらのエントリは IAM Identity Center のマネージド ID と連携するため、管理者は Identity Center で定義されたユーザーとグループのクラスターアクセスを制御できます。

### EKS クラスター認証フロー:
<a name="_eks_cluster_authentication_flow"></a>

![EKS クラスター認証フロー](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/eks-auth-flow.jpg)


1. プリンシパル (ヒューマンユーザー) または自動プロセスは、適切な AWS アカウントのアクセス許可を提示することで AWS IAM を介して認証します。このステップでは、適切な AWS IAM プリンシパル (ロールまたはユーザー) にマッピングされます。

1. 次に、EKS アクセスエントリは、Kubernetes アクセス許可のみを含む適切なアクセスポリシーを定義することで、この IAM プリンシパルを Kubernetes RBAC プリンシパル (ユーザーまたはグループ) にマッピングします。

1. Kubernetes エンドユーザーがクラスターにアクセスしようとすると、その認証リクエストは aws-iam-authenticator または AWS EKS CLI によって処理され、kubeconfig ファイルのクラスターコンテキストに対して検証されます。

1. 最後に、EKS オーソライザーは、認証されたユーザーのアクセスエントリに関連付けられたアクセス許可を検証し、それに応じてアクセスを許可または拒否します。
   + API は Amazon EKS 固有のアクセスポリシーを使用して、各アクセスエントリの認可レベルを定義します。これらのポリシーは、IAM Identity Center で設定されたロールとアクセス許可にマッピングできるため、AWS のサービスおよび EKS クラスター間で一貫したアクセスコントロールを確保できます。

### ConfigMap ベースのアクセス管理の利点:
<a name="_benefits_over_configmap_based_access_management"></a>

1.  **設定ミスのリスクを軽減**: API ベースの直接管理により、ConfigMap の手動編集に関連する一般的なエラーを排除します。これにより、クラスターからユーザーをロックアウトする可能性のある誤った削除や構文エラーを防ぐことができます。

1.  **最小特権の原則を強化**: クラスター作成者 ID からクラスター管理者アクセス許可が不要になり、より詳細で適切なアクセス許可の割り当てが可能になります。このアクセス許可は、Break Glass ユースケースに追加できます。

1.  **拡張セキュリティモデル**: アクセスエントリが適用される前に、組み込みの検証を提供します。さらに、 は認証のために AWS IAM とのより緊密な統合を提供します。

1.  **オペレーションの合理化**: AWS ネイティブツールを使用してアクセス許可を管理する、より直感的な方法を提供します。

### ベストプラクティス:
<a name="_best_practices"></a>

1. AWS Organizations を使用して複数のアカウントを管理し、サービスコントロールポリシー (SCPs。

1. 最小特権の原則を実装するには、さまざまな EKS ロール (管理者、開発者、読み取り専用など) に特定のアクセス許可セットを作成します。

1. 属性ベースのアクセスコントロール (ABAC) を使用して、ユーザー属性に基づいてポッドにアクセス許可を動的に割り当てます。

1. アクセス許可を定期的に監査して確認します。

### 考慮事項/制限事項:
<a name="_considerationslimitations"></a>

1. Identity Center によって生成されたロール ARNs にはランダムなサフィックスがあるため、静的設定での使用が困難です。

1. Kubernetes リソースレベルでのきめ細かなアクセス許可のサポートが制限されました。カスタム Kubernetes RBAC ロールには追加の設定が必要です。Kubernetes ネイティブ RBAC に加えて、EKS クラスターでの高度なアクセス許可管理に Kyverno を使用することを検討してください。

## オプション 2: Kubernetes グループにマッピングされた AWS IAM ユーザー/ロール
<a name="_option_2_aws_iam_usersroles_mapped_to_kubernetes_groups"></a>

### メリット:
<a name="_pros"></a>

1. IAM アクセス許可をきめ細かく制御します。

1. 予測可能なロール ARN と静的ロール ARNs

### デメリット:
<a name="_cons"></a>

1. ユーザーアカウントの管理オーバーヘッドの増加

1. 一元化された ID 管理の欠如

1. IAM エンティティの拡散の可能性

### ベストプラクティス:
<a name="_best_practices_2"></a>

1. セキュリティと管理性を向上させるために、IAM ユーザーの代わりに IAM ロールを使用する

1. 一貫性と管理の容易性を確保するために、ロールの命名規則を実装する

1. IAM ポリシー条件を使用して、タグやその他の属性に基づいてアクセスを制限します。

1. アクセスキーを定期的にローテーションし、アクセス許可を確認します。

### 考慮事項/制限事項:
<a name="_considerationslimitations_2"></a>

1. 多数のユーザーまたはロールを管理する際のスケーラビリティの問題

1. 組み込みのシングルサインオン機能がない

## オプション 3: OIDC プロバイダー
<a name="_option_3_oidc_providers"></a>

### メリット:
<a name="_pros_2"></a>

1. 既存の ID 管理システムとの統合

1. ユーザーアカウントの管理オーバーヘッドの削減

### デメリット:
<a name="_cons_2"></a>

1. 追加の設定の複雑さ

1. 認証中のレイテンシーが増加する可能性

1. 外部 ID プロバイダーへの依存関係

### ベストプラクティス:
<a name="_best_practices_3"></a>

1. OIDC プロバイダーを慎重に設定して、安全なトークン検証を確保します。

1. 有効期間の短いトークンを使用し、トークン更新メカニズムを実装します。

1. OIDC 設定を定期的に監査および更新します。

[外部シングルサインオンプロバイダーを Amazon EKS と統合](https://aws.amazon.com/solutions/guidance/integrating-external-single-sign-on-providers-with-amazon-eks/)するリファレンス実装については、このガイドを参照してください。

### 考慮事項/制限事項:
<a name="_considerationslimitations_3"></a>

1. IAM と比較して AWS サービスとのネイティブ統合が制限されました。

1. EKS が署名キーを検出するには、OIDC プロバイダーの発行者 URL がパブリックにアクセス可能である必要があります。

## ワークロードの AWS EKS Pod Identity と IRSA
<a name="_aws_eks_pod_identity_vs_irsa_for_workloads"></a>

Amazon EKS には、Amazon EKS クラスターで実行されるワークロードに AWS IAM アクセス許可を付与する 2 つの方法があります。サービスアカウント (IRSA) の IAM ロールと EKS ポッドアイデンティティです。

IRSA と EKS Pod Identity の両方が最小特権アクセス、認証情報の分離、監査可能性の利点を提供しますが、EKS Pod Identity はワークロードにアクセス許可を付与するために推奨される方法です。

EKS ポッドのアイデンティティと認証情報に関する詳細なガイダンスについては、セキュリティのベストプラクティスの[「アイデンティティと認証情報」セクション](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods)を参照してください。

## 推奨事項
<a name="_recommendation"></a>

### IAM Identity Center と CAM API を組み合わせる
<a name="_combine_iam_identity_center_with_cam_api"></a>
+  **管理の簡素化**: クラスターアクセス管理 API を IAM アイデンティティセンターと組み合わせて使用すると、管理者は他の AWS のサービスと一緒に EKS クラスターアクセスを管理できるため、異なるインターフェイスを切り替えるか、ConfigMaps を手動で編集する必要がなくなります。
+ アクセスエントリを使用して、クラスター外から IAM プリンシパルの Kubernetes アクセス許可を管理します。EKS API、AWS コマンドラインインターフェイス、AWS SDKs、AWS CloudFormation、AWS マネジメントコンソールを使用して、クラスターへのアクセスを追加および管理できます。つまり、クラスターを作成したのと同じツールでユーザーを管理できるということです。
+ 詳細な Kubernetes アクセス許可は、アクセスエントリとアクセスポリシーを介して SSO ID に関連付けられた IAM プリンシパルを持つ Kubernetes ユーザーまたはグループをマッピングすることで適用できます。
+ 開始するには、「[アクセスエントリを使用するように認証モードを変更する](https://docs.aws.amazon.com/eks/latest/userguide/setting-up-access-entries.html#access-entries-setup-console)」に従い、次に「[既存の aws-auth ConfigMap エントリをアクセスエントリに移行する](https://docs.aws.amazon.com/eks/latest/userguide/migrating-access-entries.html)」に従います。