**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS 機能 IAM ロール
EKS 機能には、機能 IAM ロール (または機能ロール) を設定する必要があります。機能は、このロールを使用して AWS サービスに対してアクションを実行し、自動的に作成されたアクセスエントリを介してクラスター内の Kubernetes リソースにアクセスします。
機能の作成時に機能ロールを指定する場合は、事前に IAM ロールを作成してその機能のタイプに適した信頼ポリシーとアクセス許可を付与する必要があります。このように作成した IAM ロールは、任意の数の機能リソースで再利用できます。
## 機能ロールの要件
機能ロールは、以下の要件を満たしている必要があります。
+ クラスターおよび機能リソースと同じ AWS アカウントに存在する必要があります
+ 信頼ポリシーにより、EKS 機能サービスがロールを引き受けることを許可する必要があります。
+ 機能タイプとユースケースの要件に適したアクセス許可を付与する必要があります (「[機能タイプ別のアクセス許可](#capability-permissions)」を参照)。
## 機能ロールの信頼ポリシー
すべての機能ロールに、次の信頼ポリシーを含める必要があります。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
この信頼ポリシーにより、EKS は以下のことを行うことができます。
+ AWS API オペレーションを実行するロールを引き受けます。
+ 監査と追跡の目的でセッションにタグを付けます。
## 機能タイプ別のアクセス許可
必要な IAM アクセス許可は、使用している機能と現在のデプロイモデルによって異なります。
**注記**
本番稼働でのデプロイに IAM ロールセレクターと ACK を使用する場合や、AWS サービスを統合することなく kro または Argo CD を使用する場合、機能ロールには信頼ポリシー以外に IAM アクセス許可は必要ありません。
**kro (Kube Resource Orchestrator)**
必須の IAM アクセス許可はありません。ポリシーをアタッチせずに機能ロールを作成できます。kro に必要なのは Kubernetes リソースを作成および管理するための Kubernetes RBAC アクセス許可のみです。
**Kubernetes 用 AWS コントローラー (ACK)**
ACK は、2 つのアクセス許可モデルをサポートしています。
+ **シンプルなセットアップ (開発/テスト)**: AWS サービスアクセス許可を機能ロールに直接追加します。これは、使用を開始する場合、シングルアカウントでデプロイする場合、またはすべてのユーザーに同じアクセス許可が必要な場合に適しています。
+ **本番稼働のベストプラクティス**: IAM ロールセレクターを使用して最小特権のアクセスを実装します。このアプローチで機能ロールに必要なのは、サービス固有のロールを引き受ける `sts:AssumeRole` アクセス許可のみです。機能ロール自体に AWS サービスアクセス許可 (S3 や RDS など) を追加しないでください。そうしたアクセス許可は、特定の名前空間にマッピングされた個々の IAM ロールに付与します。
IAM ロールセレクターにより、以下のことを行うことができます。
+ 名前空間レベルでのアクセス許可の分離
+ クロスアカウントリソース管理
+ チームに固有の IAM ロール
+ 最小特権セキュリティモデル
IAM ロールセレクターによるアプローチでの機能ロールポリシーの例:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
IAM ロールセレクターなど ACK アクセス許可の詳細な設定については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
**Argo CD**
デフォルトでは、必須の IAM アクセス許可はありません。以下のものには、オプションでアクセス許可が必要になる場合があります。
+ **AWS Secrets Manager**: Secrets Manager を使用して Git リポジトリ認証情報を保存する場合
+ **AWS CodeConnections**: Git リポジトリの認証に CodeConnections を使用する場合
Secrets Manager と CodeConnections のポリシーの例:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Argo CD アクセス許可要件の詳細については、「[Argo CD に関する考慮事項](argocd-considerations.md)」を参照してください。
## 既存の機能ロールを確認する
アカウントに既にユースケースに適した機能 IAM ロールがあるかどうかを確認するには、次の手順を使用できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストを検索して、機能ロール名 (`ACKCapabilityRole` や `ArgoCDCapabilityRole` など) を確認します。
1. ロールが存在する場合は、そのロールを選択して、アタッチされたポリシーおよび信頼関係を表示します。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係が[機能信頼ポリシー](#capability-trust-policy)と一致することを確認します。一致しない場合は、信頼ポリシーを更新します。
1. **[アクセス許可]** を選択し、ロールに機能タイプとユースケースに適したアクセス許可が付与されていることを確認します。
## 機能 IAM ロールを作成する
AWS マネジメントコンソール または AWS CLI を使用して、機能ロールを作成できます。
** AWS マネジメントコンソール **
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. **[信頼されたエンティティタイプ]** で、**[カスタム信頼ポリシー]** を選択します。
1. [機能信頼ポリシー](#capability-trust-policy)をコピーして、信頼ポリシーエディタに貼り付けます。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** タブで、機能タイプに適したポリシーを選択または作成します (「[機能タイプ別のアクセス許可](#capability-permissions)」を参照)。kro では、このステップをスキップできます。
1. [**次へ**] を選択します。
1. **[ロール名]** に、`ACKCapabilityRole`、`ArgoCDCapabilityRole`、`kroCapabilityRole` などロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - ACK capability role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
**AWS CLI**
1. [機能信頼ポリシー](#capability-trust-policy)を `capability-trust-policy.json` という名前のファイルにコピーします。
1. ロールを作成します。`ACKCapabilityRole` を目的のロール名で置き換えます。
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. 必要な IAM ポリシーをロールにアタッチします。ACK の場合、管理する AWS サービスのポリシーをアタッチします。Argo CD の場合、必要に応じて Secrets Manager または CodeConnections のポリシーをアタッチします。kro では、このステップをスキップできます。
ACK に S3 アクセス許可を付与した例:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## 機能ロールの問題をトラブルシューティングする
**機能の作成が「無効な IAM ロール」で失敗する**
以下を確認してください。
+ ロールがクラスターと同じアカウントに存在する
+ 信頼ポリシーが[機能信頼ポリシー](#capability-trust-policy)と一致する
+ ロールに `iam:PassRole` アクセス許可が付与されている
**機能でアクセス許可エラーが表示される**
以下を確認してください。
+ ロールに、機能タイプに必要な IAM アクセス許可が付与されている
+ ロールのアクセスエントリがクラスターに存在する
+ 必要に応じて追加の Kubernetes アクセス許可が設定される (「[その他の Kubernetes アクセス許可](capabilities-security.md#additional-kubernetes-permissions)」を参照)
**ACK リソースが「アクセス許可が拒否されました」というエラーで失敗する**
以下を確認してください。
+ ロールに、ユースケースに必要な IAM アクセス許可が付与されている
+ ACK コントローラーがシークレットを参照する場合、適切な名前空間に範囲が限定された `AmazonEKSSecretReaderPolicy` アクセスエントリポリシーを関連付けていることを確認します。
トラブルシューティングの詳しいガイダンスについては、「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。