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

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

# ACK アクセス許可を設定する
<a name="ack-permissions"></a>

自分の代わりに ACK で AWS リソースを作成および管理できるようにするには、IAM アクセス許可が必要です。このトピックでは、IAM が ACK でどのように機能するかを説明し、さまざまなユースケースに合わせてアクセス許可を設定する際のガイダンスを示します。

## IAM は ACK でどのように機能するか
<a name="_how_iam_works_with_ack"></a>

ACK は、IAM ロールを使用して AWS で認証し、リソースに対してアクションを実行します。ACK にアクセス許可を付与する方法が 2 つあります。

 **機能ロール**: ACK 機能の作成時に指定する IAM ロールです。このロールは、デフォルトではすべての ACK オペレーションに使用されます。

 **IAM ロールセレクター**: 特定の名前空間またはリソースにマッピングできる追加の IAM ロールです。これらのロールの範囲内にあるリソースの機能ロールは上書きされます。

リソースを作成または管理する必要があるときに、ACK はどの IAM ロールを使用するかを決定します。

1. IAMRoleSelector がリソースの名前空間に一致するかどうかを確認します。

1. 一致した場合、その IAM ロールを引き受けます。

1. 一致しない場合、機能ロールを使用します。

このアプローチにより、シンプルな単一ロールセットアップから複雑なマルチアカウントかつマルチチームの設定まで、アクセス許可を柔軟に管理できます。

## 使用開始: シンプルなアクセス許可セットアップ
<a name="_getting_started_simple_permission_setup"></a>

開発、テスト、またはシンプルなユースケースの場合、必要なすべてのサービスアクセス許可を機能ロールに直接追加できます。

このアプローチは、次の場合に適しています。
+ ACK の使用を開始している
+ すべてのリソースが同じ AWS アカウントにある
+ 1 つのチームがすべての ACK リソースを管理する
+ すべての ACK ユーザーに同じアクセス許可が付与されていると確信している

## 本番稼働でのベストプラクティス: IAM ロールセレクター
<a name="_production_best_practice_iam_role_selectors"></a>

本番稼働環境では、IAM ロールセレクターを使用して、最小特権のアクセスと名前空間レベルでの分離を実装します。

IAM ロールセレクターを使用する場合、機能ロールに必要なアクセス許可はサービス固有のロールを引き受けるための `sts:AssumeRole` および `sts:TagSession` アクセス許可だけです。機能ロール自体に AWS サービスアクセス許可 (S3 や RDS など) を追加する必要はありません。そうしたアクセス許可は、機能ロールが引き受ける個々の IAM ロールに付与します。

 **アクセス許可モデルを選択する**:

次の場合は、**直接アクセス許可** (機能ロールにサービスアクセス許可を追加すること) を使用します。
+ 使用を開始し、最もシンプルなセットアップにする場合
+ すべてのリソースがクラスターと同じアカウントにある場合
+ クラスター全体の管理アクセス許可を必要とする場合
+ すべてのチームが同じアクセス許可を共有できる場合

次の場合は、**IAM ロールセレクター**を使用します。
+ 複数の AWS アカウント全体のリソースを管理する場合
+ チームや名前空間ごとに異なるアクセス許可が必要な場合
+ 名前空間ごとにきめ細かなアクセスコントロールが必要な場合
+ 最小特権のセキュリティプラクティスに従う場合

直接アクセス許可から開始し、その後、要件の増大に応じて IAM ロールセレクターに移行できます。

 **なぜ本番稼働で IAM ロールセレクターを使用するのか:** 
+  **最小特権**: 名前空間ごとに必要なアクセス許可のみを取得します。
+  **チーム分離**: チーム A が誤ってチーム B のアクセス許可を使用することがないようにします。
+  **容易な監査**: どの名前空間がどのロールを使用するかを明確にマッピングします。
+  **クロスアカウントサポート**: 複数のアカウントのリソースを管理する場合に必要です。
+  **関心の分離**: サービスや環境ごとに異なるロールを使用します。

### 基本的な IAM ロールセレクターのセットアップ
<a name="_basic_iam_role_selector_setup"></a>

 **ステップ 1: サービス固有の IAM ロールを作成する** 

特定の AWS サービスに対するアクセス許可を付与した IAM ロールを作成します。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": "*"
    }
  ]
}
```

機能ロールに引き受けられるように信頼ポリシーを設定します。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
      },
      "Action": ["sts:AssumeRole", "sts:TagSession"]
    }
  ]
}
```

 **ステップ 2: AssumeRole アクセス許可を機能ロールに付与する** 

サービス固有のロールを引き受けるためのアクセス許可を機能ロールに追加します。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["sts:AssumeRole", "sts:TagSession"],
      "Resource": "arn:aws:iam::111122223333:role/ACK-S3-Role"
    }
  ]
}
```

 **ステップ 3: IAMRoleSelector を作成する** 

名前空間に IAM ロールをマッピングします。

```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
  name: s3-namespace-config
spec:
  arn: arn:aws:iam::111122223333:role/ACK-S3-Role
  namespaceSelector:
    names:
      - s3-resources
```

 **ステップ 4: マッピングした名前空間にリソースを作成する** 

`s3-resources` 名前空間内のリソースは、指定されたロールを自動的に使用します。

```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: my-bucket
  namespace: s3-resources
spec:
  name: my-production-bucket
```

## マルチアカウント管理
<a name="_multi_account_management"></a>

IAM ロールセレクターを使用すると、複数の AWS アカウントのリソースを管理できます。

 **ステップ 1: クロスアカウント IAM ロールを作成する** 

ターゲットアカウント (444455556666) に、ソースアカウントの機能ロールを信頼するロールを作成します。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
      },
      "Action": ["sts:AssumeRole", "sts:TagSession"]
    }
  ]
}
```

このロールにサービス固有のアクセス許可をアタッチします。

 **ステップ 2: AssumeRole アクセス許可を付与する** 

ソースアカウント (111122223333) で、機能ロールがターゲットアカウントロールを引き受けられるようにします。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["sts:AssumeRole", "sts:TagSession"],
      "Resource": "arn:aws:iam::444455556666:role/ACKTargetAccountRole"
    }
  ]
}
```

 **ステップ 3: IAMRoleSelector を作成する** 

名前空間にクロスアカウントロールをマッピングします。

```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
  name: production-account-config
spec:
  arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
  namespaceSelector:
    names:
      - production
```

 **ステップ 4: リソースを作成する** 

`production` 名前空間内のリソースは、ターゲットアカウントに作成します。

```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: my-bucket
  namespace: production
spec:
  name: my-cross-account-bucket
```

## セッションタグ
<a name="_session_tags"></a>

EKS ACK 機能は、すべての AWS API リクエストにセッションタグを自動的に設定します。これらのタグは、各リクエストのソースを特定することで、きめ細かなアクセスコントロールと監査を可能にします。

### 利用可能なセッションタグ
<a name="_available_session_tags"></a>

ACK によって行われるすべての AWS API コールには、次のセッションタグが含まれています。


| タグキー | 説明 | 
| --- | --- | 
|   `eks:eks-capability-arn`   |  リクエストを行う EKS 機能の ARN  | 
|   `eks:kubernetes-namespace`   |  管理対象のリソースの Kubernetes 名前空間  | 
|   `eks:kubernetes-api-group`   |  リソースの Kubernetes API グループ (例: `s3.services.k8s.aws`)  | 

### セッションタグを使用したアクセス制御
<a name="_using_session_tags_for_access_control"></a>

これらのセッションタグを IAM ポリシー条件で使用して、ACK が管理できるリソースを制限できます。これにより、名前空間ベースの IAM ロールセレクターに加えて追加セキュリティレイヤーが設定されます。

 **例: 名前空間による制限** 

リクエストが `production` 名前空間から発信された場合にのみ、ACK が S3 バケットを作成できるようにします。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/eks:kubernetes-namespace": "production"
        }
      }
    }
  ]
}
```

 **例: 機能による制限** 

特定の ACK 機能からのアクションのみを許可します。

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/eks:eks-capability-arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack"
        }
      }
    }
  ]
}
```

**注記**  
セッションタグは、デフォルトでこれらのタグを設定しないセルフマネージド ACK とは異なります。これにより、マネージド機能によるより詳細なアクセスコントロールが可能になります。

## 高度な IAM ロールセレクターパターン
<a name="_advanced_iam_role_selector_patterns"></a>

ラベルセレクターやリソース固有のロールマッピングなどの例に見られる高度な設定については、「[ACK IRSA ドキュメント](https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/)」を参照してください。

## 次のステップ
<a name="_next_steps"></a>
+  [ACK の概念](ack-concepts.md) - ACK の概念およびリソースライフサイクルを理解する
+  [ACK の概念](ack-concepts.md) - リソースの採用と削除ポリシーについて学ぶ
+  [EKS 機能のセキュリティに関する考慮事項](capabilities-security.md) - 機能のセキュリティベストプラクティスを理解する