**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# EKS 機能のセキュリティに関する考慮事項
<a name="capabilities-security"></a>

このトピックでは、EKS 機能のセキュリティを考慮するうえで重要な事項について説明します。具体的には、IAM ロール設定、Kubernetes アクセス許可、マルチクラスターデプロイとクロスアカウント AWS リソース管理のアーキテクチャパターンなどです。

EKS 機能では、IAM ロール、EKS アクセスエントリ、Kubernetes RBAC を組み合わせることにより、AWS サービスとクラスター内 Kubernetes リソースに安全にアクセスし、AWS CodeConnections、AWS Secrets Manager、およびその他の AWS サービスと統合できます。

## 機能 IAM ロール
<a name="_capability_iam_role"></a>

機能を作成するときは、自分の代わりに EKS がアクションを実行するように IAM 機能ロールを指定できます。このロールの要件は次のとおりです。
+ クラスターおよび機能リソースと同じ AWS アカウントに存在していること
+ 信頼ポリシーにより、`capabilities.eks.amazonaws.com` サービスプリンシパルがロールを引き受けることを許可すること
+ 要件に応じて、機能タイプとユースケースに適した IAM アクセス許可を付与すること 必要な IAM アクセス許可の詳細については、「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。

ここでのベストプラクティスは、特定のユースケースに必要な権限の範囲を考慮したうえで、要件を満たすために必要なアクセス許可のみを付与することです。例えば、Kube Resource Orchestrator に EKS 機能を使用する場合には IAM アクセス許可は必要ありませんが、Kubernetes 用 AWS コントローラーに EKS 機能を使用する場合には 1 つ以上の AWS サービスへのフルアクセスを許可できます。

**重要**  
ユースケースによっては広範な管理者権限の使用を許可できますが、特定のユースケースに必要な最小限の IAM アクセス許可のみを付与して最小特権の原則に従うと、ワイルドカードアクセス許可を使用するのではなく、ARN と条件キーを使用して、特定のリソースへのアクセスを制限できます。

機能 IAM ロールの作成と設定の詳細については、「[Amazon EKS 機能 IAM ロール](capability-role.md)」を参照してください。

## EKS アクセスエントリ
<a name="_eks_access_entries"></a>

IAM ロールと共に機能を作成すると、Amazon EKS がそのロールのアクセスエントリをクラスターに自動的に作成します。このアクセスエントリにより、動作に必要なベースラインとなる Kubernetes アクセス許可が機能に付与されます。

**注記**  
アクセスエントリが作成されるクラスターは、機能が作成されているクラスターです。Argo CD でリモートクラスターにデプロイする場合は、Argo CD 機能がアプリケーションをデプロイおよび管理できるように、そのクラスターにアクセスエントリを作成して適切なアクセス許可を付与する必要があります。

アクセスエントリの内容は以下のとおりです。
+ IAM ロール ARN をプリンシパルとします。
+ 機能固有のアクセスエントリポリシーでベースライン Kubernetes アクセス許可を付与します。
+ 機能タイプに基づいて適切な範囲 (クラスター全体または名前空間範囲内) を指定します。

**注記**  
Argo CD の場合、名前空間範囲のアクセス許可は機能設定に指定された名前空間に付与されます (デフォルトは `argocd`)。

 **機能別のデフォルトアクセスエントリポリシー** 

機能タイプごとに必要なアクセス許可が機能ロールに付与され、次のように異なるデフォルトアクセスエントリポリシーが設定されます。

 **kro**   
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy` (クラスター範囲)

  ResourceGraphDefinitions を監視および管理するアクセス許可を付与し、RGD に定義されたカスタムリソースのインスタンスを作成します。

 **ACK**   
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy` (クラスター範囲)

  すべての名前空間で ACK カスタムリソースを作成、読み取り、更新、削除できるアクセス許可を付与します。

 **Argo CD**   
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy` (クラスター範囲)

  Argo CD がリソースを検出し、クラスター範囲のオブジェクトを管理するために必要なクラスターレベルのアクセス許可を付与します。
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy` (名前空間範囲)

  Argo CD がアプリケーションをデプロイおよび管理するために必要な名前空間レベルのアクセス許可を付与します。機能設定に指定された名前空間に限定されます (デフォルトは `argocd`)。

詳細については、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。

## その他の Kubernetes アクセス許可
<a name="additional-kubernetes-permissions"></a>

機能によっては、デフォルトのアクセスエントリポリシーの範囲を超える Kubernetes アクセス許可が追加で必要になる場合があります。こうしたアクセス許可を付与するには、次のいずれかを使用します。
+  **アクセスエントリポリシー**: 追加の管理ポリシーをアクセスエントリに関連付けます。
+  **Kubernetes RBAC**: 機能の Kubernetes ユーザーに対して `Role` または `ClusterRole` バインディングを作成します。

 **ACK シークレット読み取りアクセス許可** 

ACK コントローラーによっては、データベースパスワードなどの機密データを取得するために Kubernetes シークレットを読み取る必要があります。次の ACK コントローラーでは、シークレット読み取りアクセスが必要です。
+  `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager` 

シークレット読み取りアクセス許可を付与するには:

1. `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` アクセスエントリポリシーを機能のアクセスエントリに関連付けます。

1. ACK リソースがシークレットを参照するか、クラスター全体のアクセスを許可する、特定の名前空間にポリシーの範囲を限定します。

**重要**  
シークレット読み取りアクセス許可の範囲は、アクセスエントリポリシーを関連付けるときに指定する名前空間に限定されます。これにより、機能がどのシークレットにアクセスできるかを制限できます。

<a name="kro-resource-permissions"></a> **kro による任意のリソースアクセス許可** 

kro には、ResourceGraphDefinitions に定義されたリソースを作成および管理するためのアクセス許可が必要です。デフォルトでは、kro は RGD 自体を監視および管理できるだけです。

kro にリソースを作成するためのアクセス許可を付与するには:

 **オプション 1: アクセスエントリポリシー** 

`AmazonEKSAdminPolicy` や `AmazonEKSEditPolicy` などの事前定義済みのアクセスエントリポリシーを機能のアクセスエントリに関連付けます。

 **オプション 2: Kubernetes RBAC** 

`ClusterRoleBinding` を作成して、機能の Kubernetes ユーザーに必要なアクセス許可を付与します。

```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-cluster-admin
subjects:
- kind: User
  name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
```

**注記**  
kro の Kubernetes ユーザー名は、`arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO` というパターンに従います。  
セッション名 `/KRO` (大文字) は、EKS kro 機能によって自動的に設定されます。

## 機能で必要な IAM アクセス許可
<a name="_iam_permissions_required_by_capability"></a>

 **kro (Kube Resource Orchestrator)**   
必須の IAM アクセス許可はありません。ポリシーをアタッチせずに機能ロールを作成できます。kro に必要なのは Kubernetes RBAC アクセス許可のみです。

 **ACK (Kubernetes 用 AWS コントローラー)**   
ACK が作成および管理する AWS リソースを管理するためのアクセス許可が必要です。要件に基づいて、特定のサービス、アクション、リソースに対するアクセス許可の範囲を限定する必要があります。IAM ロールセレクターによる本番稼働のベストプラクティスなど、ACK アクセス許可の設定の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。

 **Argo CD**   
デフォルトでは、必須の IAM アクセス許可はありません。以下のものには、オプションでアクセス許可が必要になる場合があります。  
+  AWS Secrets Manager: Git リポジトリ認証情報を Secrets Manager に保存する場合
+  AWS CodeConnections: Git リポジトリの認証に CodeConnections を使用する場合
+ Amazon ECR: Amazon ECR に OCI 形式で保存された Helm チャートを使用する場合

## セキュリティのベストプラクティス
<a name="_security_best_practices"></a>

### IAM 最小特権
<a name="_iam_least_privilege"></a>

ユースケースに必要なアクセス許可のみを機能リソースに付与します。これは、機能には必要に応じて広範な管理アクセス許可を付与できないという意味ではありません。このような場合は、そうしたリソースに対するアクセスを適切に管理する必要があります。

 **機能ロール**:
+  **ACK**: 可能であれば、ユースケースと要件に基づいて、チームに必要な特定の AWS サービスとリソースに IAM アクセス許可を制限します。
+  **Argo CD**: 特定の Git リポジトリと Kubernetes 名前空間に対するアクセスを制限します。
+  **kro**: 信頼ポリシーに機能ロールは必要ですが、IAM アクセス許可は必要ありません (クラスター RBAC のみを使用します)。

 **例**: `"Resource": "*"` ではなく、特定のリソースやリソースグループに対するパターンを指定します。

```
"Resource": [
  "arn:aws:s3:::my-app-*",
  "arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```

IAM 条件キーを使用して、アクセスをさらに制限します。

```
"Condition": {
  "StringEquals": {
    "aws:ResourceTag/Environment": "production"
  }
}
```

IAM 設定の詳細については、各機能の考慮事項に関するセクションを参照してください。

### Argo CD シークレットの名前空間の分離
<a name="_namespace_isolation_for_argo_cd_secrets"></a>

マネージド Argo CD 機能は、自身に設定された名前空間内のすべての Kubernetes シークレットにアクセスできます (デフォルト: `argocd`)。最適なセキュリティ体制を維持するには、名前空間の分離に関する以下のプラクティスに従ってください。
+ Argo CD 関連のシークレットのみを Argo CD 名前空間内に保持します。
+ 無関係なアプリケーションシークレットを Argo CD と同じ名前空間に保存しないようにします。
+ Argo CD オペレーションに必要ないアプリケーションシークレットには別の名前空間を使用します。

この分離により、Argo CD のシークレットアクセスは、Git リポジトリの認証やその他の Argo CD に固有のオペレーションに必要な認証情報のみに制限されます。

### Kubernetes RBAC
<a name="_kubernetes_rbac"></a>

機能リソースを作成および管理できるユーザーおよびサービスアカウントを制御します。ここでのベストプラクティスは、適切な RBAC ポリシーに沿って専用の名前空間に機能リソースをデプロイすることです。

例: ACK で RBAC ロールを使用して、`app-team` 名前空間で S3 バケットリソースを管理できるようにします。

```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ack-s3-manager
  namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
  resources: ["buckets"]
  verbs: ["get", "list", "create", "update", "delete"]
```

### 監査ログ
<a name="_audit_logging"></a>

 **CloudTrail**: すべての EKS Capability API オペレーション (作成、更新、削除) が AWS CloudTrail に記録されます。

CloudTrail ログ記録では以下を追跡できます。
+ 誰が機能を作成または変更したか
+ いつ機能設定が変更されたか
+ どのような機能ロールが使用されているか

### ネットワークアクセスおよび VPC エンドポイント
<a name="_network_access_and_vpc_endpoints"></a>

#### プライベート Argo CD API アクセス
<a name="_private_argo_cd_api_access"></a>

Argo CD API サーバーへのアクセスを制限するには、ホストされた Argo CD エンドポイントに 1 つ以上の VPC エンドポイントを関連付けます。これにより、パブリックインターネットを経由することなく、VPC 内からのプライベート接続が可能になります。VPC エンドポイントは、Argo CD ウェブ UI と Argo CD API (CLI アクセスを含む) の両方へのアクセスを提供します。

**注記**  
ホストされた Argo CD API エンドポイントに接続されている VPC エンドポイント (eks-capabilities.*region*.amazonaws.com を使用) は、VPC エンドポイントポリシーをサポートしていません。

#### プライベートクラスターにデプロイする
<a name="_deploying_to_private_clusters"></a>

Argo CD 機能ではアプリケーションを完全にプライベートな EKS クラスターにデプロイできるため、VPC ピアリングや複雑なネットワーク設定が不要になり、運用面で大きなメリットが得られます。ただし、このアーキテクチャを設計するときは、Argo CD が Git リポジトリ (パブリックの場合あり) から設定をプルして、プライベートクラスターに適用するようにすることを検討してください。

以下の点を確認します。
+ 機密のワークロードにプライベートな Git リポジトリを使用している
+ Git リポジトリに適切なアクセスコントロールと認証を実装している
+ マージする前にプルリクエストを通じて変更を確認のうえ承認している
+ Argo CD の同期期間を使用してデプロイのタイミングを制御することを検討している
+ Argo CD 監査ログをモニタリングして不正な設定変更がないか確認している

### コンプライアンス
<a name="_compliance"></a>

EKS 機能は、完全マネージド型で、Amazon EKS のコンプライアンス認定を受けています。

現在のコンプライアンス情報については、「[コンプライアンスプログラムによる対象範囲内の AWS サービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。

## 次のステップ
<a name="_next_steps"></a>
+  [ACK アクセス許可を設定する](ack-permissions.md) - ACK 用に IAM アクセス許可を設定する
+  [kro アクセス許可の設定](kro-permissions.md) - kro 用に Kubernetes RBAC を設定する
+  [Argo CD アクセス許可を設定する](argocd-permissions.md) - Argo CD 用にアイデンティティセンター統合を設定する
+  [EKS 機能をトラブルシューティングする](capabilities-troubleshooting.md) - セキュリティとアクセス許可の問題をトラブルシューティングする