# Amazon Elastic Container Service のセキュリティ
AWS ではクラウドセキュリティが最優先事項です。セキュリティを最も重視する組織の要件を満たすために構築された 「AWS」 のデータセンターとネットワークアーキテクチャは、お客様に大きく貢献します。
セキュリティは、「AWS」 と顧客の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、この責任がクラウド*の*セキュリティおよびクラウド*内*のセキュリティとして説明されています。
+ **クラウドのセキュリティ** - 「AWS」は、「AWS」クラウドで「AWS」のサービスを実行するインフラストラクチャを保護する責任を負います。また、「AWS」は、使用するサービスを安全に提供します。[「AWS」 コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。Amazon Elastic Container Service, に適用されるコンプライアンスプログラムについては、[コンプライアンスプログラムによる対象範囲内のAWSサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** - ユーザーの責任は、使用する AWS のサービスに応じて異なります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、Amazon ECS 使用時における責任共有モデルの適用法を理解するのに役立ちます。以下のトピックでは、セキュリティとコンプライアンスの目的を満たすように Amazon ECS を設定する方法について説明します。Amazon ECS リソースのモニタリングやセキュリティ確保に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [Amazon Elastic コンテナサービスのアイデンティティ とアクセス管理](security-iam.md)
+ [Amazon Elastic Container Service でのログとモニタリング](ecs-logging-monitoring.md)
+ [Amazon Elastic Container Service でのコンプライアンス検証](ecs-compliance.md)
+ [AWS Fargate 連邦情報処理標準 (FIPS-140)](ecs-fips-compliance.md)
+ [Amazon Elastic Container Service におけるインフラストラクチャセキュリティ](infrastructure-security.md)
+ [Amazon ECS の AWS 責任共有モデル。](security-shared-model.md)
+ [Amazon ECS マネージドインスタンスの責任共有モデル](security-shared-model-managed-instances.md)
+ [Amazon ECS のネットワークセキュリティのベストプラクティス](security-network.md)
+ [Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス](security-tasks-containers.md)
# Amazon Elastic コンテナサービスのアイデンティティ とアクセス管理
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービス です。IAM 管理者は、誰を*認証* (サインイン) し、誰に Amazon ECS リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、追加費用なしで使用できる AWS のサービス です。
**Topics**
+ [対象者](#security_iam_audience)
+ [アイデンティティによる認証](#security_iam_authentication)
+ [ポリシーを使用したアクセス権の管理](#security_iam_access-manage)
+ [IAM を使用するAmazon Elastic Container Service](security_iam_service-with-iam.md)
+ [Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)
+ [Amazon Elastic Container Service に関する AWS 管理ポリシー](security-iam-awsmanpol.md)
+ [Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)
+ [Amazon ECS の IAM ロール](security-ecs-iam-role-overview.md)
+ [Amazon ECS コンソールに必要なアクセス許可](console-permissions.md)
+ [Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)
+ [Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)
+ [リソース作成時にタグ付けするための許可を付与する](supported-iam-actions-tagging.md)
+ [Amazon Elastic Container Service のアイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ [Amazon ECS の IAM ベストプラクティス](security-iam-bestpractices.md)
## 対象者
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Amazon Elastic Container Service のアイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[IAM を使用するAmazon Elastic Container Service](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティによる認証
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、IAM ユーザー の AWS アカウントのルートユーザー として、または IAM ロールを引き受けることによって、認証される 必要があります。
AWS IAM アイデンティティセンター (IAM アイデンティティセンター)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント のルートユーザー
AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS のサービス にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。
*フェデレーテッドアイデンティティ*は、エンタープライズディレクトリ、ウェブ ID プロバイダー、Directory Service のユーザーであり、ID ソースからの認証情報を使用して AWS のサービス にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、AWS IAM アイデンティティセンター をお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)、または AWS CLI や AWS API オペレーションを呼び出すことで、ロールを引き受けることができます。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## ポリシーを使用したアクセス権の管理
AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは、アイデンティティやリソースとの関連付けに伴うアクセス許可を定義します。AWS は、プリンシパルがリクエストを行うときに、これらのポリシーを評価します。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS マネージドポリシーを使用することはできません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプで付与された最大数のアクセス許可を設定できる、追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations 内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド* の [ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) を参照してください。
# IAM を使用するAmazon Elastic Container Service
IAM を使用して Amazon ECS へのアクセスを管理する前に、Amazon ECS で使用できる IAM 機能について理解しておく必要があります。
| IAM 機能 | Amazon ECS サポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | はい |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | なし |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | はい |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | 部分的 |
| [ポリシー条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys) | はい |
| [ACL](#security_iam_service-with-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | はい |
| [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | はい |
| [転送アクセスセッション (FAS)](#security_iam_service-with-iam-principal-permissions) | はい |
| [サービスロール](#security_iam_service-with-iam-roles-service) | はい |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | はい |
大部分の IAM 機能が Amazon ECS および、その他のサービスでどのように機能するかに関するおおまかな説明については、[AWS IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)の「*IAM と連携する AWS のサービス*」を参照してください。
## Amazon ECS のアイデンティティベースの ポリシー
**ID ベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### Amazon ECS の ID ベースのポリシー例
Amazon ECS でのアイデンティティベースのポリシーの例は、「[Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」でご確認ください。
## Amazon ECS 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーションユーザー、または AWS のサービス を含めることができます。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## Amazon ECS のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Amazon ECS アクションのリストを確認するには、「*Service Authorization Reference*」の「[Actions defined by Amazon Elastic Container Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-actions-as-permissions)」を参照してください。
Amazon ECS のポリシーアクションは、アクションの前に以下のプレフィックスを使用します。
```
ecs
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"ecs:action1",
"ecs:action2"
]
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます:
```
"Action": "ecs:Describe*"
```
Amazon ECS でのアイデンティティベースのポリシーの例は、「[Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」でご確認ください。
## Amazon ECS のポリシーリソース
**ポリシーリソースのサポート:** 一部
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Amazon ECS リソースタイプとその ARN のリストを確認するには、「*Service Authorization Reference*」の「[Resources defined by Amazon Elastic Container Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-resources-for-iam-policies)」を参照してください。各リソースの ARN を指定できるアクションについては、「[Amazon Elastic Container Service で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-actions-as-permissions)」を参照してください。
複数のリソースをサポートする Amazon ECS API アクションもあります。例えば、`DescribeClusters` API アクションを呼び出すときに複数のクラスターを参照できます。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。
```
"Resource": [
"EXAMPLE-RESOURCE-1",
"EXAMPLE-RESOURCE-2"
```
例えば、Amazon ECS クラスターリソースの ARN は次のようになります。
```
arn:${Partition}:ecs:${Region}:${Account}:cluster/${clusterName}
```
次の ARN を使用して、ステートメントで `my-cluster-1` および `my-cluster-2` クラスタを指定します。
```
"Resource": [
"arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster-1",
"arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster-2"
```
特定のアカウントに属するすべてのクラスターを指定するには、ワイルドカード (\$1) を使用します。
```
"Resource": "arn:aws:ecs:us-east-1:123456789012:cluster/*"
```
タスク定義では、最新のリビジョンまたは特定のリビジョンを指定できます。
タスク定義のすべてのリビジョンを指定するには、ワイルドカード (\$1) を使用します。
```
"Resource:arn:${Partition}:ecs:${Region}:${Account}:task-definition/${TaskDefinitionFamilyName}:*"
```
特定のタスク定義リビジョンを指定する場合は、\$1\$1TaskDefinitionRevisionNumber\$1 を使用します。
```
"Resource:arn:${Partition}:ecs:${Region}:${Account}:task-definition/${TaskDefinitionFamilyName}:${TaskDefinitionRevisionNumber}"
```
Amazon ECS でのアイデンティティベースのポリシーの例は、「[Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」でご確認ください。
## Amazon ECS のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。
Amazon ECS は、以下のサービス固有の条件キーをサポートしており、IAM ポリシーのきめ細かいフィルタリングの提供に使用することができます。
| 条件キー | 説明 | 評価の種類 |
| --- | --- | --- |
| aws:RequestTag/\$1\$1TagKey\$1 | コンテキストキーは `"aws:RequestTag/tag-key":"tag-value"` という形式です。ここで *tag-key* および *tag-value* はタグキーと値のペアです。 タグキーと値のペアが AWS リクエストに含まれていることを確認します。例えば、リクエストに「`"Dept"`」タグキーが含まれ、「`"Accounting"`」という値が含まれているかどうかを確認できます。 | String |
| aws:ResourceTag/\$1\$1TagKey\$1 | コンテキストキーは `"aws:ResourceTag/tag-key":"tag-value"` という形式です。ここで *tag-key* および *tag-value* はタグキーと値のペアです。 リソース (ユーザーまたはロール) を識別するためにアタッチされたタグが、指定されたキーの名前および値と一致するかどうかをチェックします。 | String |
| aws:TagKeys | このコンテキストキーは `"aws:TagKeys":"tag-key"` という形式であり、ここで *tag-key* は値 (`["Dept","Cost-Center"]` など) のないタグキーのリストです。 AWS リクエストに存在するタグキーをチェックします。 | String |
| ecs:ResourceTag/\$1\$1TagKey\$1 | コンテキストキーは `"ecs:ResourceTag/tag-key":"tag-value"` という形式です。ここで *tag-key* および *tag-value* はタグキーと値のペアです。 リソース (ユーザーまたはロール) を識別するためにアタッチされたタグが、指定されたキーの名前および値と一致するかどうかをチェックします。 | String |
| ecs:account-setting | コンテキストキーは `"ecs:account-setting":"account-setting"` という形式で、*account-setting* はアカウント設定の名前です。 | String |
| ecs:auto-assign-public-ip | コンテキストキーは"ecs:auto-assign-public-ip":"value" 形式であり、value- は「true」または「false」です。 | String |
| ecs:capacity-provider | コンテキストキーは `"ecs:capacity-provider":"capacity-provider-arn"` という形式で、*capacity-provider-arn* はキャパシティープロバイダーの ARN です。 | ARN、Null |
| ecs:cluster | コンテキストキーは `"ecs:cluster":"cluster-arn"` という形式です。ここで *cluster-arn* は、Amazon ECS クラスターの ARN です。 | ARN、Null |
| ecs:compute-compatability | コンテキストキーは "ecs:compute-compatability":"compatability-type" という形式で、 compatability-type は「FARGATE」、「EC2」、または「EXTERNAL」です。 | String |
| ecs:container-instances | コンテキストキーは `"ecs:container-instances":"container-instance-arns"` という形式です。ここで *container-instance-arns* は、1 つ以上のコンテナインスタンス ARN です。 | ARN、Null |
| ecs:container-name | コンテキストキーは `"ecs:container-name":"container-name"` 形式で、*container-instan-* は、タスク定義で定義されている Amazon ECS コンテナの名前です。 | String |
| ecs:enable-execute-command | コンテキストキーは"ecs:enable-execute-command":"value" 形式であり、value- は「true」または「false」です。 | String |
| ecs:enable-service-connect | コンテキストキーは `"ecs:enable-service-connect":"value"` 形式であり、*value* は `"true"` または `"false"` です。 | String |
| ecs:enable-ebs-volumes | コンテキストキーは `"ecs:enable-ebs-volumes":"value"` 形式であり、*value* は `"true"` または `"false"` です。 | String |
| ecs:enable-managed-tags | コンテキストキーは `"ecs:enable-managed-tags":"value"` 形式であり、*value* は `"true"` または `"false"` です。 | String |
| ecs:enable-vpc-lattice | コンテキストキーは `"ecs:vpc-lattice":"value"` 形式であり、*value* は `"true"` または `"false"` です。 | String |
| ecs:fargate-ephemeral-storage-kms-key | コンテキストキーは `"ecs:fargate-ephemeral-storage-kms-key":"key"` という形式で、*キー*は AWS KMS キーの ID です。 | String |
| ecs:namespace | コンテキストキーは `"ecs:namespace":"namespace-arn"` 形式であり、*namespace-arn* は AWS Cloud Map 名前空間の ARN です。 | ARN、Null |
| ecs:propagate-tags | コンテキストキーは `"ecs:propagate-tags":"value"` という形式で、*値*は `"TASK_DEFINITION"`、`"SERVICE"`、または `"NONE"` です。 | String |
| ecs:service | コンテキストキーは `"ecs:service":"service-arn"` という形式です。ここで *service-arn* は、Amazon ECS サービスの ARN です。 | ARN、Null |
| ecs:task-definition | コンテキストキーは `"ecs:task-definition":"task-definition-arn"` という形式です。ここで *task-definition-arn* は、Amazon ECS タスク定義の ARN です。 | ARN、Null |
| ecs:subnet | コンテキストキーは `"ecs:subnet":"subnets"` という形式で、*サブネット*は `awsvpc` モードを使用するタスクまたはサービスのサブネットです。 | String |
| ecs:task | コンテキストキーは `"ecs:task":"task-arn"` という形式で、*task-arn* は、Amazon ECS サービスの ARN です。 | ARN、Null |
| ecs:task-cpu | コンテキストキーは "ecs:task-cpu":"task-cpu" という形式で、task-cpu はタスク CPU で、1024 = 1 vCPU の整数です。 | 整数 |
| ecs:task-memory | コンテキストキーは "ecs:task-memory":"task-memory" という形式で、task-memory は MiB のタスクメモリです。 | 整数 |
Amazon ECS 条件キーのリストを確認するには、「*Service Authorization Reference*」の「[Condition keys for Amazon Elastic Container Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、「[Amazon Elastic Container Service で定義するアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-actions-as-permissions)」を参照してください。
Amazon ECS でのアイデンティティベースのポリシーの例は、「[Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」でご確認ください。
## Amazon ECS アクセスコントロールリスト (ACL)
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Amazon ECS での属性ベースのアクセスコントロール (ABAC)
**重要**
Amazon ECS は、すべての Amazon ECS リソースに対して属性ベースのアクセスコントロールをサポートしています。属性を使用してアクションの範囲を設定できるかどうかを判断するには、「*サービス許可リファレンス*」の「[Amazon Elastic Container Service で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-actions-as-permissions)」の表を参照してください。まず、**リソース**列にリソースがあることを確認します。次に、**[条件キー]**列を使用して、アクションとリソースの組み合わせのキーを確認します。
**ABAC (ポリシー内のタグ) のサポート:** あり
属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグを付けることで、プリンシパルのタグがリソースタグと一致するときに操作を許可する ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
Amazon ECS リソースのタグ付けの詳細については、「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。
リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースポリシーの例を表示するには、「[タグに基づき、Amazon ECS サービスを記述する](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-cluster-tags)」を参照してください。
## Amazon ECS での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は、AWSリソースへの短期的なアクセスを提供し、フェデレーションの使用時またはロールの切り替え時に自動的に作成されます。AWS では、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Amazon ECS のフォワードアクセスセッション
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、AWS のサービス を呼び出すプリンシパルのアクセス許可を AWS のサービス のリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Amazon ECS のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールの許可を変更すると、Amazon ECS の機能が破損する可能性があります。Amazon ECS が指示する場合以外は、サービスロールを編集しないでください。
## Amazon ECS のサービスにリンクされたロール
**サービスリンクロールのサポート:** あり
サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
Amazon ECS でのサービスにリンクされたロールの作成または管理の詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
# Amazon Elastic Container Service のアイデンティティベースのポリシーの例
デフォルトでは、ユーザーおよびロールにはAmazon ECS リソースを作成または変更する許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
Amazon ECS が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*Service Authorization Reference*」の「[Actions, resources, and condition keys for Amazon Elastic Container Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html)」を参照してください。
**Topics**
+ [Amazon ECS ポリシーのベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [自分のアクセス許可の表示を Amazon ECS ユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Amazon ECS クラスターの例](#IAM_cluster_policies)
+ [Amazon ECS コンテナインスタンスの例](#IAM_container_instance_policies)
+ [Amazon ECS タスク定義の例](#IAM_task_definition_policies)
+ [Amazon ECS タスク実行の例](#IAM_run_policies)
+ [Amazon ECS タスク開始の例](#IAM_start_policies)
+ [Amazon ECS のタスクの例を一覧表示して説明する](#IAM_task_policies)
+ [Amazon ECS サービス作成の例](#IAM_create_service_policies)
+ [タグに基づき、Amazon ECS サービスを記述する](#security_iam_id-based-policy-examples-view-cluster-tags)
+ [Amazon ECS Service Connect 名前空間の上書き拒否の例](#IAM_disable_namespace_override_policies)
## Amazon ECS ポリシーのベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内で誰かが Amazon ECS リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、AWS アカウント に費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## 自分のアクセス許可の表示を Amazon ECS ユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI か AWS API を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Amazon ECS クラスターの例
次の IAM ポリシーでは、クラスターを作成し、記載したアクセス権限を付与します。`CreateCluster` と `ListClusters` のアクションはリソースを受け入れないため、すべてのリソースでリソース定義は `*` に設定されます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:ListClusters"
],
"Resource": "*"
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:DescribeClusters",
"ecs:DeleteCluster"
],
"Resource": ["arn:aws:ecs:us-east-1:123456789012:cluster/cluster-name"]
}
]
}
```
------
次の IAM ポリシーでは、特定のクラスターに記述、および削除するアクセス権限を付与します。`DescribeClusters` と `DeleteCluster` のアクションはリソースとしてクラスター ARN を使用します。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Action": [
"ecs:Describe*",
"ecs:List*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ecs:DeleteCluster",
"ecs:DeregisterContainerInstance",
"ecs:ListContainerInstances",
"ecs:RegisterContainerInstance",
"ecs:SubmitContainerStateChange",
"ecs:SubmitTaskStateChange"
],
"Effect": "Allow",
"Resource": "arn:aws:ecs:us-east-1:123456789012:cluster/default"
},
{
"Action": [
"ecs:DescribeContainerInstances",
"ecs:DescribeTasks",
"ecs:ListTasks",
"ecs:UpdateContainerAgent",
"ecs:StartTask",
"ecs:StopTask",
"ecs:RunTask"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"ArnEquals": {"ecs:cluster": "arn:aws:ecs:us-east-1:123456789012:cluster/default"}
}
}
]
}
```
------
次の IAM ポリシーは、ユーザーまたはグループが特定のクラスターでのオペレーションの実行のみを許可するユーザーまたはグループにアタッチできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ecs:Describe*",
"ecs:List*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ecs:DeleteCluster",
"ecs:DeregisterContainerInstance",
"ecs:ListContainerInstances",
"ecs:RegisterContainerInstance",
"ecs:SubmitContainerStateChange",
"ecs:SubmitTaskStateChange"
],
"Effect": "Allow",
"Resource": "arn:aws:ecs:us-east-1:111122223333:cluster/default"
},
{
"Action": [
"ecs:DescribeContainerInstances",
"ecs:DescribeTasks",
"ecs:ListTasks",
"ecs:UpdateContainerAgent",
"ecs:StartTask",
"ecs:StopTask",
"ecs:RunTask"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"ArnEquals": {"ecs:cluster": "arn:aws:ecs:us-east-1:111122223333:cluster/default"}
}
}
]
}
```
------
## Amazon ECS コンテナインスタンスの例
コンテナインスタンス登録は、Amazon ECS エージェントによって処理されますが、ユーザーがクラスターからインスタンスを手動で登録解除を許可する場合があります。コンテナインスタンスを間違ったクラスターに登録、または実行中のタスクがあるインスタンスを誤って終了してしまうかもしれません。
次に示す IAM ポリシーでは、ユーザーが指定したクラスターでコンテナインスタンスをリストし、登録を解除することができます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:DeregisterContainerInstance",
"ecs:ListContainerInstances"
],
"Resource": "arn:aws:ecs:us-east-1:123456789012:cluster/cluster_name"
}
]
}
```
------
## Amazon ECS タスク定義の例
タスク定義 IAM ポリシーは、リソースレベルのアクセス権限をサポートしていませんが、次の IAM ポリシーでは、ユーザーがタスク定義を登録、一覧表示、および記述することができます。
コンソールを使用する場合は、`CloudFormation: CreateStack` を `Action` として追加する必要があります。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:RegisterTaskDefinition",
"ecs:ListTaskDefinitions",
"ecs:DescribeTaskDefinition"
],
"Resource": "*"
}
]
}
```
------
## Amazon ECS タスク実行の例
`RunTask` のリソースは、タスク定義です。ユーザーがタスク定義を実行できるクラスターを制限するには、`Condition` ブロックで指定します。この方法には、適切なアクセス権を許可するためにリソースでタスク定義とクラスターの両方をリストする必要がないという利点があります。いずれか、または両方を適用できます。
次の IAM ポリシーでは、特定のクラスターで特定のタスク定義の変更を実行するアクセス権限を付与します。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["ecs:RunTask"],
"Condition": {
"ArnEquals": {"ecs:cluster": "arn:aws:ecs:us-east-1:123456789012:cluster/cluster_name"}
},
"Resource": ["arn:aws:ecs:us-east-1:123456789012:task-definition/task_family:*"]
}
]
}
```
------
## Amazon ECS タスク開始の例
`StartTask` のリソースは、タスク定義です。ユーザーがタスク定義を開始できるクラスターとコンテナインスタンスを制限するには、`Condition` ブロックでそれらを指定します。この方法には、適切なアクセス権を許可するためにリソースでタスク定義とクラスターの両方をリストする必要がないという利点があります。いずれか、または両方を適用できます。
次の IAM ポリシーでは、特定のクラスターおよび特定のコンテナインスタンスで特定のタスク定義の変更を開始するアクセス許可を付与します。
**注記**
この例では、AWS CLI または別の AWS SDK で `StartTask` API を呼び出すときに、`Resource` マッピングが一致するようにタスク定義リビジョンを指定する必要があります。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["ecs:StartTask"],
"Condition": {
"ArnEquals": {
"ecs:cluster": "arn:aws:ecs:us-east-1:123456789012:cluster/cluster_name",
"ecs:container-instances": ["arn:aws:ecs:us-east-1:123456789012:container-instance/cluster_name/container_instance_UUID"]
}
},
"Resource": ["arn:aws:ecs:us-east-1:123456789012:task-definition/task_family:*"]
}
]
}
```
------
## Amazon ECS のタスクの例を一覧表示して説明する
次の IAM ポリシーでは、ユーザーが指定したクラスターに指定タスクを記述することができます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["ecs:DescribeTasks"],
"Condition": {
"ArnEquals": {"ecs:cluster": "arn:aws:ecs:us-east-1:123456789012:cluster/cluster_name"}
},
"Resource": ["arn:aws:ecs:us-east-1:123456789012:task/cluster_name/task_UUID"]
}
]
}
```
------
## Amazon ECS サービス作成の例
次の IAM; ポリシーでは、ユーザーが AWS マネジメントコンソール で Amazon ECS サービスを作成することができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-autoscaling:Describe*",
"application-autoscaling:PutScalingPolicy",
"application-autoscaling:RegisterScalableTarget",
"cloudwatch:DescribeAlarms",
"cloudwatch:PutMetricAlarm",
"ecs:List*",
"ecs:Describe*",
"ecs:CreateService",
"elasticloadbalancing:Describe*",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:ListAttachedRolePolicies",
"iam:ListRoles",
"iam:ListGroups",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
------
## タグに基づき、Amazon ECS サービスを記述する
アイデンティティベースのポリシーの条件を使用して、タグに基づいて Amazon ECS リソースへのアクセスをコントロールできます。この例では、サービスを表示できるポリシーを作成する方法を示します。ただし、アクセス許可は、サービスタグ `Owner` にそのユーザーのユーザー名の値がある場合のみ、付与されます。このポリシーでは、このアクションをコンソールで実行するために必要なアクセス許可も付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DescribeServices",
"Effect": "Allow",
"Action": "ecs:DescribeServices",
"Resource": "*"
},
{
"Sid": "ViewServiceIfOwner",
"Effect": "Allow",
"Action": "ecs:DescribeServices",
"Resource": "arn:aws:ecs:*:*:service/*",
"Condition": {
"StringEquals": {"ecs:ResourceTag/Owner": "${aws:username}"}
}
}
]
}
```
------
このポリシーをアカウントの IAM ユーザーにアタッチできます。`richard-roe` という名前のユーザーが Amazon ECS サービスを表示する場合は、サービスに `Owner=richard-roe` または `owner=richard-roe` とタグ付けする必要があります。それ以外の場合、アクセスは拒否されます。条件キー名では大文字と小文字が区別されないため、条件タグキー `Owner` は `Owner` と `owner` の両方に一致します。詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
## Amazon ECS Service Connect 名前空間の上書き拒否の例
以下の IAM ポリシーは、サービス設定のデフォルトの Service Connect 名前空間をユーザーが上書きすることを拒否します。デフォルトの名前空間はクラスターに設定されます。ただし、サービス設定内ではそれを上書きできます。一貫性を保つため、新しいサービスはすべて同じ名前空間を使用するように設定することを検討してください。サービスに特定の名前空間を使用するように要求するには、以下のコンテキストキーを使用します。以下の例で、``、``、``、`` を独自のものに置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateService",
"ecs:UpdateService"
],
"Condition": {
"ArnEquals": {
"ecs:cluster": "arn:aws:ecs:us-east-1:123456789012:cluster/cluster_name",
"ecs:namespace": "arn:aws:servicediscovery:us-east-1:123456789012:namespace/namespace_id"
}
},
"Resource": "*"
}
]
}
```
------
# Amazon Elastic Container Service に関する AWS 管理ポリシー
ユーザー、グループ、ロールにアクセス許可を追加するには自分でポリシーを作成するよりも、AWS マネージドポリシーを使用する方が簡単です。チームに必要な権限のみを提供する [IAM カスタマーマネージドポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)には時間と専門知識が必要です。すぐに使用を開始するために、AWS マネージドポリシーを使用できます。これらのポリシーは一般的なユースケースを対象範囲に含めており、AWS アカウントで利用できます。AWS マネージドポリシーの詳細については「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
AWS のサービスはAWS マネージドポリシーを維持および更新します。AWS マネージドポリシーの許可を変更することはできません。サービスでは新しい機能を利用できるようにするために、AWS マネージドポリシーに権限が追加されることがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。新しい機能が立ち上げられた場合や、新しいオペレーションが使用可能になった場合に、各サービスが AWS マネージドポリシーを更新する可能性が最も高くなります。サービスはAWS マネージドポリシーから権限を削除しないため、ポリシーの更新によって既存の権限が破棄されることはありません。
さらに、AWS は複数のサービスにまたがるジョブ機能の特徴に対するマネージドポリシーもサポートしています。例えば、**ReadOnlyAccess** AWS マネージドポリシーではすべての AWS のサービスおよびリソースへの読み取り専用アクセスを許可します。サービスが新しい機能を起動する場合、AWS は新たなオペレーションとリソース用に、読み取り専用の許可を追加します。ジョブ機能のポリシーの一覧および詳細については、「*IAM ユーザーガイド*」の「[AWS のジョブ機能のマネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。
Amazon ECS および Amazon ECR では、ユーザー、グループ、ロール、Amazon EC2 インスタンス、および Amazon ECS タスクにアタッチして、リソースや API オペレーションで異なる制御レベルを使用できる複数の管理ポリシーと信頼関係を提供しています。これらのポリシーを直接適用することも、独自のポリシーを作成する開始点として使用することもできます。Amazon ECR 管理ポリシーの詳細については、「[Amazon ECR 管理ポリシー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr_managed_policies.html)」を参照してください。
## AmazonECS\$1FullAccess
`AmazonECS_FullAccess` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、Amazon ECS リソースへの管理アクセスを許可し、IAM ID(ユーザー、グループ、ロールなど)にAWSサービスは、Amazon ECS のすべての機能を使用するために統合されています。このポリシーを使用すると、AWS マネジメントコンソール で利用可能な Amazon ECS のすべての機能にアクセスできます。これらの機能は、。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECS\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECS_FullAccess.html)」を参照してください。
## AmazonECSInfrastructureRolePolicyForVolumes
`AmazonECSInfrastructureRolePolicyForVolumes` マネージドポリシーを IAM エンティティにアタッチできます。
ポリシーは、Amazon ECS がユーザーに変わって AWS API コールを行うのに必要なアクセス許可を付与します。このポリシーは、Amazon ECS のタスクとサービスを起動するときにボリューム設定で指定する IAM ロールにアタッチできます。このロールにより、Amazon ECS はタスクにアタッチされたボリュームを管理できます。詳細については、「[Amazon ECS インフラストラクチャの IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInfrastructureRolePolicyForVolumes](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForVolumes.html)」を参照してください。
## AmazonEC2ContainerServiceforEC2Role
`AmazonEC2ContainerServiceforEC2Role` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、ユーザーに代わって AWS に呼び出すことを Amazon ECS コンテナインスタンスに許可する管理権限を付与します。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
Amazon ECS は、Amazon EC2 インスタンスまたは外部インスタンスに対して、ユーザーに代わってアクションを実行することを Amazon ECS に許可するサービスロールにこのポリシーをアタッチします。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonEC2ContainerServiceforEC2Role](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerServiceforEC2Role.html)」を参照してください。
### 考慮事項
`AmazonEC2ContainerServiceforEC2Role` が管理する IAM ポリシーを使用するときは、次の推奨事項と考慮事項を検討する必要があります。
+ 最小権限を付与する標準のセキュリティアドバイスに従って、`AmazonEC2ContainerServiceforEC2Role` 管理ポリシーを変更して、特定のニーズに合わせることができます。管理ポリシーで付与されたアクセス許可のいずれかがユースケースに必要でない場合、カスタムポリシーを作成し、必要なアクセス許可のみを追加します。例えば、`UpdateContainerInstancesState` アクセス許可は、スポットインスタンスのドレインに提供されます。その権限がユースケースに必要ない場合、カスタムポリシーを使用して除外します。
+ コンテナインスタンスで実行しているコンテナは、[インスタンスのメタデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)を通じてコンテナインスタンスのロールに提供されているすべての権限にアクセスできます。コンテナインスタンスのロールのアクセス許可は、以下に提供されるマネージド型 `AmazonEC2ContainerServiceforEC2Role` ポリシーのアクセス許可のミニマリストに制限することをお勧めします。タスクのコンテナでリストされていない追加のアクセス許可が必要な場合は、独自の IAM ロールを使用してタスクを提供することをお勧めします。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
コンテナを防ぐには、`docker0` ブリッジからコンテナインスタンスロールに指定されたアクセス許可にアクセスしないようにします。これは、次の **iptables** コマンドをコンテナインスタンスで実行することで [Amazon ECS タスクの IAM ロール](task-iam-roles.md) が提供するアクセス許可を許可して、コンテナは、有効なこのルールでインスタンスメタデータをクエリできません。このコマンドはデフォルトの Docker のブリッジ設定を前提としており、`host` ネットワークモードを使用してコンテナでは動作しません。詳細については、「[ネットワークモード](task_definition_parameters.md#network_mode)」を参照してください。
```
sudo yum install -y iptables-services; sudo iptables --insert DOCKER USER 1 --in-interface docker+ --destination 169.254.169.254/32 --jump DROP
```
再起動後も有効にするには、コンテナインスタンスでこの **iptables** ルールを保存する必要があります。Amazon ECS 最適化 AMI の場合は、次のコマンドを使用します。他のオペレーティングシステムについては、その OS のドキュメントを参照してください。
+ Amazon ECS に最適化された Amazon Linux 2 AMI の場合:
```
sudo iptables-save | sudo tee /etc/sysconfig/iptables && sudo systemctl enable --now iptables
```
+ Amazon ECS に最適化された Amazon Linux AMI の場合:
```
sudo service iptables save
```
## AmazonEC2ContainerServiceEventsRole
`AmazonEC2ContainerServiceEventsRole` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、Amazon EventBridge(旧 CloudWatch Events)がユーザーに代わってタスクを実行できるようにするアクセス権限を付与します。このポリシーは、スケジュールされたタスクの作成時に指定された IAM ロールにアタッチできます。詳細については、「[Amazon ECS EventBridge IAM ロール](CWE_IAM_role.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonEC2ContainerServiceEventsRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerServiceEventsRole.html)」を参照してください。
## AmazonECSTaskExecutionRolePolicy
`AmazonECSTaskExecutionRolePolicy` 管理 IAM ポリシーは、Amazon ECS コンテナエージェントおよび AWS Fargate コンテナエージェントに必要なアクセス権限を付与し、ユーザーに代わって AWS API コールを作成します。このポリシーは、タスク実行 IAM ロールに追加できます。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSTaskExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSTaskExecutionRolePolicy.html)」を参照してください。
## AmazonECSServiceRolePolicy
`AmazonECSServiceRolePolicy` マネージド IAM ポリシーにより、Amazon Elastic Container Service でクラスターを管理できるようになります。このポリシーは、[AWSServiceRoleForECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using-service-linked-roles-for-clusters.html#service-linked-role-permissions-clusters) サービスにリンクされたロールに追加できます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSServiceRolePolicy.html)」を参照してください。
## `AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity`
IAM エンティティに `AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity` ポリシーをアタッチできます。このポリシーは、お客様に代わって Amazon ECS Service Connect TLS 機能を管理するために必要な AWS Private Certificate Authority、Secrets Manager、およびその他の AWS サービスへの管理アクセスを提供します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity.html)」を参照してください。
## `AWSApplicationAutoscalingECSServicePolicy`
IAM エンティティに `AWSApplicationAutoscalingECSServicePolicy` をアタッチすることはできません。このポリシーは、ユーザーに代わって Application Auto Scaling がアクションを実行することを許可する、サービスにリンクされたロールにアタッチされます。詳細については、「[Application Auto Scaling のサービスにリンクされたロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSApplicationAutoscalingECSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSApplicationAutoscalingECSServicePolicy.html)」を参照してください。
## `AWSCodeDeployRoleForECS`
IAM エンティティに `AWSCodeDeployRoleForECS` をアタッチすることはできません。このポリシーは、ユーザーに代わって CodeDeploy がアクションを実行することを許可する、サービスにリンクされたロールにアタッチされます。詳細については、*AWS CodeDeploy ユーザーガイド*の「[CodeDeploy のサービスロールを作成する](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-service-role.html)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSCodeDeployRoleForECS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeDeployRoleForECS.html)」を参照してください。
## `AWSCodeDeployRoleForECSLimited`
IAM エンティティに `AWSCodeDeployRoleForECSLimited` をアタッチすることはできません。このポリシーは、ユーザーに代わって CodeDeploy がアクションを実行することを許可する、サービスにリンクされたロールにアタッチされます。詳細については、*AWS CodeDeploy ユーザーガイド*の「[CodeDeploy のサービスロールを作成する](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-service-role.html)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSCodeDeployRoleForECSLimited](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeDeployRoleForECSLimited.html)」を参照してください。
## `AmazonECSInfrastructureRolePolicyForLoadBalancers`
IAM エンティティに `AmazonECSInfrastructureRolePolicyForLoadBalancers` ポリシーをアタッチできます。このポリシーは、Amazon ECS がユーザーに代わって Elastic Load Balancing リソースを管理できるようにするアクセス許可を付与します。このポリシーには以下が含まれます。
+ リスナー、ルール、ターゲットグループ、ターゲットヘルスを記述するための読み取り専用アクセス許可
+ ターゲットグループでターゲットを登録および登録解除するためのアクセス許可
+ Application Load Balancer と Network Load Balancer のリスナーを変更するためのアクセス許可
+ Application Load Balancer のルールを変更するためのアクセス許可
これらのアクセス許可により、Amazon ECS はサービスの作成時または更新時にロードバランサーの設定を自動的に管理できるようになり、コンテナへのトラフィックの適切なルーティングが確保されます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInfrastructureRolePolicyForLoadBalancers](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForLoadBalancers.html)」を参照してください。
## `AmazonECSInfrastructureRolePolicyForManagedInstances`
IAM エンティティに `AmazonECSInfrastructureRolePolicyForManagedInstances` ポリシーをアタッチできます。このポリシーは、ユーザーに代わって ECS マネージドインスタンスの Amazon EC2 リソースを作成および更新するために Amazon ECS が必要とするアクセス許可を付与します。このポリシーには以下が含まれます。
+ マネージドインスタンスの Amazon EC2 起動テンプレートを作成および管理するアクセス許可
+ CreateFleet と RunInstances を使用して Amazon EC2 インスタンスをプロビジョニングするアクセス許可
+ ECS が作成する Amazon EC2 リソースでタグを作成および管理するためのアクセス許可
+ マネージドインスタンスの Amazon EC2 インスタンスに IAM ロールを渡すアクセス許可
+ Amazon EC2 スポットインスタンス用のサービスにリンクされたロールを作成するアクセス許可
+ インスタンス、インスタンスタイプ、起動テンプレート、ネットワークインターフェイス、アベイラビリティーゾーン、セキュリティグループ、サブネット、VPC、EC2 イメージ、およびキャパシティ予約を含めた Amazon EC2 リソースを記述するための読み取り専用許可
+ Amazon ResourceGroups リソースを一覧表示するための読み取り専用許可 (タグ付けされたリソースを取得し、Amazon CloudFormation スタックリソースを一覧表示するための基礎的な許可が必要です)
これらのアクセス許可により、Amazon ECS は ECS マネージドインスタンスの Amazon EC2 インスタンスを自動的にプロビジョニングおよび管理し、基盤となるコンピューティングリソースの適切な設定とライフサイクル管理を確保できます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInfrastructureRolePolicyForManagedInstances](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForManagedInstances.html)」を参照してください。
## `AmazonECSInfrastructureRolePolicyForVpcLattice`
IAM エンティティに `AmazonECSInfrastructureRolePolicyForVpcLattice` ポリシーをアタッチできます。このポリシーは、ユーザーに代わって Amazon ECS ワークロードの VPC Lattice 機能を管理するために必要な他の AWS サービスリソースへのアクセスを提供します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInfrastructureRolePolicyForVpcLattice](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForVpcLattice.html)」を参照してください。
ユーザーに代わって Amazon ECS ワークロードの VPC Lattice 機能を管理するために必要な他の AWS サービスリソースへのアクセスを提供します。
## `AmazonECSInfrastructureRoleforExpressGatewayServices`
IAM エンティティに `AmazonECSInfrastructureRoleforExpressGatewayServices` ポリシーをアタッチできます。このポリシーは、Amazon ECS がユーザーに代わって Express サービスを使用してウェブアプリケーションを作成および更新するために必要なアクセス許可を付与します。このポリシーには以下が含まれます。
+ Amazon ECS Application Auto Scaling のサービスにリンクされたロールを作成するアクセス許可
+ これには Application Load Blancer、リスナー、ルール、ターゲットグループの作成、更新、削除のアクセス許可が含まれます。
+ ECS マネージドリソースの VPC セキュリティグループを作成、変更、削除するアクセス許可
+ ACM 経由で SSL/TLS 証明書のリクエスト、管理、削除を実行するアクセス許可
+ Amazon ECS サービスの Application Auto Scaling ポリシーとターゲットを設定するアクセス許可
+ 自動スケーリングトリガー用 CloudWatch アラームを作成および管理するためのアクセス許可
+ ロードバランサー、VPC リソース、証明書、自動スケーリング設定、CloudWatch アラームを記述するための読み取り専用アクセス許可
これらのアクセス許可により、Amazon ECS は Express サービスウェブアプリケーションに必要なインフラストラクチャコンポーネント (ロードバランシング、セキュリティグループ、SSL 証明書、自動スケーリング設定など) のプロビジョニングおよび管理を自動的に実行できます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInfrastructureRoleforExpressGatewayServices](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRoleforExpressGatewayServices.html)」を参照してください。
## `AmazonECSComputeServiceRolePolicy`
AmazonECSComputeServiceRole サービスにリンクされたロールが `AmazonECSComputeServiceRolePolicy` ポリシーにアタッチされます。詳細については、「[ロールを使用して Amazon ECS マネージドインスタンスを管理する](using-service-linked-roles-instances.md)」を参照してください。
このポリシーには Amazon ECS に次のタスクを完了させるための権限が含まれています。
+ Amazon ECS が起動テンプレートを記述および削除する。
+ Amazon ECS が起動テンプレートのバージョンを記述および削除する。
+ Amazon ECS がインスタンスを終了する。
+ Amazon ECS では、次のインスタンスデータパラメータを記述できます。
+ インスタンス
+ インスタンスネットワークインターフェイス: Amazon ECS は、EC2 インスタンスのライフサイクルを管理するインターフェイスを記述できます。
+ インスタンスイベントウィンドウ: Amazon ECS は、インスタンスのパッチ適用を目的としたワークフロー中断の可否を決定するためのイベントウィンドウ情報を記述できます。
+ インスタンスステータス: Amazon ECS は、インスタンスの状態をモニタリングするためにインスタンスステータスを記述できます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSComputeServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSComputeServiceRolePolicy.html)」を参照してください。
## `AmazonECSInstanceRolePolicyForManagedInstances`
この `AmazonECSInstanceRolePolicyForManagedInstances` ポリシーは、Amazon ECS マネージドインスタンスを Amazon ECS クラスターに登録し、Amazon ECS サービスと通信するためのアクセス許可を提供します。
このポリシーには Amazon ECS マネージドインスタンスに次のタスクを完了させるための権限が含まれます。
+ Amazon ECS クラスターの登録および登録解除を実行する。
+ コンテナインスタンスの状態の変更を送信する。
+ タスクの状態の変更を送信する。
+ Amazon ECS エージェントのポーリングエンドポイントを検出する。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonECSInstanceRolePolicyForManagedInstances](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInstanceRolePolicyForManagedInstances.html)」を参照してください。
## Amazon ECS での AWS 管理ポリシーに関する更新
Amazon ECS 向けの AWS 管理ポリシーについて、このサービスがこれらの変更の追跡を開始して以降行われた更新の詳細情報を示します。このページの変更に関する自動通知を入手するには、Amazon ECS ドキュメントの履歴ページから、RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| `AmazonECSInfrastructureRolePolicyForManagedInstances` ポリシーを更新 | Amazon ECS マネージドインスタンスでキャパシティ予約をサポートするため、以下の許可で `AmazonECSInfrastructureRolePolicyForManagedInstances` ポリシーが更新されました。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-iam-awsmanpol.html) | 2026 年 2 月 24 日 |
| [AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSServiceRolePolicy) に許可を追加 | AmazonECSServiceRolePolicy マネージド IAM ポリシーが更新され、ssmmessages:OpenDataChannel アクセス許可が含まれるようになりました。この許可は、Amazon ECS が ECS Exec セッションのデータチャネルを開くことを可能にします。 | 2026 年 1 月 20 日 |
| `AmazonECSInfrastructureRolePolicyForManagedInstances` ポリシーを更新する | `AmazonECSInfrastructureRolePolicyForManagedInstances` ポリシーが更新され、`CreateFleet` 許可が変更されました。以下の理由により、サブネット、セキュリティグループ、EC2 イメージに対するリソースベースの条件が削除されました。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-iam-awsmanpol.html) この変更によって、期待される ECS 管理タグがないリソースでもポリシーが正しく機能するようになります。 | 2025 年 12 月 15 日 |
| [AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSServiceRolePolicy) にアクセス許可を追加します。 | AmazonECSServiceRolePolicy マネージド IAM ポリシーを更新し、新しい Amazon EC2 アクセス許可を追加しました。このアクセス許可で、Amazon ECS はイベントウィンドウに関連付けられたサービスおよびクラスターの Amazon EC2 イベントウィンドウを取得できます。 | 2025 年 11 月 20 日 |
| [AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSServiceRolePolicy) にアクセス許可を追加します。 | AmazonECSServiceRolePolicy マネージド IAM ポリシーを更新し、新しい Amazon EC2 アクセス許可を追加しました。このアクセス許可で、Amazon ECS はタスク ENI のプロビジョニングおよびプロビジョニング解除を実行できます。 | 2025 年 11 月 14 日 |
| [AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity) ポリシーを更新 | AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity マネージド IAM ポリシーを更新し、secretsmanager:DescribeSecret アクセス許可を独自のポリシーステートメントとして分離しました。このアクセス許可は、引き続き Amazon ECS で作成したシークレットにのみ Amazon ECS アクセスの範囲を設定します。また、範囲設定にはリソースタグの代わりに ARN パターンマッチングを使用します。これにより、Amazon ECS は、シークレットが削除された場合などを含めて、ライフサイクル全体でシークレットの状態をモニタリングできます。 | 2025 年 11 月 13 日 |
| 新しい [`AmazonECSInfrastructureRoleforExpressGatewayServices`](#security-iam-awsmanpol-AmazonECSInfrastructureRoleforExpressGatewayServices) の追加 | Express サービスを使用してウェブアプリケーションを作成および管理するための Amazon ECS アクセス許可を提供する、新しい AmazonECSInfrastructureRoleforExpressGatewayServices ポリシーを追加しました。 | 2025 年 11 月 21 日 |
| 新しい [`AmazonECSInstanceRolePolicyForManagedInstances`](#security-iam-awsmanpol-AmazonECSInstanceRolePolicyForManagedInstances) の追加 | Amazon ECS マネージドインスタンスから Amazon ECS クラスターに登録するためのアクセス許可を提供する、新しい AmazonECSInstanceRolePolicyForManagedInstances ポリシーを追加しました。 | 2025 年 9 月 30 日 |
| 新しい [`AmazonECSInfrastructureRolePolicyForManagedInstances`](#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForManagedInstances) の追加 | Amazon EC2 マネージドリソースを作成および管理するための Amazon ECS アクセスを提供する新しい AmazonECSInfrastructureRolePolicyForManagedInstances ポリシーを追加しました。 | 2025 年 9 月 30 日 |
| 新しい [AmazonECSComputeServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSComputeServiceRolePolicy) を追加 | Amazon ECS が Amazon ECS マネージドインスタンスと関連リソースを管理できるようにします。 | 2025 年 8 月 31 日 |
| [AmazonEC2ContainerServiceforEC2Role](#security-iam-awsmanpol-AmazonEC2ContainerServiceforEC2Role) へのアクセス許可を追加する | AmazonEC2ContainerServiceforEC2Role マネージド IAM ポリシーが更新され、ecs:ListTagsForResource アクセス許可が含まれるようになりました。このアクセス許可により、Amazon ECS エージェントはタスクメタデータエンドポイント (\$1\$1ECS\$1CONTAINER\$1METADATA\$1URI\$1V4\$1/taskWithTags) を介してタスクおよびコンテナインスタンスのタグを取得できます。 | 2025 年 8 月 4 日 |
| [AmazonECSInfrastructureRolePolicyForLoadBalancers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForLoadBalancers) にアクセス許可を追加します。 | AmazonECSInfrastructureRolePolicyForLoadBalancers マネージド IAM ポリシーが更新され、ターゲットグループを記述、登録解除、登録するための新しいアクセス許可が追加されました。 | 2025 年 7 月 25 日 |
| 新しい [`AmazonECSInfrastructureRolePolicyForLoadBalancers`](#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForLoadBalancers) ポリシーを追加する | Amazon ECS ワークロードに関連づけられているロードバランサーの管理に必要な他の AWS サービスリソースへのアクセスを提供する新しい AmazonECSInfrastructureRolePolicyForLoadBalancers ポリシーを追加しました。 | 2025 年 7 月 15 日 |
| [AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSServiceRolePolicy) にアクセス許可を追加します。 | AmazonECSServiceRolePolicy マネージド IAM ポリシーは、Amazon ECS が管理するサービスの AWS Cloud Map サービス属性を Amazon ECS が更新できる新しい AWS Cloud Map アクセス許可で更新されました。 | 2025 年 7 月 15 日 |
| [AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSServiceRolePolicy) にアクセス許可を追加する | AmazonECSServiceRolePolicy マネージド IAM ポリシーは、Amazon ECS が管理するサービスの AWS Cloud Map サービス属性を Amazon ECS が更新できる新しい AWS Cloud Map アクセス許可で更新されました。 | 2025 年 6 月 24 日 |
| [AmazonECSInfrastructureRolePolicyForVolumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForVolumes) へのアクセス許可を追加する | AmazonECSInfrastructureRolePolicyForVolumes ポリシーが更新され、ec2:DescribeInstances のアクセス許可が追加されました。アクセス許可は、同じコンテナインスタンスで実行される Amazon ECS タスクにアタッチされている Amazon EBS ボリュームのデバイス名のコリジョンを防ぐのに役立ちます。 | 2025 年 6 月 2 日 |
| 新しい [AmazonECSInfrastructureRolePolicyForVpcLattice](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForVpcLattice) の追加 | ユーザーに代わって Amazon ECS ワークロードの VPC Lattice 機能を管理するために必要な他の AWS サービスリソースへのアクセスを提供します。 | 2024 年 11 月 18 日 |
| [AmazonECSInfrastructureRolePolicyForVolumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForVolumes) へのアクセス許可を追加する | AmazonECSInfrastructureRolePolicyForVolumes ポリシーが更新され、お客様がスナップショットから Amazon EBS ボリュームを作成できるようになりました。 | 2024 年 10 月 10 日 |
| アクセス許可を [AmazonECS\$1FullAccess](#security-iam-awsmanpol-AmazonECS_FullAccess) に追加しました。 | AmazonECS\$1FullAccess ポリシーが更新され、ecsInfrastructureRole という名前のロールの IAM ロールの iam:PassRole アクセス許可が追加されました。これは、AWS マネジメントコンソール によって作成されたデフォルトの IAM ロールで、Amazon ECS が ECS タスクにアタッチされた Amazon EBS ボリュームを管理できる ECS インフラストラクチャロールとして使用されることを目的としています。 | 2024 年 8 月 13 日 |
| 新しく、[AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity) ポリシーを追加しました。 | 新しく、AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity ポリシーを追加しました。これは AWS KMS、AWS Private Certificate Authority、Secrets Manager に管理アクセスを付与し、Amazon ECS Service Connect TLS 機能が正常に動作できるようにするものです。 | 2024 年 1 月 22 日 |
| 新しいポリシー [AmazonECSInfrastructureRolePolicyForVolumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSInfrastructureRolePolicyForVolumes) を追加しました。 | AmazonECSInfrastructureRolePolicyForVolumes ポリシーが追加されました。このポリシーにより、Amazon ECS が AWS API コールを行い、Amazon ECS ワークロードに関連付けられた Amazon EBS ボリュームを管理するために必要な権限が付与されます。 | 2024 年 1 月 11 日 |
| [AmazonECSServiceRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonECSServiceRolePolicy) にアクセス許可を追加する | AmazonECSServiceRolePolicy マネージド IAM ポリシーが更新され、新しい events アクセス許可および、追加権限 autoscaling、autoscaling-plans が追加されました。 | 2023 年 12 月 4 日 |
| 許可を [AmazonEC2ContainerServiceEventsRole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerServiceEventsRole) に追加する | AmazonECSServiceRolePolicy マネージド IAM ポリシーが AWS Cloud Map DiscoverInstancesRevision API 操作へのアクセスを許可するように更新されました。 | 2023 年 10 月 4 日 |
| 許可を [AmazonEC2ContainerServiceforEC2Role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerServiceforEC2Role) に追加する | AmazonEC2ContainerServiceforEC2Role ポリシーが変更され、新しく作成されたクラスターと登録されたコンテナインスタンスのみに許可を制限する条件を含む ecs:TagResource 許可が追加されました。 | 2023 年 3 月 6 日 |
| [AmazonECS\$1FullAccess](#security-iam-awsmanpol-AmazonECS_FullAccess) へのアクセス許可を追加する | AmazonECS\$1FullAccess ポリシーが変更され、elasticloadbalancing:AddTags 権限が追加されました。これには、新しく作成されたロードバランサー、ターゲットグループ、ルール、および作成されたリスナーのみにアクセス許可を制限する条件が含まれています。この権限では、既に作成されている Elastic Load Balancing リソースにタグを追加することはできません。 | 2023 年 1 月 4 日 |
| Amazon ECS が変更の追跡を開始しました。 | Amazon ECS が AWS 管理ポリシーの変更の追跡を開始しました。 | 2021 年 6 月 8 日 |
# AWS Amazon Elastic Container Service の マネージド IAM ポリシーを段階的に廃止します。
以下の AWS 管理 IAM ポリシーは段階的に廃止されます。これらのポリシーは、更新されたポリシーに置き換えられます。ユーザーまたはロールを更新して、更新されたポリシーを使用することをお勧めします。
## AmazonEC2ContainerServiceFullAccess
**重要**
`AmazonEC2ContainerServiceFullAccess` 管理 IAM ポリシーは、2021 年 1 月 29 日に段階的に廃止されました。これは、`iam:passRole` 許可で発見されたセキュリティへの対応です。このアクセス許可は、アカウント内のロールへの認証情報を含むすべてのリソースへのアクセスを許可します。ポリシーが廃止されると、新しいユーザーまたはロールにポリシーをアタッチできなくなります。ポリシーがアタッチされているユーザーまたはロールは、そのポリシーを引き続き使用できます。ただし、ユーザーまたはロールを更新して、`AmazonECS_FullAccess` 管理ポリシーを代わりに使用することをお勧めします 詳細については、「[`AmazonECS_FullAccess` 管理ポリシーへの移行](security-iam-awsmanpol-amazonecs-full-access-migration.md)」を参照してください。
## AmazonEC2ContainerServiceRole
**重要**
`AmazonEC2ContainerServiceRole` マネージド IAM ポリシーは段階的に廃止されます。これで Amazon ECS サービスリンクロールに置き換えられます。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
## AmazonEC2ContainerServiceAutoscaleRole
**重要**
`AmazonEC2ContainerServiceAutoscaleRole` マネージド IAM ポリシーは段階的に廃止されます。これは、Amazon ECS の Application Auto Scaling サービスリンクロールに置き換えられました。詳細については、「Application Auto Scaling ユーザーガイド」の「[Application Auto Scaling 用のサービスリンクロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。
# `AmazonECS_FullAccess` 管理ポリシーへの移行
`AmazonEC2ContainerServiceFullAccess` 管理 IAM ポリシーは、2021 年 1 月 29 日に段階的に廃止されました。これは、`iam:passRole` アクセス許可で発見されたセキュリティへの対応です。このアクセス許可は、アカウント内のロールへの認証情報を含むすべてのリソースへのアクセスを許可します。ポリシーが廃止されると、新しいグループ、ユーザー、またはロールにポリシーをアタッチできなくなります。すでにポリシーがアタッチされているグループ、ユーザー、またはロールは、引き続きそのポリシーを使用できます。ただし、グループ、ユーザー、またはロールを更新して、`AmazonECS_FullAccess` が管理するポリシーを代わりに使用することをお勧めします。
`AmazonECS_FullAccess` によって付与される許可には、ECS を管理者として使用するために必要なアクセス許可の完全なリストが含まれます。`AmazonECS_FullAccess` ポリシーにはない `AmazonEC2ContainerServiceFullAccess` ポリシーによって付与されているアクセス許可を現在使用している場合、それらをインラインポリシーステートメントに追加できます。詳細については、「[Amazon Elastic Container Service に関する AWS 管理ポリシー](security-iam-awsmanpol.md)」を参照してください。
現在 `AmazonEC2ContainerServiceFullAccess` 管理 IAM ポリシーを使用しているグループ、ユーザー、またはロールがあるかを判断するには、次のステップを使用します。次に、これらのポリシーを更新して以前のポリシーをデタッチし、`AmazonECS_FullAccess` ポリシーをアタッチします。
**AmazonECS\$1FullAccess ポリシーを使用するようにグループ、ユーザー、またはロールを更新するには (AWS マネジメントコンソール)**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで [**Policies**] を選択し、`AmazonEC2ContainerServiceFullAccess` ポリシーを検索して選択します。
1. [**Policy usage (ポリシーの使用)**] タブを選択すると、現在このポリシーを使用している IAM ロールが表示されます。
1. 現在 `AmazonEC2ContainerServiceFullAccess` ポリシーを使用している IAM ロールごとに、ロールを選択し、次の手順を使用して段階的廃止されるポリシーをデタッチし、`AmazonECS_FullAccess` ポリシーをアタッチします。
1. **[Permissions]** (許可) タブで、**AmazonEC2ContainerServiceFullAccess** ポリシーの横にある **X** を選択します。
1. [**Add permissions (許可の追加)**] を選択します。
1. [**Attach existing policies directly**] を選択し、**AmazonECS\$1FullAccess** ポリシーを検索してクリックして、[**Next: Review**] を選択します。
1. 変更を確認し、[**Add permissions**] を選択します。
1. `AmazonEC2ContainerServiceFullAccess` ポリシーを使用しているグループ、ユーザー、またはロールごとに、これらの手順を繰り返します。
**`AmazonECS_FullAccess` ポリシーを使用するようにグループ、ユーザー、またはロールを更新するには (AWS CLI)**
1. [https://docs.aws.amazon.com/cli/latest/reference/iam/generate-service-last-accessed-details.html](https://docs.aws.amazon.com/cli/latest/reference/iam/generate-service-last-accessed-details.html) コマンドを使用して、段階的に廃止されたポリシーが最後に使用された日時に関する詳細を含むレポートを生成します。
```
aws iam generate-service-last-accessed-details \
--arn arn:aws:iam::aws:policy/AmazonEC2ContainerServiceFullAccess
```
出力例:
```
{
"JobId": "32bb1fb0-1ee0-b08e-3626-ae83EXAMPLE"
}
```
1. [https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-last-accessed-details.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-last-accessed-details.html) コマンドを使用して、前回の出力のジョブ ID を指定すると、サービスの最終アクセスレポートを取得できます。このレポートには、段階的に廃止されたポリシーを最後に使用した IAM エンティティの Amazon リソースネーム (ARN) が表示されます。
```
aws iam get-service-last-accessed-details \
--job-id 32bb1fb0-1ee0-b08e-3626-ae83EXAMPLE
```
1. グループ、ユーザー、またはロールから `AmazonEC2ContainerServiceFullAccess` ポリシーをデタッチするには、次のコマンドのいずれかを使用します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-group-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-group-policy.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-role-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-role-policy.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html)
1. `AmazonECS_FullAccess` ポリシーをグループ、ユーザー、またはロールにアタッチするには、次のコマンドのいずれかを使用します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html)
# Amazon ECS のサービスリンクロールの使用
Amazon Elastic Container Service は、AWS Identity and Access Management (IAM) の[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスリンクロールは、Amazon ECS に直接リンクされた特殊なタイプの IAM ロールです。サービスにリンクされたロールは Amazon ECS で事前定義されています。このロールには、サービスがユーザーに代わって他の AWS のサービスを呼び出すために必要なアクセス許可がすべて付与されています。
**Topics**
+ [ロールを使用して Amazon ECS にクラスターの管理を許可する](using-service-linked-roles-for-clusters.md)
+ [ロールを使用して Amazon ECS マネージドインスタンスを管理する](using-service-linked-roles-instances.md)
# ロールを使用して Amazon ECS にクラスターの管理を許可する
Amazon Elastic Container Service は、AWS Identity and Access Management (IAM) の[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスリンクロールは、Amazon ECS に直接リンクされた特殊なタイプの IAM ロールです。サービスにリンクされたロールは Amazon ECS で事前定義されています。このロールには、サービスがユーザーに代わって他の AWS のサービスを呼び出すために必要なアクセス許可がすべて付与されています。
サービスにリンクされたロールを使用すると、必要な許可を手動で追加する必要がないため、Amazon ECS のセットアップが簡単になります。サービスリンクロールの許可は Amazon ECS が定義し、特に定義されない限り、Amazon ECS のみがそのロールを引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。こうすることで、不注意によりリソースにアクセスするための許可を削除することがなくなるため、Amazon ECS リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、**サービスにリンクされたロール列**内で **[はい]** と表記されたサービスを確認してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。
## Amazon ECS のサービスリンクロール許可
Amazon ECS は、**AWSServiceRoleForECS** という名前のサービスにリンクされたロールを使用します。このロールにより、Amazon ECS はクラスターを管理できるようになります。
サービスにリンクされたロール AWSServiceRoleForECS は、次のサービスを信頼してロールを引き受けます。
+ `ecs.amazonaws.com`
AmazonECSServiceRolePolicy という名前のロールのアクセス許可ポリシーは、指定したリソースに対して以下のアクションを実行することを Amazon ECS に許可します。
+ アクション: `awsvpc` Amazon ECS タスクのネットワークモードを使用する場合、Amazon ECS はタスクに関連するエラスティックネットワークインターフェイスのライフサイクルを管理します。これには、Amazon ECS がエラスティックネットワークインターフェイスに追加するタグも含まれます。
+ アクション: Amazon ECS サービスでロードバランサーを使用する場合、Amazon ECS は、ロードバランサーへのリソースの登録と登録解除を管理します。
+ アクション: Amazon ECS サービス検出を使用する場合、Amazon ECS は必要な Route 53 を管理し、AWS Cloud Map サービス検出が機能するためのリソース
+ アクション: Amazon ECS サービスのオートスケーリングを使用する場合、Amazon ECS は必要な Auto Scaling リソースを管理します。
+ アクション: Amazon ECS は、Amazon ECS リソースのモニタリングに役立つ CloudWatch アラームとログストリームを作成および管理します。
+ アクション: Amazon ECS Exec を使用する場合、Amazon ECS Exec セッションを開始するために必要なタスクへのアクセス権限は Amazon ECS が管理します。
+ アクション: Amazon ECS Service Connect を使用する場合、その機能を使用するために必要な AWS Cloud Map リソースは Amazon ECS が管理します。
+ アクション: Amazon ECS キャパシティープロバイダーを使用する場合、Auto Scaling グループとその Amazon EC2 インスタンスを変更するために必要なアクセス権限は Amazon ECS が管理します。
+ アクション: Amazon ECS は、Amazon ECS が管理するサービスの AWS Cloud Map サービス属性を更新できます。
+ アクション: Amazon ECS は、タスクの開始時と停止時に Amazon EC2 のプロビジョニング及びプロビジョニング解除用 ENI を呼び出すことができます。
+ アクション: Amazon ECS は Event Windows に関連付けられたサービスとクラスターのために Amazon EC2 Event Windows を取得することが可能になります。
ユーザー、グループ、またはロールにサービスリンクロールの作成、編集、または削除を許可するには、アクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## Amazon ECS のサービスリンクロールの作成
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でクラスターを作成したり、サービスを作成または更新したりすると、Amazon ECS によってサービスにリンクされたロールが自動的に作成されます。
**重要**
このサービスリンクロールはこのロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。2017 年 1 月 1 日より前に Amazon ECS サービスを使用している場合、サービスにリンクされたロールのサポートの開始時に、Amazon ECS によって AWSServiceRoleForECS ロールがアカウントに作成されています。詳細については、「[AWS アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
**AWSServiceRoleForECS** ユースケースでサービスにリンクされたロールを作成するには、IAM コンソールを使用します。AWS CLI または AWS API で、IAM を使用してサービスにリンクされたロール (サービス名は `ecs.amazonaws.com`) で作成します。詳細については、*IAM ユーザーガイド*の「[サービスリンクロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。このサービスリンクロールを削除しても、同じ方法でロールを再作成できます。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。クラスターを作成したり、サービスを作成または更新したりすると、Amazon ECS によってサービスにリンクされたロールが自動的に作成されます。
このサービスにリンクされたロールを削除する場合、この同じ IAM プロセスを使用して、もう一度ロールを作成できます。
## Amazon ECS のサービスリンクロールの編集
Amazon ECS では、AWSServiceRoleForECS サービスリンクロールを編集できません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Amazon ECS のサービスリンクロールの削除
AWSServiceRoleForECS ロールを手動で削除する必要はありません。AWS マネジメントコンソール、AWS CLI、AWS API の全リージョンのクラスターを削除すると、Amazon ECS がリソースをクリーンアップし、サービスリンクロールを削除します。
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースを削除しようとしたときに Amazon ECS サービスがロールを使用している場合は、削除が失敗する可能性があります。失敗した場合は数分待ってから操作を再試行してください。
**AWSServiceRoleForECS が使用している Amazon ECS リソースを削除するには (コンソール)**
1. すべての Amazon ECS サービスをすべてのリージョンで必要数 0 に縮小してから、サービスを削除します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」および「[コンソールを使用して Amazon ECS サービスの削除](delete-service-v2.md)」を参照してください。
1. 全リージョンのすべてのクラスターからすべてのコンテナインスタンスを強制的に登録解除します。詳細については、「[Amazon ECS コンテナインスタンスの登録を解除する](deregister_container_instance.md)」を参照してください。
1. すべてのリージョンですべての Amazon ECS クラスターを削除します。詳細については、「[Amazon ECS クラスターを削除する](delete_cluster-new-console.md)」を参照してください。
**AWSServiceRoleForECS が使用している Amazon ECS リソースを削除するには (AWS CLI)**
1. すべての Amazon ECS サービスをすべてのリージョンで必要数 0 に縮小してから、サービスを削除します。詳細については、「AWS Command Line Interfaceリファレンス」の「[update–service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)」および「[delete–service](https://docs.aws.amazon.com/cli/latest/reference/ecs/delete-service.html)」を参照してください。
1. 全リージョンのすべてのクラスターからすべてのコンテナインスタンスを強制的に登録解除します。詳細については、「[deregister–container–instance](https://docs.aws.amazon.com/cli/latest/reference/ecs/deregister-container-instance.html)」を参照してください。
1. 全リージョンですべての Amazon ECS クラスターを削除します。詳細については、「[delete–cluster](https://docs.aws.amazon.com/cli/latest/reference/ecs/delete-cluster.html)」を参照してください。
**AWSServiceRoleForECS が使用している Amazon ECS リソースを削除するには (API)**
1. すべての Amazon ECS サービスをすべてのリージョンで必要数 0 に縮小してから、サービスを削除します。詳細については、*Amazon ECS API リファレンス*の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」および「[DeleteService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteService.html)」を参照してください。
1. 全リージョンのすべてのクラスターからすべてのコンテナインスタンスを強制的に登録解除します。詳細については、「[DeregisterContainerInstance](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeregisterContainerInstance.html)」を参照してください。
1. 全リージョンですべての Amazon ECS クラスターを削除します。詳細については、「[DeleteCluster](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteCluster.html)」を参照してください。
### サービスリンク役割の手動による削除
IAM コンソール、AWS CLI、または AWS API を使用して、サービスにリンクされたロールである AWSServiceRoleForECS を削除します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon ECS サービスリンクロールがサポートされるリージョン
Amazon ECS は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、「[AWS リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
# ロールを使用して Amazon ECS マネージドインスタンスを管理する
Amazon Elastic Container Service は、AWS Identity and Access Management (IAM) の[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスリンクロールは、Amazon ECS に直接リンクされた特殊なタイプの IAM ロールです。サービスにリンクされたロールは Amazon ECS で事前定義されています。このロールには、サービスがユーザーに代わって他の AWS のサービスを呼び出すために必要なアクセス許可がすべて付与されています。
サービスにリンクされたロールを使用すると、必要な許可を手動で追加する必要がないため、Amazon ECS のセットアップが簡単になります。サービスリンクロールの許可は Amazon ECS が定義し、特に定義されない限り、Amazon ECS のみがそのロールを引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。こうすることで、不注意によりリソースにアクセスするための許可を削除することがなくなるため、Amazon ECS リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、**サービスにリンクされたロール列**内で **[はい]** と表記されたサービスを確認してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。
## Amazon ECS のサービスリンクロール許可
Amazon ECS は、**AWSServiceRoleForECSCompute** という名前のサービスリンクロールを使用して、Amazon ECS マネージドインスタンスキャパシティプロバイダーがプロビジョニングした Amazon EC2 マネージドインスタンスを Amazon ECS で管理できるようにします。
AWSServiceRoleForECSCompute サービスリンクロールは、次のサービスを信頼してロールを引き受けます。
+ `ecs-compute.amazonaws.com`
[`AmazonECSComputeServiceRolePolicy`](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECSComputeServiceRolePolicy) という名前のロールのアクセス許可ポリシーは、Amazon ECS が次のアクションを完了することを許可します。
+ Amazon ECS が起動テンプレートを記述および削除する。
+ Amazon ECS が起動テンプレートのバージョンを記述および削除する。
+ Amazon ECS がインスタンスを終了する。
+ Amazon ECS では、次のインスタンスデータパラメータを記述できます。
+ インスタンス
+ インスタンスネットワークインターフェイス: Amazon ECS は、EC2 インスタンスのライフサイクルを管理するインターフェイスを記述できます。
+ インスタンスイベントウィンドウ: Amazon ECS は、インスタンスのパッチ適用を目的としたワークフロー中断の可否を決定するためのイベントウィンドウ情報を記述できます。
+ インスタンスステータス: Amazon ECS は、インスタンスの状態をモニタリングするためにインスタンスステータスを記述できます。
ユーザー、グループ、またはロールにサービスリンクロールの作成、編集、または削除を許可するには、アクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## Amazon ECS のサービスリンクロールの作成
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、AWS API で Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成すると、Amazon ECS がサービスにリンクされたロールを作成します。
**重要**
このサービスリンクロールはこのロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。2017 年 1 月 1 日より前に Amazon ECS サービスを使用している場合、サービスにリンクされたロールのサポートが開始された時点で、Amazon ECS が AmazonECSComputeServiceRolePolicy ロールをアカウントに作成しています。詳細については、「[AWS アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成すると、Amazon ECS はサービスにリンクされたロールを再度作成します。
このサービスにリンクされたロールを削除する場合、この同じ IAM プロセスを使用して、もう一度ロールを作成できます。
## Amazon ECS のサービスリンクロールの編集
Amazon Connect では、サービスにリンクされたロール AmazonECSComputeServiceRolePolicy を編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Amazon ECS のサービスリンクロールの削除
AmazonECSComputeServiceRolePolicy を手動で削除する必要はありません。AWS マネジメントコンソール、AWS CLI、AWS API の全リージョンの Amazon ECS マネージドインスタンスキャパシティプロバイダーを削除すると、Amazon ECS がリソースをクリーンアップし、サービスリンクロールを削除します。
### サービスリンク役割の手動による削除
IAM コンソール、AWS CLI、AWS API を使用して、AmazonECSComputeServiceRolePolicy サービスリンクロールを削除します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon ECS サービスリンクロールがサポートされるリージョン
Amazon ECS は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、「[AWS リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
# Amazon ECS の IAM ロール
IAM ロール は、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティです。Amazon ECS では、コンテナやサービスなどの Amazon ECS リソースにアクセス許可を付与するロールを作成できます。
Amazon ECS が必要とするロールは、タスク定義の起動タイプと使用する機能によって異なります。次の表を参照して、Amazon ECS に必要な IAM ロールを決定します。
| ロール | 定義 | 必要な場合 | 詳細情報 |
| --- | --- | --- | --- |
| タスク実行ロール | このロールにより、Amazon ECS がお客様に代わって他の AWS サービスを利用できるようにします。 | タスクは AWS Fargate または外部インスタンスホストされています。また、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-ecs-iam-role-overview.html) タスクは、AWS Fargate または Amazon EC2 インスタンスでホストされています。また、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-ecs-iam-role-overview.html) | [Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md) |
| タスクロール | このロールにより、(コンテナ上の) アプリケーションコードが他の AWS サービスを使用できるようになります。 | アプリケーションは、Amazon S3 などの他の AWS サービスにアクセスします。 | [Amazon ECS タスクの IAM ロール](task-iam-roles.md) |
| コンテナインスタンスのロール | このロールにより、EC2 インスタンスまたは外部インスタンスをクラスターに登録できます。 | タスクは Amazon EC2 インスタンスまたは外部インスタンスでホストされています。 | [Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md) |
| Amazon ECS Anywhere ロール | このロールにより、外部インスタンスが AWS API にアクセスできるようになります。 | タスクは外部インスタンスでホストされています。 | [Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md) |
| ロードバランサーロール用の Amazon ECS インフラストラクチャ | このロールにより、Amazon ECS はブルー/グリーンデプロイにおいて、ユーザーに代わってクラスター内のロードバランサーリソースを管理できます。 | Amazon ECS のブルー/グリーンデプロイを使用できます。 | [ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) |
| Amazon ECS CodeDeploy ロール | このロールにより、CodeDeploy はサービスを更新できます。 | CodeDeploy のブルー/グリーンデプロイタイプを使用して、サービスをデプロイします。 | [Amazon ECS CodeDeploy IAM ロール](codedeploy_IAM_role.md) |
| Amazon ECS EventBridge ロール | このロールにより、EventBridge はサービスを更新できます。 | EventBridge のルールとターゲットを使用してタスクをスケジュールします。 | [Amazon ECS EventBridge IAM ロール](CWE_IAM_role.md) |
| Amazon ECS インフラストラクチャロール | このロールにより、Amazon ECS はクラスター内のインフラストラクチャリソースを管理できます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-ecs-iam-role-overview.html) | [Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md) |
| インスタンスプロファイル | このロールにより、Amazon ECS マネージドインスタンスはインフラストラクチャロールを安全に引き受けることができます。 | クラスターで Amazon ECS マネージドインスタンスを使用します。 | [Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md) |
# Amazon ECS での IAM ロールのベストプラクティス
Amazon ECS が必要とするロールは、タスク定義の起動タイプと使用する機能によって異なります。ロールを共有するのではなく、テーブルに個別のロールを作成することをお勧めします。
| ロール | 定義 | 必要な場合 | 詳細情報 |
| --- | --- | --- | --- |
| タスク実行ロール | このロールにより、Amazon ECS がお客様に代わって他の AWS サービスを利用できるようにします。 | タスクは AWS Fargate または外部インスタンスホストされています。また、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-iam-roles.html) タスクは、AWS Fargate または Amazon EC2 インスタンスでホストされています。また、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-iam-roles.html) | [Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md) |
| タスクロール | このロールにより、(コンテナ上の) アプリケーションコードが他の AWS サービスを使用できるようになります。 | アプリケーションは、Amazon S3 などの他の AWS サービスにアクセスします。 | [Amazon ECS タスクの IAM ロール](task-iam-roles.md) |
| コンテナインスタンスのロール | このロールにより、EC2 インスタンスまたは外部インスタンスをクラスターに登録できます。 | タスクは Amazon EC2 インスタンスまたは外部インスタンスでホストされています。 | [Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md) |
| Amazon ECS Anywhere ロール | このロールにより、外部インスタンスが AWS API にアクセスできるようになります。 | タスクは外部インスタンスでホストされています。 | [Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md) |
| Amazon ECS CodeDeploy ロール | このロールにより、CodeDeploy はサービスを更新できます。 | CodeDeploy のブルー/グリーンデプロイタイプを使用して、サービスをデプロイします。 | [Amazon ECS CodeDeploy IAM ロール](codedeploy_IAM_role.md) |
| Amazon ECS EventBridge ロール | このロールにより、EventBridge はサービスを更新できます。 | EventBridge のルールとターゲットを使用してタスクをスケジュールします。 | [Amazon ECS EventBridge IAM ロール](CWE_IAM_role.md) |
| Amazon ECS インフラストラクチャロール | このロールにより、Amazon ECS はクラスター内のインフラストラクチャリソースを管理できます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-iam-roles.html) | [Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md) |
## タスクロール
タスクロールを割り当てることをお勧めします。このロールは、それが実行されている Amazon EC2 インスタンスのロールと区別することができます。各タスクにロールを割り当てることは、最小権限アクセスの原則に沿っており、アクションとリソースをよりきめ細かく制御できます。
タスクロールをタスク定義に追加すると、Amazon ECS コンテナエージェントはタスク用の固有の認証情報 ID (例: `12345678-90ab-cdef-1234-567890abcdef`) を持つトークンを自動的に作成します。その後、このトークンとロール認証情報はエージェントの内部キャッシュに追加されます。エージェントは、コンテナ内の環境変数 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` に認証情報 ID の URI (例: `/v2/credentials/12345678-90ab-cdef-1234-567890abcdef`) を入力します。
Amazon ECS コンテナエージェントの IP アドレスに環境変数を追加し、結果の文字列に対して `curl` コマンドを実行することで、コンテナ内から一時的なロール認証情報を手動で取得できます。
```
curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
```
予想される出力は次のようになります。
```
{
"RoleArn": "arn:aws:iam::123456789012:role/SSMTaskRole-SSMFargateTaskIAMRole-DASWWSF2WGD6",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token": "IQoJb3JpZ2luX2VjEEM/Example==",
"Expiration": "2021-01-16T00:51:53Z"
}
```
新しいバージョンの AWS SDK では、AWS API 呼び出しを行うと、これらの認証情報が `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` 環境変数から自動的に取得されます。認証情報を更新する方法については、rePost の「[AWS 認証情報の更新](https://repost.aws/questions/QUgcf1EIOPS7GZNboeAiyO9Q/renewing-aws-credentials)」を参照してください。
出力には、シークレットアクセスキー ID で構成されるアクセスキーペアと、アプリケーションが AWS リソースにアクセスするために使用するシークレットキーが含まれます。また、認証情報が有効であることを確認するために AWS が使用するトークンも含まれています。デフォルトでは、タスクロールを使用してタスクに割り当てられた認証情報は6 時間有効です。その後は、Amazon ECS コンテナエージェントによって自動的にローテーションされます。
## タスク実行ロール
タスク実行ロールは、ユーザーに代わって特定の AWS API アクションを呼び出すためのアクセス許可を Amazon ECS コンテナエージェントに付与するのに使用されます。たとえば、AWS Fargate を使用する場合、Fargate には Amazon ECR からイメージをプルして CloudWatch Logs にログを書き込むことができる IAM ロールが必要です。IAM ロールは、イメージプルシークレットなど、AWS Secrets Manager に保存されているシークレットをタスクが参照する場合にも必要です。
**注記**
認証されたユーザーとしてイメージをプルする場合、[Docker Hub のプルレート制限](https://www.docker.com/pricing/resource-consumption-updates)が変更されても、影響を受ける可能性は低くなります。詳細については、[「コンテナインスタンスのプライベートレジストリの認証」](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth-container-instances.html)を参照してください。
Amazon ECR と Amazon ECR パブリックを使用することで、Docker によって課せられる制限を回避できます。Amazon ECR からイメージをプルすると、ネットワークのプル時間を短縮し、トラフィックが VPC を離れる際のデータ転送の変更を減らすのにも役立ちます。
**重要**
Fargate を使用するときは、`repositoryCredentials` を使用してプライベートイメージレジストリの認証を行う必要があります。Amazon ECS コンテナエージェントの環境変数である `ECS_ENGINE_AUTH_TYPE` および `ECS_ENGINE_AUTH_DATA` を設定したり、Fargate でホストされているタスクの `ecs.config` ファイルを変更したりすることはできません。詳細については、「[タスクのプライベートレジストリの認証](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)」を参照してください。
## コンテナインスタンスのロール
`AmazonEC2ContainerServiceforEC2Role` 管理 IAM ポリシーには以下のアクセス許可が含まれています。最小権限を付与する標準のセキュリティアドバイスに従って、`AmazonEC2ContainerServiceforEC2Role` 管理ポリシーをガイドとして使用できます。ユースケースの管理ポリシーで付与されているアクセス許可が不要な場合、カスタムポリシーを作成し、必要なアクセス許可のみを追加します。
+ `ec2:DescribeTags` – (オプション) Amazon EC2 インスタンスに関連付けられているタグをプリンシパルが記述できるようになります。このアクセス許可は、リソースタグの伝播をサポートするために Amazon ECS コンテナエージェントによって使用されます。詳細については、「[リソースのタグ付け方法](ecs-using-tags.md#tag-resources)」を参照してください。
+ `ecs:CreateCluster` – (任意) プリンシパルが Amazon ECS クラスターを作成できるようになります。このアクセス許可は、Amazon ECS コンテナエージェントによって `default` クラスターが存在しない場合、このクラスタを作成するために使用されます。
+ `ecs:DeregisterContainerInstance` – (任意) プリンシパルがクラスターから Amazon ECS コンテナインスタンスを登録解除できるようになります。Amazon ECS コンテナエージェントはこの API 操作を呼び出しませんが、このアクセス許可は後方互換性を確保するために維持されます。
+ `ecs:DiscoverPollEndpoint` – (必須) このアクションは、Amazon ECS コンテナエージェントが更新のポーリングに使用するエンドポイントを返します。
+ `ecs:Poll` – (必須) Amazon ECS コンテナエージェントが Amazon ECS コントロールプレーンと通信し、タスクの状態の変更を報告できるようになります。
+ `ecs:RegisterContainerInstance` – (必須) プリンシパルがコンテナインスタンスをクラスターに登録できるようになります。このアクセス許可は、Amazon ECS コンテナエージェントが Amazon EC2 インスタンスをクラスターに登録し、リソースタグの伝播をサポートするために使用されます。
+ `ecs:StartTelemetrySession` – (任意) Amazon ECS コンテナエージェントが Amazon ECS コントロールプレーンと通信し、各コンテナおよびタスクのヘルス情報とメトリクスをレポートできるようになります。
このアクセス許可は必須ではありませんが、コンテナインスタンスのメトリクスがスケールアクションを開始できるようにし、ヘルスチェックコマンドに関連するレポートを受信できるようにするために、これを追加することをお勧めします。
+ `ecs:TagResource` – (任意) Amazon ECS コンテナエージェントが、作成時にクラスターにタグ付けしたり、コンテナインスタンスがクラスターに登録されたときにタグ付けしたりできるようになります。
+ `ecs:UpdateContainerInstancesState` — プリンシパルが Amazon ECS コンテナインスタンスのステータスを変更できるようにします。このアクセス許可は、スポットインスタンスのドレイン用に Amazon ECS コンテナエージェントによって使用されます。
+ `ecs:Submit*` – (必須) これには API アクション `SubmitAttachmentStateChanges`、`SubmitContainerStateChange`、および `SubmitTaskStateChange` が含まれています。これらは、Amazon ECS コンテナエージェントによって使用され、各リソースの状態変化を Amazon ECS コントロールプレーンに報告します。`SubmitContainerStateChange` アクセス許可は、Amazon ECS コンテナエージェントによって使用されなくなりますが、後方互換性を確保するために維持されます。
+ `ecr:GetAuthorizationToken` – (オプション) プリンシパルに認可トークンの取得を許可します。認可トークンは IAM 認証情報を表し、IAM プリンシパルによってアクセスされる Amazon ECR レジストリへのアクセスに使用できます。受け取る認可トークンは 12 時間有効です。
+ `ecr:BatchCheckLayerAvailability` – (任意) コンテナイメージが Amazon ECR プライベートリポジトリにプッシュされると、各イメージレイヤーに対してすでにプッシュされているかどうかが確認されます。その場合、そのイメージレイヤーはスキップされます。
+ `ecr:GetDownloadUrlForLayer` – (任意) コンテナイメージが Amazon ECR プライベートリポジトリからプルされると、この API が、まだキャッシュされていない各イメージレイヤーに対して 1 回呼び出されます。
+ `ecr:BatchGetImage` – (任意) コンテナイメージが Amazon ECR プライベートリポジトリからプルされると、この API が 1 回呼び出されてイメージマニフェストが取得されます。
+ `logs:CreateLogStream` – (任意) プリンシパルが、指定したロググループの CloudWatch Logs ログストリームを作成できるようになります。
+ `logs:PutLogEvents` – (任意) プリンシパルが、指定したログストリームにログイベントのバッチをアップロードできるようになります。
## サービスリンクロール
Amazon ECS のサービス連動ロールを使用して、Amazon ECS サービスに他のサービス API を代理で呼び出す許可を付与できます。Amazon ECS には、ネットワークインターフェイスの作成と削除、ターゲットグループへのターゲットの登録と登録解除を行う許可が必要です。また、スケーリングポリシーの作成と削除に必要な許可も必要です。これらの許可は、サービスにリンクされたロールによって付与されます。このロールは、サービスを初めて使用するときに、ユーザーに代わって作成されます。
**注記**
サービスにリンクされたロールを誤って削除してしまった場合は、ロールを再作成できます。手順については、[「サービスにリンクされたロールの作成」](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using-service-linked-roles.html#create-service-linked-role)を参照してください。
## ロールの推奨事項
タスクの IAM ロールとポリシーを設定するときは、以下を行うことをお勧めします。
### Amazon EC2 メタデータへのアクセスをブロックする
Amazon EC2 インスタンスでタスクを実行する場合、Amazon EC2 メタデータへのアクセスをブロックして、それらのインスタンスに割り当てられたロールをコンテナが継承しないようにすることを強くお勧めします。アプリケーションが AWS API アクションを呼び出す必要がある場合は、代わりに IAM ロールをタスクに使用してください。
**ブリッジ**モードで実行されているタスクが Amazon EC2 メタデータにアクセスしないようにするには、次のコマンドを実行するか、インスタンスのユーザーデータを更新します。インスタンスのユーザーデータを更新する方法の詳細については、この[AWS サポート記事](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-container-ec2-metadata/)を参照してください。タスク定義ブリッジモードについて詳しくは、「[タスク定義ネットワークモード](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#network_mode)」を参照してください。
```
sudo yum install -y iptables-services; sudo iptables --insert FORWARD 1 --in-interface docker+ --destination 169.254.169.254/32 --jump DROP
```
再起動後もこの変更が持続するようにするには、Amazon マシンイメージ (AMI) 固有の次のコマンドを実行します。
+ Amazon Linux 2
```
sudo iptables-save | sudo tee /etc/sysconfig/iptables && sudo systemctl enable --now iptables
```
+ Amazon Linux
```
sudo service iptables save
```
`awsvpc` ネットワークモードを使用するタスクでは、`/etc/ecs/ecs.config` ファイル内の環境変数 `ECS_AWSVPC_BLOCK_IMDS` を `true` に設定します。
`host` ネットワーク内で実行されているコンテナが Amazon EC2 メタデータにアクセスできないように、`ecs-agent config` ファイルの `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST` 変数を `false` に設定する必要があります。
### `awsvpc` ネットワークモードを使用する
`awsvpc` ネットワークモードを使用して、異なるタスクの間、またはタスクと Amazon VPC 内で実行される他のサービスとの間のトラフィックの流れを制限します。これにより、セキュリティの追加レイヤーが追加されます。`awsvpc` ネットワークモードは、Amazon EC2 で実行されるタスクをタスクレベルでネットワーク分離します。これは AWS Fargate のデフォルトモードであり、タスクにセキュリティグループを割り当てるのに使用できる唯一のネットワークモードです。
### 最終アクセス時間情報を使用してロールを絞り込む
一度も使用されていないか、しばらく使用されていないアクションは、削除することをお勧めします。そうすることで、望ましくないアクセスが発生するのを防ぐことができます。これを行うには、IAM によって提供される最終アクセス時間情報を確認し、使用されたことがない、または最近使用されていないアクションを削除します。これを行うには、次のステップに従ってください。
次のコマンドを実行して、参照されたポリシーの最終アクセス情報を示すレポートを生成します。
```
aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1
```
出力に表示されていた `JobId` を使用して、次のコマンドを実行します。これを実行すると、レポートの結果を表示できます。
```
aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9
```
詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed.html)」を参照してください。
### AWS CloudTrail に不審なアクティビティがないか監視する
AWS CloudTrail に不審なアクティビティがないか監視することができます。ほとんどの AWS API 呼び出しは AWS CloudTrail イベントとして記録されます。これらは AWS CloudTrail Insights によって分析され、`write` API 呼び出しに関連する疑わしい動作があればアラートが表示されます。これには、呼び出しの急増が含まれる場合があります。これらのアラートには、異常なアクティビティが発生した時間や、API に寄与した上位のアイデンティティ ARN などの情報が含まれます。
IAM ロールが割り当てられているタスクが実行するアクションは、AWS CloudTrail でイベントの `userIdentity` プロパティを調べることで特定できます。次の例では、`arn` に引き受けたロールの名前 `s3-write-go-bucket-role` が含まれ、その後にタスクの名前 `7e9894e088ad416eb5cab92afExample` が続きます。
```
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA36C6WWEJ2YEXAMPLE:7e9894e088ad416eb5cab92afExample",
"arn": "arn:aws:sts::123456789012:assumed-role/s3-write-go-bucket-role/7e9894e088ad416eb5cab92afExample",
...
}
```
**注記**
ロールを引き受けるタスクが Amazon EC2 コンテナインスタンスで実行されると、リクエストは Amazon ECS コンテナエージェントによって、`/var/log/ecs/audit.log.YYYY-MM-DD-HH` フォーマットのアドレスにあるエージェントの監査ログに記録されます。詳細については、「[タスクの IAM ロール ログ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html#task_iam_roles-logs)」 と 「[証跡のインサイトイベントの記録](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-insights-events-with-cloudtrail.html)」を参照してください。
# Amazon ECS タスク実行IAM ロール
タスク実行ロールは、ユーザーに代わって AWS API コールを実行するためのアクセス許可を Amazon ECS コンテナと Fargate エージェントに付与します。タスク実行 IAM ロールは、タスクの要件に応じて必要です。さまざまな目的とサービスのタスク実行ロールを、アカウントに複数関連付けることができます。
**注記**
これらのアクセス許可は、Amazon ECS が定期的にロールの一時的な認証情報を送信することで、インスタンスで実行されているエージェントが使用できるようになりますが、タスク内のコンテナからは直接アクセスできません。コンテナ内のアプリケーションコードの実行に必要な IAM 許可については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
以下に示しているのは、タスク実行 IAM ロールの一般的なユースケースです。
+ タスクは AWS Fargate、Amazon ECS マネージドインスタンス、または外部インスタンスでホストされており、次の動作を行います。
+ Amazon ECR プライベートリポジトリからコンテナイメージをプルします。
+ タスクを実行するアカウントとは別のアカウントの Amazon ECR プライベートリポジトリからコンテナイメージをプルします。
+ `awslogs` ログドライバーを使用して CloudWatch Logs にコンテナログを送信します。詳細については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
+ タスクは、AWS Fargate または Amazon EC2 インスタンスでホストされています。また、
+ プライベートレジストリの認証を使用します。詳細については、「[プライベートレジストリ認証のアクセス許可](#task-execution-private-auth)」を参照してください。
+ Runtime Monitoring を使用します。
+ タスク定義は、Secrets Manager のシークレットまたは AWS Systems Manager Parameter Store のパラメータを使用して機密データを参照します。詳細については、「[Secrets Manager または Systems Manager のアクセス許可](#task-execution-secrets)」を参照してください。
**注記**
タスク実行ロールは Amazon ECS コンテナエージェントバージョン 1.16.0 以降でサポートされています。
Amazon ECS は、`AmazonECSTaskExecutionRolePolicy` という管理ポリシーを提供します。このポリシーには、上記の一般的ユースケースで必要なアクセス許可が含まれています。詳細については、「*AWS Managed Policy リファレンスガイド*」の「[AmazonECSTaskExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSTaskExecutionRolePolicy.html)」を参照してください。特殊なユースケースでは、タスク実行ロールにインラインポリシーを追加する必要がある可能性があります。
Amazon ECS コンソールで、ECS タスク実行ロールを作成します。追加の機能や機能強化が導入された場合に Amazon ECS がそのアクセス許可を追加できるように、タスクのマネージド IAM ポリシーを手動でアタッチすることができます。IAM コンソールの検索を使用して `ecsTaskExecutionRole` を検索すると、アカウントにすでにタスク実行ロールがあるかどうかを確認できます。詳細については、「*IAM ユーザーガイド*」の「[IAM コンソールの検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_search.html)」を参照してください。
認証されたユーザーとしてイメージをプルすると、[Docker Hub の使用量と制限](https://docs.docker.com/docker-hub/usage/)が変更された場合でも、影響を受ける可能性が低くなります。詳細については、[「コンテナインスタンスのプライベートレジストリの認証」](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth-container-instances.html)を参照してください。
Amazon ECR と Amazon ECR パブリックを使用することで、Docker によって課せられる制限を回避できます。Amazon ECR からイメージをプルすると、ネットワークのプル時間を短縮し、トラフィックが VPC を離れる際のデータ転送の変更を減らすのにも役立ちます。
Fargate を使用するときは、`repositoryCredentials` を使用してプライベートイメージレジストリの認証を行う必要があります。Amazon ECS コンテナエージェントの環境変数である `ECS_ENGINE_AUTH_TYPE` および `ECS_ENGINE_AUTH_DATA` を設定したり、Fargate でホストされているタスクの `ecs.config` ファイルを変更したりすることはできません。詳細については、「[タスクのプライベートレジストリの認証](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)」を参照してください。
## タスク実行 ロールの作成
アカウントにまだタスク実行ロールがない場合は、次のステップに従ってロールを作成します。
------
#### [ AWS マネジメントコンソール ]
**Elastic Container Service のサービスロールを作成するには (IAM コンソール)**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールを作成]** を選択します。
1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。
1. **[サービスまたはユースケース]** で **[エラスティックコンテナサービス]** を選択し、次に **[エラスティックコンテナのサービスタスク]** を選択します。
1. [**次へ**] を選択します。
1. **[アクセス許可の追加]** セクションで **[AmazonECSTaskExecutionRolePolicy]** を検索し、ポリシーを選択します。
1. [**次へ**] を選択します。
1. **[ロール名]** に **[ECSTaskExecutionRole]** と入力します。
1. ロールを確認したら、**[ロールを作成]** を選択します。
------
#### [ AWS CLI ]
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. IAM ロールに使用する信頼ポリシーが含まれている `ecs-tasks-trust-policy.json` という名前のファイルを作成します。ファイルには次の内容が含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用した `ecsTaskExecutionRole` という名前の IAM ロールを作成します。
```
aws iam create-role \
--role-name ecsTaskExecutionRole \
--assume-role-policy-document file://ecs-tasks-trust-policy.json
```
1. AWS 管理 `AmazonECSTaskExecutionRolePolicy` ポリシー `ecsTaskExecutionRole` をロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ecsTaskExecutionRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
```
------
ロールを作成したら、次の機能のアクセス許可をロールに追加します。
| 機能 | 追加のアクセス許可 |
| --- | --- |
| Secrets Manager 認証情報を使用して、AWS の外部のプライベートレジストリ (Docker Hub、Quay.io、独自のプライベートレジストリなど) からコンテナイメージをプルする | [プライベートレジストリ認証のアクセス許可](#task-execution-private-auth) |
| Systems Manager または Secrets Manager を使用して機密データを渡す | [Secrets Manager または Systems Manager のアクセス許可](#task-execution-secrets) |
| Fargate タスクが、インターネットエンドポイントを介して Amazon ECR イメージをプルできるようにする | [インターフェイスエンドポイントのアクセス許可によって Amazon ECR イメージをプルする Fargate タスクです。](#task-execution-ecr-conditionkeys) |
| 設定ファイルを Amazon S3 バケットでホストする | [Amazon S3 ファイルストレージのアクセス許可](#s3-required) |
| Amazon ECS ライフサイクルイベントを表示するように Container Insights を設定する | [Amazon ECS ライフサイクルイベントを Container Insights で表示するために必要なアクセス許可](console-permissions.md#required-permissions-configure) |
| Container Insights に Amazon ECS ライフサイクルイベントを表示する | [Amazon ECS ライフサイクルイベントを Container Insights で表示するには、以下のアクセス許可が必要です。](console-permissions.md#required-permissions-view) |
## プライベートレジストリ認証のアクセス許可
プライベートレジストリ認証を使用すると、Amazon ECS タスクは、認証情報を必要とする AWS の外部のプライベートレジストリ (Docker Hub、Quay.io、独自のプライベートレジストリなど) からコンテナイメージをプルできます。この機能は Secrets Manager を使用してレジストリ認証情報を安全に保存し、`repositoryCredentials` パラメータを使用してタスク定義で参照します。
プライベートレジストリ認証の設定の詳細については、「[Amazon ECS での非 AWS コンテナイメージの使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)」を参照してください。
プライベートレジストリ認証情報を含むシークレットにアクセスできるようにするには、以下のアクセス許可を、インラインポリシーとしてタスクの実行ロールに追加します。詳細については、「[IAM ポリシーの追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
+ `secretsmanager:GetSecretValue`— Secrets Manager からプライベートレジストリ認証情報を取得するために必要です。
+ `kms:Decrypt` – シークレットでカスタムの KMS キーを使用し、デフォルトのキーを使用しない場合にのみ必須です。カスタムキーの Amazon リソースネーム (ARN) は、リソースとして追加する必要があります。
次の例では、インラインポリシーによりアクセス許可を追加しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name",
"arn:aws:kms:us-east-1:111122223333:key/key_id"
]
}
]
}
```
------
## Secrets Manager または Systems Manager のアクセス許可
コンテナエージェントが必要な AWS Systems Manager または Secrets Manager のリソースをプルできるようにするためのアクセス許可です。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
**Secrets Manager の使用**
作成した Secrets Manager シークレットにアクセスできるようにするには、タスクの実行ロールに対し、以下のアクセス許可を手動により追加します。アクセス許可の管理の詳細については、「*IAM ユーザーガイド*」の「[IAM ID のアクセス許可の追加および削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
+ `secretsmanager:GetSecretValue` – Secrets Manager シークレットを参照する場合に必須です。Secrets Manager からシークレットを取得するための許可を追加します。
次のポリシーの例では、必須のアクセス許可を追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name"
]
}
]
}
```
------
**Systems Manager の使用**
**重要**
EC2 起動タイプを使用するタスクの場合、この機能を使用するには ECS エージェント設定変数 `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` を使用する必要があります。コンテナインスタンスの作成時に `./etc/ecs/ecs.config` ファイルに追加するか、既存のインスタンスに追加して ECS エージェントを再起動できます。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
作成した Systems Manager Parameter Store のパラメータにアクセスできるようにするには、タスク実行ロールに対し、以下のアクセス許可を手動で追加する必要があります。アクセス許可の管理の詳細については、「*IAM ユーザーガイド*」の「[IAM ID のアクセス許可の追加および削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
+ `ssm:GetParameters` – Systems Manager Parameter Store のパラメータをタスク定義で参照している場合は必須です。Systems Manager パラメータを取得するための許可を追加します。
+ `secretsmanager:GetSecretValue` – Secrets Manager シークレットをユーザーが直接参照している、あるいは、Systems Manager Parameter Store のパラメータが、タスク定義で Secrets Manager シークレットを参照している場合は必須です。Secrets Manager からシークレットを取得するための許可を追加します。
+ `kms:Decrypt` – シークレットが、デフォルトのキーではなく、カスタマーマネージドのキーを使用している場合にのみ必須です。そのカスタムキーの ARN はリソースとして追加されている必要があります。カスタマーマネージドキーを復号するための許可を追加します。
次の例のポリシーでは、必須のアクセス許可を追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"secretsmanager:GetSecretValue",
"kms:Decrypt"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:parameter/parameter_name",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name",
"arn:aws:kms:us-east-1:111122223333:key/key_id"
]
}
]
}
```
------
## インターフェイスエンドポイントのアクセス許可によって Amazon ECR イメージをプルする Fargate タスクです。
Amazon ECR がインターフェイス VPC エンドポイントを使用するように設定されている場合、Amazon ECR からイメージをプルする Fargate を使用するタスクを起動するときは、特定の VPC または VPC エンドポイントへのアクセスにタスクを制限できます。この操作を行うには、IAM 条件キーを使用するタスクのタスク実行ロールを作成します。
次の IAM グローバル条件キーを使用して、特定の VPC または VPC エンドポイントへのアクセスを制限します。詳細については、「[AWSvグローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
+ `aws:SourceVpc` - 特定の VPC へのアクセスを制限します。タスクとエンドポイントをホストする VPC に制限できます。
+ `aws:SourceVpce` - 特定の VPC エンドポイントへのアクセスを制限します。
次のタスク実行ロールポリシーは、条件キーを追加する方法の例を示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:*:*:repository/*",
"Condition": {
"StringEquals": {
"aws:sourceVpce": "vpce-0123456789abcdef0"
}
}
}
]
}
```
------
## Amazon ECR のアクセス許可
Amazon ECR プライベートリポジトリからコンテナイメージをプルする必要がある場合は、以下のアクセス許可が必要です。タスクの実行ロールには、Amazon ECS コンテナと Fargate エージェントがユーザーに代わってコンテナイメージをプルできるように、これらのアクセス許可が必要です。基本的な ECS 実装の場合、これらのアクセス許可は、タスクの IAM ロールではなく、タスクの実行ロールに追加する必要があります。
Amazon ECS タスクの実行ロール管理ポリシー (`AmazonECSTaskExecutionRolePolicy`) には、Amazon ECR からイメージをプルするために必要なアクセス許可が含まれています。マネージドポリシーを使用している場合は、これらのアクセス許可を個別に追加する必要はありません。
カスタムポリシーを作成する場合は、以下のアクセス許可を含めて、Amazon ECR からのイメージのプルを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken"
],
"Resource": "*"
}
]
}
```
------
これらのアクセス許可は、アプリケーションコードが Amazon ECR API と直接やり取りする必要がある場合に、タスクの IAM ロールで必要となるアクセス許可とは異なることに注意してください。Amazon ECR におけるタスクの IAM ロールのアクセス許可の詳細については、「[Amazon ECR のアクセス許可](task-iam-roles.md#ecr-required-iam-permissions)」を参照してください。
## Amazon S3 ファイルストレージのアクセス許可
Amazon S3 でホストされる設定ファイルを指定する場合、タスク実行ロールには、設定ファイルに対する `s3:GetObject` アクセス許可と、ファイルが格納されている Amazon S3 バケットでの `s3:GetBucketLocation` アクセス許可が含まれている必要があります。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 のポリシーアクション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security_iam_service-with-iam.html#security_iam_service-with-iam-id-based-policies-actions)」を参照してください。
次のポリシーの例では、Amazon S3 からファイルを取得するために必要なアクセス許可を追加します。Amazon S3 バケットの名前と設定ファイル名を指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/folder_name/config_file_name"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
### セキュリティに関する重要な考慮事項
Amazon S3 バケットと統合する Amazon ECS 機能を使用する場合は、バケットの所有権検証を実装して、バケット乗っ取り攻撃を防止します。適切な検証を実行しない場合、悪意のあるアクターが Amazon S3 バケットを削除し、同じ名前のバケットを再作成すると、知らないうちにタスクが悪意のある設定を読み込む、攻撃者が管理するバケットに機密データを送信するなどの事態が発生する可能性があります。
**推奨される IAM ポリシー条件:**
```
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "TRUSTED-ACCOUNT-ID"
}
}
```
*TRUSTED–ACCOUNT–ID* を、S3 バケットを所有する AWS アカウント ID に置き換えます。
この条件により、タスク実行ロールは、指定された信頼されたアカウントが所有する Amazon S3 バケットにのみアクセスできるようになります。
# Amazon ECS タスクの IAM ロール
Amazon ECS タスクには IAM ロールを関連付けることができます。IAM ロールで付与されるアクセス許可は、タスクで実行中のコンテナに対し発行されます。このロールにより、(コンテナ上で実行) アプリケーションコードが他の AWS サービスを使用できるようになります。タスクロールは、アプリケーションが Amazon S3 などの他の AWS サービスにアクセスするときに必要です。
**注記**
これらのアクセス許可は、Amazon ECS コンテナと Fargate エージェントからはアクセスされません。Amazon ECS がコンテナイメージをプルしてタスクを実行するために必要な IAM 許可については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
タスクロールを使用する利点は次のとおりです。
+ **懸念事項の分離**: EC2 を使用している場合、タスク IAM ロールを使用すると、EC2 インスタンスプロファイルを使わずにコンテナの IAM アクセス許可を指定できます (詳細については、「**AWS Identity and Access Management ユーザーガイド」の「[インスタンスプロファイルの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)」を参照してください)。したがって、EC2 インスタンスに関連付けられた IAM アクセス許可を変更することなく、アプリケーションを ECS コンテナインスタンスに個別かつ均一にデプロイできます。
+ **監査性:** CloudTrail にアクセスしイベントのログ記録を利用することで、遡及的な監査を確実に行えます。タスクの認証情報には、セッションにアタッチされている `taskArn` のコンテキストがあるため、CloudTrail ログにはロールの認証情報が発行されたタスクが表示されます。
+ **統一された認証情報配信**: ECS は IAM ロール認証情報をコンテナに配信し、タスクに関連付けられたコンピューティングオプションに関係なく、明確に定義されたインターフェイスを介してアクセスできるようにします。ECS Fargate では、EC2 インスタンスプロファイルはタスク内のコンテナでは使用できません。タスク IAM ロールを使用すると、コンテナで AWS SDK または AWS CLI を使用する場合、コンピューティングオプションに関係なく、コンテナに IAM アクセス許可を関連付けることができます。AWS SDK がこれらの認証情報にアクセスする方法の詳細については、「[コンテナ認証情報プロバイダー](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html)」を参照してください。
**重要**
コンテナはセキュリティ境界ではなく、タスク IAM ロールを使用しても変更されません。Fargate で実行されている各タスクは、独自の分離境界を持ち、基盤となるカーネル、CPU リソース、メモリリソース、Elastic Network Interface を別のタスクと共有しません。ECS 上の EC2 および外部コンテナインスタンスの場合、タスクの分離はなく (Fargate とは異なり）、コンテナは同じコンテナインスタンス上の他のタスクの認証情報にアクセスできる可能性があります。[ECS コンテナインスタンスロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html)に割り当てられたアクセス許可にアクセスすることもできます。[ロールの推奨事項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-roles.html#security-iam-roles-recommendations)に従って、コンテナの Amazon EC2 インスタンスメタデータサービスへのアクセスをブロックします (詳細については、「**Amazon EC2 ユーザーガイド」の「[インスタンスメタデータサービスを使用してインスタンスメタデータにアクセスする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください)。
タスク用の IAM ロールを指定すると、そのタスクのコンテナ内の AWS CLI または他の SDK は、タスクロールによって提供された AWS 認証情報を排他的に使用し、Amazon EC2 または外部インスタンスで実行されていて、それらから IAM 許可を継承しなくなる点に注意してください。
## タスクの IAM ロールを作成する
タスクで使用する IAM ポリシーを作成するときは、そのポリシーはタスクのコンテナが引き受けるタスクの許可を含める必要があります。既存の AWS マネージドポリシーを使用することも、特定のニーズを満たすカスタムポリシーを最初から作成することもできます。詳細については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
**重要**
Amazon ECS タスク (すべての起動タイプ) では、タスクに IAM ポリシーとロールを使用することをお勧めします。これらの認証情報により、タスクは `sts:AssumeRole` を呼び出してタスクに既に関連付けられているのと同じロールを引き受けることなく、AWS API リクエストを行うことができます。タスクでロールがそれ自体を引き受けることが必要な場合、そのロールがそれ自体を引き受けることを明示的に許可する信頼ポリシーを作成する必要があります。詳細については、「**IAM ユーザーガイド」の「[ロール信頼ポリシーの更新](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)」を参照してください。
IAM ポリシーを作成した後、Amazon ECS タスク定義で参照するポリシーを含む IAM ロールを作成できます。IAM コンソールで **[Elastic Container Service Task]** (Elastic Container Service タスク) ユースケースを使用してロールを作成できます。その後、タスクのコンテナに必要なアクセス許可を付与するロールに特定の IAM ポリシーをアタッチできます。次の手順では、これを行う方法について説明します。
IAM のアクセス許可を必要とする複数のタスク定義またはサービスがある場合は、各タスクに提供するアクセスを最小限に抑えるために、タスクを操作するために必要な最小限のアクセス許可で特定のタスク定義またはサービスごとにロールを作成することを検討してください。
リージョンのサービスエンドポイントの詳細については、「*Amazon Web Services 全般のリファレンス ガイド*」の「[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html#ecs_region)」を参照してください。
IAM タスクロールは、`ecs-tasks.amazonaws.com` サービスを特定する信頼ポリシーが必要です。`sts:AssumeRole` 許可は、Amazon EC2 インスタンスが使用するロールとは異なる IAM ロールをタスクに引き受けられるようにします。これにより、タスクは Amazon EC2 インスタンスに関連付けられたロールを継承しません。以下に示しているのは、信頼ポリシーの例です。リージョン識別子を置き換えて、タスク起動時に使用する AWS アカウント番号を特定します。
**重要**
タスク IAM ロールを作成するときは、ロールに関連付けられた信頼関係ポリシーで `aws:SourceAccount` または `aws:SourceArn` のいずれかの条件キーを使用してアクセス許可のスコープを明確にし、混乱した代理のセキュリティ問題の発生を防止するよう推奨します。特定のクラスターを指定する `aws:SourceArn` 条件キーの使用は現在サポートされていません。ワイルドカードを使用してすべてのクラスターを指定する必要があります。混乱した代理の問題と、お客様の AWS アカウントの保護方法の詳細について学ぶためには、[[The confused deputy problem]](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) (IAM ユーザーガイド) の*[IAM User Guide]* (混乱した代理の問題) を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":[
"ecs-tasks.amazonaws.com"
]
},
"Action":"sts:AssumeRole",
"Condition":{
"ArnLike":{
"aws:SourceArn":"arn:aws:ecs:us-west-2:111122223333:*"
},
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
------
以下の手順では、Amazon S3 からオブジェクトを取得するポリシーを作成する方法を、ポリシー例とともに説明します。すべての*ユーザー入力*を自分の値に置き換えてください。
------
#### [ AWS マネジメントコンソール ]
**JSON ポリシーエディタでポリシーを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。
初めて **[ポリシー]** を選択する場合には、**[管理ポリシーにようこそ]** ページが表示されます。**今すぐ始める** を選択します。
1. ページの上部で、**[ポリシーを作成]** を選択します。
1. **ポリシーエディタ** セクションで、**JSON** オプションを選択します。
1. 次の JSON ポリシードキュメントを入力します。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"s3:GetObject"
],
"Resource":[
"arn:aws:s3:::my-task-secrets-bucket/*"
]
}
]
}
```
1. [**次へ**] を選択します。
**注記**
いつでも **Visual** と **JSON** エディタオプションを切り替えることができます。ただし、**[ビジュアル]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、*IAM ユーザーガイド* の [ポリシーの再構成](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html#troubleshoot_viseditor-restructure) を参照してください。
1. **確認と作成** ページで、作成するポリシーの **ポリシー名** と **説明** (オプション) を入力します。**このポリシーで定義されているアクセス許可** を確認して、ポリシーによって付与されたアクセス許可を確認します。
1. **ポリシーを作成** をクリックして、新しいポリシーを保存します。
------
#### [ AWS CLI ]
すべての*ユーザー入力*を自分の値に置き換えてください。
1. `s3-policy.json` というファイルを次の内容で作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"s3:GetObject"
],
"Resource":[
"arn:aws:s3:::my-task-secrets-bucket/*"
]
}
]
}
```
------
1. JSON ポリシードキュメントファイルを使用して IAM ポリシーを作成するには、次の コマンドを使用します。すべての*ユーザー入力*を自分の値に置き換えてください。
```
aws iam create-policy \
--policy-name taskRolePolicy \
--policy-document file://s3-policy.json
```
------
次の手順を使用してサービスロールを作成します。
------
#### [ AWS マネジメントコンソール ]
**Elastic Container Service のサービスロールを作成するには (IAM コンソール)**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールを作成]** を選択します。
1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。
1. **[サービスまたはユースケース]** で **[エラスティックコンテナサービス]** を選択し、次に **[エラスティックコンテナのサービスタスク]** を選択します。
1. [**次へ**] を選択します。
1. **[アクセス許可の追加]** で、作成したポリシーを検索し、選択します。
1. [**次へ**] を選択します。
1. **ロール名** に、ロールの名前を入力します。この例では、`AmazonECSTaskS3BucketRole` と入力してロールに名前を付けます。
1. ロールを確認したら、**[ロールを作成]** を選択します。
------
#### [ AWS CLI ]
1. タスク IAM ロールに使用する信頼ポリシーが含まれている `ecs-tasks-trust-policy.json` という名前のファイルを作成します。ファイルには次の内容が含まれます。リージョン識別子を置き換えて、タスク起動時に使用する AWS アカウント番号を特定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":[
"ecs-tasks.amazonaws.com"
]
},
"Action":"sts:AssumeRole",
"Condition":{
"ArnLike":{
"aws:SourceArn":"arn:aws:ecs:us-west-2:111122223333:*"
},
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用した `ecsTaskRole` という名前の IAM ロールを作成します。
```
aws iam create-role \
--role-name ecsTaskRole \
--assume-role-policy-document file://ecs-tasks-trust-policy.json
```
1. 次のコマンドを使用して、作成した IAM ポリシーの ARN を取得します。*taskRolePolicy* は、作成したポリシーの名前に置き換えます。
```
aws iam list-policies --scope Local --query 'Policies[?PolicyName==`taskRolePolicy`].Arn'
```
1. 作成した IAM ポリシーを、`ecsTaskRole` ロールにアタッチします。`policy-arn` を、作成したポリシーの ARN に置き換えます。
```
aws iam attach-role-policy \
--role-name ecsTaskRole \
--policy-arn arn:aws:iam:111122223333:aws:policy/taskRolePolicy
```
------
ロールを作成したら、次の機能のアクセス許可をロールに追加します。
| 機能 | 追加のアクセス許可 |
| --- | --- |
| ECS Exec を使用する | [ECS Exec のアクセス許可](#ecs-exec-required-iam-permissions) |
| プライベート Amazon ECR リポジトリからのイメージを使用する | [Amazon ECR のアクセス許可](#ecr-required-iam-permissions) |
| EC2 インスタンスを使用する (Windows および Linux) | [Amazon EC2 インスタンスの追加設定](#task-iam-role-considerations) |
| 外部インスタンスを使用する | [外部インスタンスの追加設定](#enable_task_iam_roles) |
| EC2 Windows インスタンスを使用する | [Amazon EC2 Windows インスタンスの追加設定](#windows_task_IAM_roles) |
## Amazon ECR のアクセス許可
アプリケーションコードが直接 Amazon ECR リポジトリとやり取りする必要がある場合は、次のアクセス許可が必要です。Amazon ECR からイメージをプルするだけの基本的な実装では、これらのアクセス許可はタスク IAM ロールレベルでは必要ありません。代わりに、Amazon ECS タスク実行ロールにこれらのアクセス許可が必要です。タスクの実行ロールの詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
コンテナで実行されているアプリケーションコードが Amazon ECR API と直接やり取りする必要がある場合は、タスクの IAM ロールに次のアクセス許可を追加し、タスク定義にタスクの IAM ロールを含める必要があります。詳細については、*IAM ユーザーガイド*の[IAM ポリシーの追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)を参照してください。
タスク IAM ロールに次のポリシーを使用して、Amazon ECR と直接やり取りする必要があるコンテナアプリケーションに必要な Amazon ECR アクセス許可を追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken"
],
"Resource": "*"
}
]
}
```
------
## ECS Exec のアクセス許可
[ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) 機能には、マネージド型 SSM エージェント (`execute-command` エージェント) と SSM サービス間の通信に必要なアクセス許可をコンテナに付与するためのタスク IAM ロールが必要です。次のアクセス許可をタスク IAM ロールに追加し、タスク定義にタスク IAM ロールを含める必要があります。詳細については、*IAM ユーザーガイド*の[IAM ポリシーの追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)を参照してください。
タスク IAM ロールに次のポリシーを使用して、必要な SSM アクセス許可を追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
```
------
## Amazon EC2 インスタンスの追加設定
コンテナインスタンスのロールの許可は、以下に提供されるマネージド型 `AmazonEC2ContainerServiceforEC2Role` IAM ポリシーの許可のミニマリストに制限することをお勧めします。
Amazon EC2 インスタンスは、タスクのロールを使用するために、コンテナエージェントのバージョン `1.11.0` 以上が必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認と最新バージョンへの更新については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。Amazon ECS に最適化された AMI を使用している場合、インスタンスには、`ecs-init` パッケージの `1.11.0-1` 以降が必要です。インスタンスが最新 Amazon ECS に最適化された AMI を使用している場合、コンテナエージェントおよび `ecs-init` の必要なバージョンが含まれます。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
コンテナインスタンスで Amazon ECS に最適化された AMI を使用していない場合、エージェントを開始する `--net=host` コマンドと、目的の設定に次のエージェント設定変数に **docker run** オプションを追加してください (詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください)。
`ECS_ENABLE_TASK_IAM_ROLE=true`
`bridge` および `default` のネットワークモードに設定されたコンテナのタスク用の、IAM ロールを使用します。
`ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true`
`host` ネットワークモードに設定されたコンテナのタスク用の、IAM ロールを使用します。この変数はエージェントバージョン 1.12.0 以降でのみサポートされています。
実行コマンドの例の詳細については、「[Amazon ECS コンテナエージェントの手動更新（Amazon ECS 最適化以外の AMI の場合）](manually_update_agent.md)」を参照してください。また、タスクのコンテナが AWS 認証情報を取得できるよう、次のネットワーキングコマンドをコンテナインスタンスで設定する必要があります。
```
sudo sysctl -w net.ipv4.conf.all.route_localnet=1
sudo iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
sudo iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
```
再起動後も有効にするには、コンテナインスタンスにこれらの **iptables** ルールを保存する必要があります。**iptables-save** および **iptables-restore** コマンドを使用して、**iptables** ルールを保存し、起動時にそのルールを復元します。詳細については、特定のオペレーティングシステムのドキュメントを参照してください。
`awsvpc` ネットワークモードを使用するタスクで実行されたコンテナが、Amazon EC2 のインスタンスプロファイルに入力されている認証情報にアクセスを防止するためには (タスクロールで指定されている許可は有効)、エージェントの設定 ファイルで `ECS_AWSVPC_BLOCK_IMDS` エージェント 設定変数を `true` に設定し、そのエージェントを再起動します。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
`bridge` ネットワークモードを使用するタスクで実行されたコンテナが、Amazon EC2 のインスタンスプロファイルに入力されている認証情報にアクセスを防止するためには (タスクロールで指定されている許可は有効)、Amazon EC2 インスタンスで次の **iptables** コマンドを実行します。このコマンドは、`host` または `awsvpc` ネットワークモードを使用するタスク内のコンテナに影響を与えることはありません。詳細については、「[ネットワークモード](task_definition_parameters.md#network_mode)」を参照してください。
+
```
sudo yum install -y iptables-services; sudo iptables --insert DOCKER-USER 1 --in-interface docker+ --destination 169.254.169.254/32 --jump DROP
```
再起動後も有効にするには、Amazon EC2 インスタンスでこの **iptables** ルールを保存する必要があります。Amazon ECS に最適化された AMI を使用する場合は、次のコマンドを使用します。他のオペレーティングシステムの場合、そのオペレーティングシステムのドキュメントを参照してください。
```
sudo iptables-save | sudo tee /etc/sysconfig/iptables && sudo systemctl enable --now iptables
```
## 外部インスタンスの追加設定
外部インスタンスは、タスクの IAM ロールを使用にするために、コンテナエージェントのバージョン `1.11.0` 以上が必要ですが、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認と最新バージョンへの更新については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。Amazon ECS に最適化された AMI を使用している場合、インスタンスは、`1.11.0-1` パッケージの `ecs-init` バージョン以降が必要です。インスタンスが最新 Amazon ECS に最適化された AMI を使用している場合、コンテナエージェントおよび `ecs-init` の必要なバージョンが含まれます。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
コンテナインスタンスで Amazon ECS に最適化された AMI を使用していない場合、エージェントを開始する `--net=host` コマンドと、目的の設定に次のエージェント設定変数に **docker run** オプションを追加してください (詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください)。
`ECS_ENABLE_TASK_IAM_ROLE=true`
`bridge` および `default` のネットワークモードに設定されたコンテナのタスク用の、IAM ロールを使用します。
`ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true`
`host` ネットワークモードに設定されたコンテナのタスク用の、IAM ロールを使用します。この変数はエージェントバージョン 1.12.0 以降でのみサポートされています。
実行コマンドの例の詳細については、「[Amazon ECS コンテナエージェントの手動更新（Amazon ECS 最適化以外の AMI の場合）](manually_update_agent.md)」を参照してください。また、タスクのコンテナが AWS 認証情報を取得できるよう、次のネットワーキングコマンドをコンテナインスタンスで設定する必要があります。
```
sudo sysctl -w net.ipv4.conf.all.route_localnet=1
sudo iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
sudo iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
```
再起動後も有効にするには、コンテナインスタンスにこれらの **iptables** ルールを保存する必要があります。**iptables-save** および **iptables-restore** コマンドを使用して、**iptables** ルールを保存し、起動時にそのルールを復元します。詳細については、特定のオペレーティングシステムのドキュメントを参照してください。
## Amazon EC2 Windows インスタンスの追加設定
**重要**
これは、タスクロールを使用する EC2 上にある Windows コンテナにのみ適用されます。
Windows 機能を使用するタスクロールには EC2 での追加設定が必要です。
+ コンテナインスタンスを起動する際に、コンテナインスタンスのユーザーデータスクリプトの `-EnableTaskIAMRole` オプションを設定して、この機能を有効にする必要があります。`EnableTaskIAMRole`は、タスクの Task IAM ロール機能をオンにします。例えば、次のようになります。
```
Import-Module ECSTools
Initialize-ECSAgent -Cluster 'windows' -EnableTaskIAMRole
```
+ [Amazon ECS コンテナブートストラップスクリプト](#windows_task_IAM_roles_bootstrap) に提供されているネットワーキングコマンドを使用してコンテナをブートストラップする必要があります。
+ タスク用の IAM ロールとポリシーを作成する必要があります。詳細については、「[タスクの IAM ロールを作成する](#create_task_iam_policy_and_role)」を参照してください。
+ タスク認証情報プロバイダーの IAM ロールは、コンテナインスタンスのポート 80 を使用します。したがって、コンテナインスタンスでタスクの IAM ロールを設定にすると、コンテナはポートマッピングのホストポートにポート 80 を使用できません。コンテナをポート 80 で公開するには、負荷分散を使用するサービスをコンテナ用に設定することをお勧めします。ロードバランサーのポート 80 を使用できます。これにより、コンテナインスタンス上の別のホストポートにトラフィックをルーティングできます。詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。
+ Windows インスタンスが再起動された場合は、プロキシインターフェイスを削除して、Amazon ECS コンテナエージェントを再度初期化し、認証情報プロキシを元に戻す必要があります。
### Amazon ECS コンテナブートストラップスクリプト
コンテナからコンテナインスタンスの認証情報プロキシにアクセスする前に、必要なネットワーキングコマンドを使用してコンテナをブートストラップする必要があります。起動時にコンテナで次のコードのサンプルスクリプトを実行する必要があります。
**注記**
Windows で `awsvpc` ネットワークモードを使用している場合は、このスクリプトを実行する必要はありません。
Powershell を含む Windows コンテナを実行する場合は、次のスクリプトを使用します。
```
# Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"). You may
# not use this file except in compliance with the License. A copy of the
# License is located at
#
# http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file. This file is distributed
# on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
# express or implied. See the License for the specific language governing
# permissions and limitations under the License.
$gateway = (Get-NetRoute | Where { $_.DestinationPrefix -eq '0.0.0.0/0' } | Sort-Object RouteMetric | Select NextHop).NextHop
$ifIndex = (Get-NetAdapter -InterfaceDescription "Hyper-V Virtual Ethernet*" | Sort-Object | Select ifIndex).ifIndex
New-NetRoute -DestinationPrefix 169.254.170.2/32 -InterfaceIndex $ifIndex -NextHop $gateway -PolicyStore ActiveStore # credentials API
New-NetRoute -DestinationPrefix 169.254.169.254/32 -InterfaceIndex $ifIndex -NextHop $gateway -PolicyStore ActiveStore # metadata API
```
コマンドシェルのみを持つ Windows コンテナを実行する場合は、次のスクリプトを使用します。
```
# Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"). You may
# not use this file except in compliance with the License. A copy of the
# License is located at
#
# http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file. This file is distributed
# on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
# express or implied. See the License for the specific language governing
# permissions and limitations under the License.
for /f "tokens=1" %i in ('netsh interface ipv4 show interfaces ^| findstr /x /r ".*vEthernet.*"') do set interface=%i
for /f "tokens=3" %i in ('netsh interface ipv4 show addresses %interface% ^| findstr /x /r ".*Default.Gateway.*"') do set gateway=%i
netsh interface ipv4 add route prefix=169.254.170.2/32 interface="%interface%" nexthop="%gateway%" store=active # credentials API
netsh interface ipv4 add route prefix=169.254.169.254/32 interface="%interface%" nexthop="%gateway%" store=active # metadata API
```
# Amazon ECS コンテナインスタンスの IAM ロール
Amazon ECS コンテナインスタンス（Amazon EC2 と外部インスタンスの両方を含む）では、Amazon ECS コンテナエージェントを実行し、エージェントがユーザーに属していることをサービスに伝える IAM ロールが必要です。コンテナインスタンスを起動してクラスターに登録する前に、使用するコンテナインスタンス用の IAM ロールを作成する必要があります。ロールは、コンソールへのログインまたは AWS CLI コマンドの実行に使用するアカウントで作成されます。
**重要**
クラスターに外部インスタンスを登録する場合、使用する IAM ロールには Systems Manager のアクセス許可も必要です。詳細については、「[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md)」を参照してください。
Amazon ECS では、`AmazonEC2ContainerServiceforEC2Role` 管理 IAM ポリシーを提供し、これには Amazon ECS の完全な機能セットを使用するために必要なアクセス権限が含まれます。この管理ポリシーは、IAM ロールにアタッチし、コンテナインスタンスに関連付けることができます。または、使用するカスタムポリシーを作成するときに、管理ポリシーをガイドとして使用することもできます。コンテナインスタンスロールには、Amazon ECS コンテナエージェントと Docker デーモンがユーザーに変わって AWS API を呼び出すために必要な許可があります。管理ポリシーの詳細については、「[AmazonEC2ContainerServiceforEC2Role](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEC2ContainerServiceforEC2Role)」を参照してください。
## コンテナインスタンスロールを作成する
**重要**
クラスターに外部インスタンスを登録する場合は、[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md) を参照してください。
機能や機能強化が今後導入されたときに Amazon ECS がそれらに対するアクセス許可を追加できるように、手動でロールを作成し、その IAM 管理ポリシーをコンテナインスタンスにアタッチできます。必要に応じて、以下の手順を使用してマネージド IAM ポリシーをアタッチします。
------
#### [ AWS マネジメントコンソール ]
**Elastic Container Service のサービスロールを作成するには (IAM コンソール)**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールを作成]** を選択します。
1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。
1. **[サービスまたはユースケース]** で **[エラスティックコンテナサービス]** を選択し、次に **[エラスティックコンテナサービスのユースケースの EC2 ロール]** を選択します。
1. [**次へ**] を選択します。
1. **[アクセス許可ポリシー]** セクションで、**[AmazonEC2ContainerServiceforEC2Role]** ポリシーが選択されていることを確認します。
**重要**
**AmazonEC2ContainerServiceforEC2Role** 管理ポリシーは、コンテナインスタンス IAM ロールにアタッチする必要があります。アタッチされていない場合、AWS マネジメントコンソール をクリックして、クラスターを作成します。
1. [**次へ**] を選択します。
1. **[ロール名]** には、**[ecsInstanceRole]** と入力します。
1. ロールを確認したら、**[ロールを作成]** を選択します。
------
#### [ AWS CLI ]
すべての*ユーザー入力*を自分の値に置き換えてください。
1. `instance-role-trust-policy.json` というファイルを次の内容で作成します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
]
}
```
1. 信頼ポリシードキュメントを使用してインスタンスの IAM ロールを作成するには、次のコマンドを使用します。
```
aws iam create-role \
--role-name ecsInstanceRole \
--assume-role-policy-document file://instance-role-trust-policy.json
```
1. [create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html) コマンドを使用して、`ecsInstanceRole-profile` という名前のインスタンスプロファイルを作成します。
```
aws iam create-instance-profile --instance-profile-name ecsInstanceRole-profile
```
レスポンスの例
```
{
"InstanceProfile": {
"InstanceProfileId": "AIPAJTLBPJLEGREXAMPLE",
"Roles": [],
"CreateDate": "2022-04-12T23:53:34.093Z",
"InstanceProfileName": "ecsInstanceRole-profile",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole-profile"
}
}
```
1. `ecsInstanceRole` インスタンスプロファイルに `ecsInstanceRole-profile` ロールを追加します。
```
aws iam add-role-to-instance-profile \
--instance-profile-name ecsInstanceRole-profile \
--role-name ecsInstanceRole
```
1. 次のコマンドを使用して、`AmazonEC2ContainerServiceForEC2Role` マネージドポリシーをロールにアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role \
--role-name ecsInstanceRole
```
------
ロールを作成したら、次の機能のアクセス許可をロールに追加します。
| 機能 | 追加のアクセス許可 |
| --- | --- |
| Amazon ECR でコンテナイメージを取得する | [Amazon ECR のアクセス許可](#container-instance-role-ecr) |
| CloudWatch Logs でコンテナインスタンスをモニタリングする | [コンテナインスタンスのモニタリングに必要なアクセス許可](#cwl_iam_policy) |
| 設定ファイルを Amazon S3 バケットでホストする | [Amazon S3 への読み取り専用アクセス](#container-instance-role-s3) |
## Amazon ECR のアクセス許可
コンテナインスタンスで使用する Amazon ECS コンテナインスタンスロールには、Amazon ECR に対する以下の IAM ポリシーのアクセス許可が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken"
],
"Resource": "*"
}
]
}
```
------
コンテナインスタンスに `AmazonEC2ContainerServiceforEC2Role` 管理ポリシーを使用すると、ロールに適切なアクセス権限が付与されます。
## awsvpcTrunking アカウント設定の設定に必要なアクセス許可
Amazon ECS は、サポートされている Amazon EC2 インスタンスタイプを使用して、ENI 密度が高いコンテナインスタンスの起動をサポートします。この機能を使用する場合は、2 つのコンテナインスタンスロールを作成することをお勧めします。1 つのロールで `awsvpcTrunking` アカウント設定を有効にし、そのロールを ENI トランキングを必要とするタスクに使用します。`awsvpcTrunking` アカウント設定については、「[アカウント設定による Amazon ECS 機能へのアクセス](ecs-account-settings.md)」を参照してください。
コンテナインスタンスで使用するコンテナインスタンスロールには、アカウント設定を設定するための次の IAM ポリシーのアクセス許可が必要です
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:ListAccountSettings",
"ecs:ListAttributes",
"ecs:PutAccountSetting"
],
"Resource": "*"
}
]
}
```
------
コンテナインスタンスロールを使用するには、インスタンスユーザーデータに以下を追加します。
```
#!/bin/bash
aws ecs put-account-setting --name awsvpcTrunking --value enabled --region region
ECS_CLUSTER=MyCluster>> /etc/ecs/ecs.config
EOF
```
EC2 インスタンスへのユーザーデータの追加の詳細については、「*Amazon EC2 ユーザーガイド*」の「[起動時に Linux インスタンスでコマンドを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」を参照してください。
## Amazon S3 への読み取り専用アクセス
設定情報を Amazon S3 のプライベートバケットに保存し、コンテナインスタンスの IAM ロールに読み取り専用アクセス権限を付与するのが、コンテナインスタンスの起動時に設定を許可する安全で便利な方法です。`ecs.config` ファイルのコピーをプライベートバケットに保存し、Amazon EC2 ユーザーデータを使用して AWS CLI をインストールします。その後、インスタンスの起動時に設定情報を `/etc/ecs/ecs.config` にコピーします。
`ecs.config` ファイルの作成と Amazon S3 への保存、およびこの構成を使用したインスタンスの起動の詳細については、「[Amazon S3 に Amazon ECS コンテナインスタンスの設定を保存する](ecs-config-s3.md)」を参照してください。
次の AWS CLI コマンドを使用すると、Amazon S3 の読み取り専用アクセス許可をコンテナインスタンスのロールに許可できます。前に作成したロールの名前で *ecsInstanceRole* を置き換えます。
```
aws iam attach-role-policy \
--role-name ecsInstanceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
```
IAM コンソールを使用して、Amazon S3 の読み取り専用アクセス許可 (`AmazonS3ReadOnlyAccess`) をロールに追加することもできます。詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。
## コンテナインスタンスのモニタリングに必要なアクセス許可
コンテナインスタンスが CloudWatch Logs にログデータを送信する前に、Amazon ECS エージェントがお客様のアプリケーションログを CloudWatch に書き込むことを許可する IAM ポリシーを作成する必要があります (通常は `awslogs` ドライバーを介して処理されます)。作成が完了したポリシーは、`ecsInstanceRole` にアタッチします。
------
#### [ AWS マネジメントコンソール ]
**JSON ポリシーエディタでポリシーを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。
初めて **[ポリシー]** を選択する場合には、**[管理ポリシーにようこそ]** ページが表示されます。**今すぐ始める** を選択します。
1. ページの上部で、**[ポリシーを作成]** を選択します。
1. **ポリシーエディタ** セクションで、**JSON** オプションを選択します。
1. 次の JSON ポリシードキュメントを入力します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": ["arn:aws:logs:*:*:*"]
}
]
}
```
1. [**次へ**] を選択します。
**注記**
いつでも **Visual** と **JSON** エディタオプションを切り替えることができます。ただし、**[ビジュアル]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、*IAM ユーザーガイド* の [ポリシーの再構成](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html#troubleshoot_viseditor-restructure) を参照してください。
1. **確認と作成** ページで、作成するポリシーの **ポリシー名** と **説明** (オプション) を入力します。**このポリシーで定義されているアクセス許可** を確認して、ポリシーによって付与されたアクセス許可を確認します。
1. **ポリシーを作成** をクリックして、新しいポリシーを保存します。
ポリシーを作成したら、そのポリシーをコンテナインスタンスロールにアタッチします。ポリシーをロールにアタッチする方法については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。
------
#### [ AWS CLI ]
1. `instance-cw-logs.json` というファイルを次の内容で作成します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": ["arn:aws:logs:*:*:*"]
}
]
}
```
1. JSON ポリシードキュメントファイルを使用して IAM ポリシーを作成するには、次の コマンドを使用します。
```
aws iam create-policy \
--policy-name cwlogspolicy \
--policy-document file://instance-cw-logs.json
```
1. 次のコマンドを使用して、作成した IAM ポリシーの ARN を取得します。*cwlogspolicy* は、作成したポリシーの名前に置き換えます。
```
aws iam list-policies --scope Local --query 'Policies[?PolicyName==`cwlogspolicy`].Arn'
```
1. ポリシー ARN を使用してコンテナインスタンスの IAM ロールにポリシーをアタッチするには、次のコマンドを使用します。
```
aws iam attach-role-policy \
--role-name ecsInstanceRole \
--policy-arn arn:aws:iam:111122223333:aws:policy/cwlogspolicy
```
------
# Amazon ECS Anywhere IAM ロール
オンプレミスサーバーまたは仮想マシン (VM) をクラスタ-に登録する場合、サーバーまたは VM は AWS APIと通信するために IAM ロールを必要とします。IAM ロールの作成は AWS アカウントごとに一度のみ行う必要があります。ただし、この IAM ロールは、クラスターに登録する各サーバーまたは VM に関連付ける必要があります。このロールは`ECSAnywhereRole`。このロールを手動で作成することもできます。または、Amazon ECS は、AWS マネジメントコンソール に外部インスタンスを登録するときに、ユーザーに代わってロールを作成することもできます。IAM コンソールの検索を使用して `ecsAnywhereRole` を検索すると、アカウントにすでにそのロールがあるかどうかを確認できます。詳細については、「*IAM ユーザーガイド*」の「[IAM コンソールの検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_search.html)」を参照してください。
AWSには、ECS Anywhere IAM ロールの作成時に使用できる 2 つの管理対象 IAM ポリシー、`AmazonSSMManagedInstanceCore`および`AmazonEC2ContainerServiceforEC2Role`ポリシーが用意されています。`AmazonEC2ContainerServiceforEC2Role`ポリシーには、必要以上に多くのアクセスを提供するアクセス許可が含まれています。したがって、特定のユースケースに応じて、必要なポリシーからのアクセス許可のみを追加するカスタムポリシーを作成することをお勧めします。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
タスク実行 IAM ロールは、ユーザーに代わって AWS API コールを実行するアクセス許可を Amazon ECS コンテナエージェントに付与します。タスク実行 IAM ロールを使用する場合は、タスク定義で指定する必要があります。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
次のいずれかの条件が適用される場合は、タスクの実行ロールが必要です。
+ コンテナログを CloudWatch Logs に送信するには、`awslogs`ログドライバーを使用します。
+ タスク定義では、Amazon ECR プライベートリポジトリでホストされるコンテナイメージを指定します。ただし、外部インスタンスに関連付けられている `ECSAnywhereRole` ロールに、Amazon ECR からイメージをプルするために必要なアクセス許可が含まれている場合は、タスク実行ロールにそれらを含める必要はありません。
## Amazon ECS Anywhere ロールを作成する
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. 以下のポリシーを持つ、`ssm-trust-policy.json` という名前のローカルファイルを作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": [
"ssm.amazonaws.com"
]},
"Action": "sts:AssumeRole"
}
}
```
------
1. 次の AWS CLI コマンドを使用して、ロールを作成し、信頼ポリシーをアタッチします。
```
aws iam create-role --role-name ecsAnywhereRole --assume-role-policy-document file://ssm-trust-policy.json
```
1. 次のコマンドを使用して AWS マネージドポリシーをアタッチします。
```
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
```
IAM のカスタム信頼ポリシーワークフローを使用してロールを作成することもできます。詳細については、「*IAM ユーザーガイド*」の「[カスタム信頼ポリシーを使用してロールを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
# Amazon ECS インフラストラクチャ IAM ロール
Amazon ECS インフラストラクチャ IAM ロールを使用すると、Amazon ECS はユーザーに代わってクラスター内のインフラストラクチャリソースを管理できます。次の場合に使用します。
+ Amazon EBS ボリュームを Fargate または EC2 起動タイプの Amazon ECS タスクにアタッチできます。インフラストラクチャロールにより、Amazon ECS はタスクの Amazon EBS ボリュームを管理できます。
`AmazonECSInfrastructureRolePolicyForVolumes` 管理ポリシーを使用できます。
+ Amazon ECS Service Connect サービス間のトラフィックを暗号化するには、Transport Layer Security (TLS) を使用します。
`AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity` 管理ポリシーを使用できます。
+ Amazon VPC Lattice ターゲットグループを作成する場合。
`AmazonECSInfrastructureRolePolicyForVpcLattice` 管理ポリシーを使用できます。
+ Amazon ECS クラスターで Amazon ECS マネージドインスタンスを使用します。インフラストラクチャロールにより、Amazon ECS はマネージドインスタンスのライフサイクルを管理できます。
`AmazonECSInfrastructureRolePolicyForManagedInstances` 管理ポリシーを使用できます。
+ Express Mode の使用を希望する場合。インフラストラクチャロールは、Amazon ECS が Express Mode サービスに必要なインフラストラクチャコンポーネント (ロードバランシング、セキュリティグループ、SSL 証明書、自動スケーリング設定など) のプロビジョニングと管理を行えるようにします。
`AmazonECSInfrastructureRoleforExpressGatewayServices` 管理ポリシーを使用できます。
Amazon ECS がこの役割を引き受け、ユーザーに代わってアクションを実行すると、イベントが AWS CloudTrail に表示されます。Amazon ECS がそのロールを使用してタスクにアタッチされた Amazon EBS ボリュームを管理する場合、CloudTrail ログ `roleSessionName` は `ECSTaskVolumesForEBS` となります。ロールを使用して Service Connect サービス間のトラフィックを暗号化する場合、CloudTrail ログ `roleSessionName` は `ECSServiceConnectForTLS` になります。ロールを使用して VPC Lattice のターゲットグループを作成する場合、CloudTrail ログ `roleSessionName` は `ECSNetworkingWithVPCLattice` になります。ロールを使用して Amazon ECS マネージドインスタンスを管理する場合、CloudTrail ログ `roleSessionName` は `ECSManagedInstancesForCompute` になります。この名前を使用して、**[ユーザー名]**でフィルタリングすることで CloudTrail コンソールでイベントを検索できます。
Amazon ECS では、ボリュームのアタッチメント、TLS、VPC Lattice、マネージドインスタンスに必要なアクセス許可を含むマネージドポリシーを提供しています。詳細については、「*AWS マネージドポリシーのリファレンスガイド*」の「[AmazonECSInfrastructureRolePolicyForVolumes](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForVolumes.html)」、「[AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity.html)」、「[AmazonECSInfrastructureRolePolicyForVpcLattice](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForVpcLattice.html)」、「[AmazonECSInfrastructureRolePolicyForManagedInstances](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForManagedInstances.html)」、および「[AmazonECSInfrastructureRoleforExpressGatewayServices](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRoleforExpressGatewayServices.html)」を参照してください。
## Amazon ECS インフラストラクチャロールを作成する
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. IAM ロールに使用する信頼ポリシーが含まれている `ecs-infrastructure-trust-policy.json` という名前のファイルを作成します。ファイルには次の内容が含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToECSForInfrastructureManagement",
"Effect": "Allow",
"Principal": {
"Service": "ecs.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用して、`ecsInfrastructureRole` という名前のロールを作成するには、次の AWS CLI コマンドを使用します。
```
aws iam create-role \
--role-name ecsInfrastructureRole \
--assume-role-policy-document file://ecs-infrastructure-trust-policy.json
```
1. ユースケースに応じて、マネージドポリシーを `ecsInfrastructureRole` ロールにアタッチします。
+ Amazon EBS ボリュームを Fargate または EC2 起動タイプの Amazon ECS タスクにアタッチするには、`AmazonECSInfrastructureRolePolicyForVolumes` マネージドポリシーをアタッチします。
+ Transport Layer Security (TLS) を使用して Amazon ECS Service Connect サービス間のトラフィックを暗号化するには、`AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity` マネージドポリシーをアタッチします。
+ Amazon VPC Lattice ターゲットグループを作成するには、`AmazonECSInfrastructureRolePolicyForVpcLattice` マネージドポリシーをアタッチします。
+ Amazon ECS クラスターで Amazon ECS マネージドインスタンスを使用するには、`AmazonECSInfrastructureRolePolicyForManagedInstances` マネージドポリシーをアタッチします。
```
aws iam attach-role-policy \
--role-name ecsInfrastructureRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
```
```
aws iam attach-role-policy \
--role-name ecsInfrastructureRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity
```
```
aws iam attach-role-policy \
--role-name ecsInfrastructureRole \
--policy-arn arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForManagedInstances
```
IAM コンソールの**[カスタム信頼ポリシー]**ワークフローを使用してロールを作成することもできます。詳細については、「*IAM ユーザーガイド*」の「[カスタム信頼ポリシーを使用してロールを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
**重要**
Amazon ECS がタスクにアタッチされた Amazon EBS ボリュームを管理するためにインフラストラクチャロールを使用している場合は、Amazon EBS ボリュームを使用するタスクを停止する前に、次の点を確認してください。
ロールが削除されていません。
ロールの信頼ポリシーは、Amazon ECS アクセス (`ecs.amazonaws.com`) を削除するように変更されていません。
マネージドポリシー `AmazonECSInfrastructureRolePolicyForVolumes` は削除されていません。ロールのアクセス許可を変更する必要がある場合は、ボリュームを削除するために、少なくとも `ec2:DetachVolume`、`ec2:DeleteVolume`、`ec2:DescribeVolumes` を残してください。
Amazon EBS ボリュームがアタッチされたタスクを停止する前にロールを削除または変更すると、タスクが `DEPROVISIONING` で停止し、関連する Amazon EBS ボリュームは削除されません。Amazon ECS は、必要なアクセス許可が回復するまで、定期的に自動的に再試行してタスクを停止し、ボリュームを削除します。[DescribeTasks API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) を使用して、タスクのボリュームアタッチ状態と関連するステータス理由を表示できます。
ファイルを作成したら、Amazon ECS にロールを渡すためのアクセス許可をユーザーに付与する必要があります。
## インフラストラクチャロールを Amazon ECS に渡すためのアクセス許可
ECS インフラストラクチャの IAM ロールを使用するには、そのロールを Amazon ECS に渡すためのユーザー権限を付与する必要があります。ユーザーに、次の `iam:PassRole` 権限をアタッチします。前に作成したインフラストラクチャロールの名前で *ecsInfrastructureRole* を置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "iam:PassRole",
"Effect": "Allow",
"Resource": ["arn:aws:iam::*:role/ecsInfrastructureRole"],
"Condition": {
"StringEquals": {"iam:PassedToService": "ecs.amazonaws.com"}
}
}
]
}
```
------
`iam:Passrole` およびユーザー権限の更新の詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[AWS サービスにロールを渡すアクセス許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」と「[IAM ユーザーのアクセス許可を変更する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html)」を参照してください。
# Amazon ECS マネージドインスタンスのインスタンスプロファイル
インスタンスプロファイルは、1 つの IAM ロールのみを保持し、Amazon ECS マネージドインスタンスがそのロールを安全に引き受けることを許可する IAM コンテナです。インスタンスプロファイルには、クラスターにインスタンスを登録し、ECS サービスと通信するために ECS エージェントが引き受けるインスタンスロールが含まれています。
**重要**
AWS マネージドインフラストラクチャポリシーで Amazon ECS マネージドインスタンスを使用している場合、インスタンスプロファイルには `ecsInstanceRole` という名前を付ける必要があります。インフラストラクチャロールにカスタムポリシーを使用している場合、インスタンスプロファイルに代替名を付けることができます。
## 信頼ポリシーでロールを作成する
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. IAM ロールに使用する信頼ポリシーが含まれている `ecsInstanceRole-trust-policy.json` という名前のファイルを作成します。ファイルには次の内容が含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用して、`ecsInstanceRole` という名前のロールを作成するには、次の AWS CLI コマンドを使用します。
```
aws iam create-role \
--role-name ecsInstanceRole \
--assume-role-policy-document file://ecsInstanceRole-trust-policy.json
```
1. AWS 管理 `AmazonECSInstanceRolePolicyForManagedInstances` ポリシー `ecsInstanceRole` をロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ecsInstanceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonECSInstanceRolePolicyForManagedInstances
```
**注記**
その代わりにアクセスの最小特権を適用し、独自のアクセス許可を指定する場合は、次のアクセス権限を追加して、Amazon ECS マネージドインスタンスのタスク関連の問題のトラブルシューティングに役立てることができます。
`ecs:StartTelemetrySession`
`ecs:PutSystemLogEvents`
IAM コンソールの**[カスタム信頼ポリシー]**ワークフローを使用してロールを作成することもできます。詳細については、「*IAM ユーザーガイド*」の「[カスタム信頼ポリシーを使用してロールを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
ファイルを作成したら、Amazon ECS にロールを渡すためのアクセス許可をユーザーに付与する必要があります。
## AWS CLI を使用してインスタンスプロファイルを作成する
ロールを作成したら、AWS CLI を使用してインスタンスプロファイルを作成します。
```
aws iam create-instance-profile --instance-profile-name ecsInstanceRole
```
次のように、インスタンスプロファイルにロールを追加します。
```
aws iam add-role-to-instance-profile \
--instance-profile-name ecsInstanceRole \
--role-name ecsInstanceRole
```
プロファイルが正常に作成されたことを確認します。
```
aws iam get-instance-profile --instance-profile-name ecsInstanceRole
```
# ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール
ロードバランサー用 Amazon ECS インフラストラクチャの IAM ロールは、Amazon ECS がユーザーに代わって、クラスター内のロードバランサーリソースを管理できるようにするためのものであり、次の場合に使用します。
+ Amazon ECS でブルー/グリーンデプロイを使用したい場合。インフラストラクチャロールにより、Amazon ECS でデプロイのロードバランサーリソースを管理できるようになります。
+ デプロイ操作中に、Amazon ECS でターゲットグループやリスナーなどのロードバランサーリソースを作成、変更、または削除する必要がある場合。
Amazon ECS がこの役割を引き受け、ユーザーに代わってアクションを実行すると、イベントが AWS CloudTrail に表示されます。Amazon ECS がこのロールを使用してブルー/グリーンデプロイのロードバランサーリソースを管理する場合、CloudTrail ログ `roleSessionName` は、`ECSNetworkingWithELB` または `ecs-service-scheduler` になります。この名前を使用して、**[ユーザー名]**でフィルタリングすることで CloudTrail コンソールでイベントを検索できます。
Amazon ECS は、ロードバランサー管理に必要となるアクセス許可を含む管理ポリシーを提供します。詳細については、「*AWS マネージドポリシーリファレンスガイド*」の「[AmazonECSInfrastructureRolePolicyForLoadBalancers](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRolePolicyForLoadBalancers.html)」を参照してください。
## ロードバランサー用の Amazon ECS インフラストラクチャロールの作成
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. IAM ロールに使用する信頼ポリシーが含まれている `ecs-infrastructure-trust-policy.json` という名前のファイルを作成します。ファイルには次の内容が含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToECSForInfrastructureManagement",
"Effect": "Allow",
"Principal": {
"Service": "ecs.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用して、`ecsInfrastructureRoleForLoadBalancers` という名前のロールを作成するには、次の AWS CLI コマンドを使用します。
```
aws iam create-role \
--role-name ecsInfrastructureRoleForLoadBalancers \
--assume-role-policy-document file://ecs-infrastructure-trust-policy.json
```
1. AWS 管理 `AmazonECSInfrastructureRolePolicyForLoadBalancers` ポリシー `ecsInfrastructureRoleForLoadBalancers` をロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ecsInfrastructureRoleForLoadBalancers \
--policy-arn arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers
```
IAM コンソールの**[カスタム信頼ポリシー]**ワークフローを使用してロールを作成することもできます。詳細については、「*IAM ユーザーガイド*」の「[カスタム信頼ポリシーを使用してロールを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
**重要**
Amazon ECS がブルー/グリーンデプロイのロードバランサーリソースを管理するためにインフラストラクチャロールを使用している場合は、ロールを削除または変更する前に以下の点を確認してください。
アクティブなデプロイの進行中に、ロールが削除されない。
ロールの信頼ポリシーは、Amazon ECS アクセス (`ecs.amazonaws.com`) を削除するように変更されていません。
アクティブなデプロイの進行中に、管理ポリシー `AmazonECSInfrastructureRolePolicyForLoadBalancers` が削除されない。
ブルー/グリーンデプロイ中にロールを削除または変更すると、デプロイが失敗し、サービスが不整合な状態になる可能性があります。
ファイルを作成したら、Amazon ECS にロールを渡すためのアクセス許可をユーザーに付与する必要があります。
## インフラストラクチャロールを Amazon ECS に渡すためのアクセス許可
ロードバランサー用の ECS インフラストラクチャの IAM ロールを使用するには、そのロールを Amazon ECS に渡すためのユーザー権限を付与する必要があります。ユーザーに、次の `iam:PassRole` 権限をアタッチします。*ecsInfrastructureRoleForLoadBalancers* を作成したインフラストラクチャロールの名前に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "iam:PassRole",
"Effect": "Allow",
"Resource": ["arn:aws:iam::*:role/ecsInfrastructureRoleForLoadBalancers"],
"Condition": {
"StringEquals": {"iam:PassedToService": "ecs.amazonaws.com"}
}
}
]
}
```
------
`iam:Passrole` およびユーザー権限の更新の詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[AWS サービスにロールを渡すアクセス許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」と「[IAM ユーザーのアクセス許可を変更する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html)」を参照してください。
# Amazon ECS CodeDeploy IAM ロール
Amazon ECS で CodeDeploy ブルー/グリーンデプロイタイプを使用するには、ユーザーの代わりに Amazon ECS サービスを更新するためのアクセス許可を事前に CodeDeploy サービスに付与しておく必要があります。これらのアクセス権限は、CodeDeploy IAM ロール (`ecsCodeDeployRole`) によって付与されます。
**注記**
ユーザーには CodeDeploy を使用するアクセス許可も必要です。これらの権限については、「[必要な IAM 許可](deployment-type-bluegreen.md#deployment-type-bluegreen-IAM)」で説明しています。
2 つの管理ポリシーが用意されています。詳細については、「*AWS マネージドポリシーリファレンスガイド*」で、次のいずれかを参照してください。
+ [AWSCodeDeployRoleForECS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeDeployRoleForECS.html) - 関連付けられたアクションを使用して、リソースを更新するためのアクセス許可を CodeDeploy に付与します。
+ [AWSCodeDeployRoleForECSLimited](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeDeployRoleForECSLimited.html) - より制限されたアクセス許可を CodeDeploy に付与します。
## CodeDeploy ロールの作成
以下の手順を使用して、Amazon ECS 用 CodeDeploy ロールを作成できます。
------
#### [ AWS マネジメントコンソール ]
**CodeDeploy のサービスロールを作成するには (IAM コンソール)**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールを作成]** を選択します。
1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。
1. **[サービスまたはユースケース]** で **[CodeDeploy]** を選択し、次に **[CodeDeploy - ECS]** ユースケースを選択します。
1. [**次へ**] を選択します。
1. 「**[アクセス許可ポリシーをアタッチする]**」セクションで、**[AWSCodeDeployRoleForECS]** ポリシーが選択されていることを確認します。
1. [**次へ**] を選択します。
1. **[ロール名]** に **[ECSodeDeployRole]** と入力します。
1. ロールを確認したら、**[ロールを作成]** を選択します。
------
#### [ AWS CLI ]
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. CodeDeploy IAM ロールに使用する信頼ポリシーを含む、`codedeploy-trust-policy.json` という名前のファイルを作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": ["codedeploy.amazonaws.com"]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用した `ecsCodedeployRole` という名前の IAM ロールを作成します。
```
aws iam create-role \
--role-name ecsCodedeployRole \
--assume-role-policy-document file://codedeploy-trust-policy.json
```
1. `AWSCodeDeployRoleForECS` または `AWSCodeDeployRoleForECSLimited` マネージドポリシー を `ecsTaskRole` ロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ecsCodedeployRole \
--policy-arn arn:aws:iam::aws:policy/AWSCodeDeployRoleForECS
```
```
aws iam attach-role-policy \
--role-name ecsCodedeployRole \
--policy-arn arn:aws:iam::aws:policy/AWSCodeDeployRoleForECSLimited
```
------
サービス内のタスクにタスク実行ロールが必要な場合は、各タスク実行ロールまたはタスクロールの上書きの `iam:PassRole` アクセス許可を、ポリシーとして CodeDeploy ロールに追加する必要があります。
### タスク実行ロールのアクセス許可
サービス内のタスクにタスク実行ロールが必要な場合は、各タスク実行ロールまたはタスクロールの上書きの `iam:PassRole` アクセス許可を、ポリシーとして CodeDeploy ロールに追加する必要があります。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」および「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。次に、そのポリシーを CodeDeploy ロールにアタッチします。
ポリシーの作成
------
#### [ AWS マネジメントコンソール ]
**JSON ポリシーエディタでポリシーを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。
初めて **[ポリシー]** を選択する場合には、**[管理ポリシーにようこそ]** ページが表示されます。**今すぐ始める** を選択します。
1. ページの上部で、**[ポリシーを作成]** を選択します。
1. **ポリシーエディタ** セクションで、**JSON** オプションを選択します。
1. 次の JSON ポリシードキュメントを入力します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": ["arn:aws:iam:::role/"]
}
]
}
```
1. [**次へ**] を選択します。
**注記**
いつでも **Visual** と **JSON** エディタオプションを切り替えることができます。ただし、**[ビジュアル]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、*IAM ユーザーガイド* の [ポリシーの再構成](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html#troubleshoot_viseditor-restructure) を参照してください。
1. **確認と作成** ページで、作成するポリシーの **ポリシー名** と **説明** (オプション) を入力します。**このポリシーで定義されているアクセス許可** を確認して、ポリシーによって付与されたアクセス許可を確認します。
1. **ポリシーを作成** をクリックして、新しいポリシーを保存します。
ポリシーを作成したら、そのポリシーを CodeDeploy ロールにアタッチします。ポリシーをロールにアタッチする方法については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。
------
#### [ AWS CLI ]
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. `blue-green-iam-passrole.json` というファイルを次の内容で作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": ["arn:aws:iam::*:role/code-deploy-role"],
"Condition": {
"StringEquals": {"iam:PassedToService": "ecs.amazonaws.com"}
}
}
]
}
```
------
1. JSON ポリシードキュメントファイルを使用して IAM ポリシーを作成するには、次の コマンドを使用します。
```
aws iam create-policy \
--policy-name cdTaskExecutionPolicy \
--policy-document file://blue-green-iam-passrole.json
```
1. 次のコマンドを使用して、作成した IAM ポリシーの ARN を取得します。
```
aws iam list-policies --scope Local --query 'Policies[?PolicyName==`cdTaskExecutionPolicy`].Arn'
```
1. 次のコマンドを使用して、ポリシーを CodeDeploy IAM ロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ecsCodedeployRole \
--policy-arn arn:aws:iam:111122223333:aws:policy/cdTaskExecutionPolicy
```
------
# Amazon ECS EventBridge IAM ロール
Amazon ECS でスケジュールされたタスクを EventBridge のルールとターゲットで送信するには、ユーザーの代わりに Amazon ECS タスクを実行するためのアクセス許可が EventBridge サービスに必要です。これらのアクセス許可は、EventBridge IAM ロール (`ecsEventsRole`) によって付与されます。
`AmazonEC2ContainerServiceEventsRole` のポリシーを次に示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["ecs:RunTask"],
"Resource": ["*"]
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": ["*"],
"Condition": {
"StringLike": {"iam:PassedToService": "ecs-tasks.amazonaws.com"}
}
},
{
"Effect": "Allow",
"Action": "ecs:TagResource",
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:CreateAction": ["RunTask"]
}
}
}
]
}
```
------
スケジュールされたタスクでタスク実行ロールの使用、タスクロール、またはタスクロール上書きが必要な場合、タスク実行ロール、タスクロール、またはタスクロール上書きごとに `iam:PassRole` アクセス許可を EventBridge IAM ロールに追加する必要があります。タスクの実行ロールの詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
**注記**
タスク実行ロールまたはタスクロール上書きの完全 ARN を指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/ecsTaskExecutionRole_or_TaskRole_name"
]
}
]
}
```
------
スケジュールされたタスクを設定するときに、AWS マネジメントコンソール が EventBridge ロールを作成するようにすることができます。詳細については、「[Amazon EventBridge スケジューラを使用して Amazon ECS タスクをスケジュールする](tasks-scheduled-eventbridge-scheduler.md)」を参照してください。
## Amazon ECS EventBridge ロールを作成する
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. IAM ロールに使用する信頼ポリシーが含まれている `eventbridge-trust-policy.json` という名前のファイルを作成します。ファイルには次の内容が含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 前のステップで作成した信頼ポリシーを使用して、`ecsEventsRole` という名前の IAM ロールを作成するには、次のコマンドを使用します。
```
aws iam create-role \
--role-name ecsEventsRole \
--assume-role-policy-document file://eventbridge-trust-policy.json
```
1. 次のコマンドを使用して、AWS マネージド `AmazonEC2ContainerServiceEventsRole` を `ecsEventsRole` ロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ecsEventsRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceEventsRole
```
IAM コンソールの**[カスタム信頼ポリシーワークフロー]** ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を使用してロールを作成することもできます。詳細については、「*IAM ユーザーガイド*」の「[カスタム信頼ポリシーを使用してロールを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
## `ecsEventsRole` ロールへのポリシーのアタッチ
以下の手順を使用して、タスク実行ロールのアクセス許可を EventBridge IAM ロールに追加できます。
------
#### [ AWS マネジメントコンソール ]
**JSON ポリシーエディタでポリシーを作成するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。
初めて **[ポリシー]** を選択する場合には、**[管理ポリシーにようこそ]** ページが表示されます。**今すぐ始める** を選択します。
1. ページの上部で、**[ポリシーを作成]** を選択します。
1. **ポリシーエディタ** セクションで、**JSON** オプションを選択します。
1. 次の JSON ポリシードキュメントを入力します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": ["arn:aws:iam::111122223333:role/"]
}
]
}
```
1. [**次へ**] を選択します。
**注記**
いつでも **Visual** と **JSON** エディタオプションを切り替えることができます。ただし、**[ビジュアル]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、*IAM ユーザーガイド* の [ポリシーの再構成](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html#troubleshoot_viseditor-restructure) を参照してください。
1. **確認と作成** ページで、作成するポリシーの **ポリシー名** と **説明** (オプション) を入力します。**このポリシーで定義されているアクセス許可** を確認して、ポリシーによって付与されたアクセス許可を確認します。
1. **ポリシーを作成** をクリックして、新しいポリシーを保存します。
ポリシーを作成したら、そのポリシーを EventBridge ロールにアタッチします。ポリシーをロールにアタッチする方法については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。
------
#### [ AWS CLI ]
すべての *[ユーザー入力]* は、お客様の情報で置き換えてください。
1. `ev-iam-passrole.json` というファイルを次の内容で作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/ecsTaskExecutionRole_or_TaskRole_name"
]
}
]
}
```
------
1. JSON ポリシードキュメントファイルを使用して IAM ポリシーを作成するには、次の AWS CLI コマンドを使用します。
```
aws iam create-policy \
--policy-name eventsTaskExecutionPolicy \
--policy-document file://ev-iam-passrole.json
```
1. 次のコマンドを使用して、作成した IAM ポリシーの ARN を取得します。
```
aws iam list-policies --scope Local --query 'Policies[?PolicyName==`eventsTaskExecutionPolicy`].Arn'
```
1. ポリシー ARN を使用して EventBridge の IAM ロールにポリシーをアタッチするには、次のコマンドを使用します。
```
aws iam attach-role-policy \
--role-name ecsEventsRole \
--policy-arn arn:aws:iam:111122223333:aws:policy/eventsTaskExecutionPolicy
```
------
# Amazon ECS コンソールに必要なアクセス許可
最小権限の付与のベストプラクティスに従い、`AmazonECS_FullAccess` 管理ポリシーを、独自のカスタムポリシーを作成するためのテンプレートとして使用できます。これにより、特定の要件に基づいて、管理ポリシーに権限を追加し、管理ポリシーから権限を追加、または権限を取り上げることができます。詳細については、「*AWS マネージドポリシーリファレンスガイド*」の「[AmazonECS\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECS_FullAccess.html)」を参照してください。
## IAM ロールを作成するための許可
以下のアクションでは、操作を完了するために追加のアクセス許可が必要です。
+ 外部インスタンスの登録 - 詳細は、[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md) を参照してください。
+ タスク定義の登録 - 詳細は、[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md) を参照してください。
+ タスクのスケジューリングに使用する EventBridge ルールの作成 - 詳細は、[Amazon ECS EventBridge IAM ロール](CWE_IAM_role.md) を参照してください。
Amazon ECS コンソールで使用する前に IAM でロールを作成することで、これらのアクセス許可を追加できます。ロールを作成しない場合、Amazon ECS コンソールがユーザーに代わってロールを作成します。
## 外部インスタンスをクラスターに登録するために必要なアクセス許可
外部インスタンスをクラスターに登録し、新しい外部インスタンス (`ecsExternalInstanceRole`) ロールを作成する場合は、追加のアクセス許可が必要です。
以下に示す追加のアクセス許可が必要です。
+ `iam` — プリンシパルが IAM ロールとそれにアタッチするポリシーを作成し、一覧表示できるようにします。
+ iam:AttachRolePolicy
+ iam:CreateRole
+ am:CreateInstanceProfile
+ iam:AddRoleToInstanceProfile
+ iam:ListInstanceProfilesForRole
+ iam:GetRole
+ `ssm` — プリンシパルが外部インスタンスを Systems Manager に登録できるようにします。
**注記**
既存の `ecsExternalInstanceRole` を選択するには、`iam:GetRole` および `iam:PassRole` のアクセス許可が必要です。
次のポリシーには必要なアクセス許可が含まれており、アクションは `ecsExternalInstanceRole` ロールに限定されます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:CreateInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:ListInstanceProfilesForRole",
"iam:GetRole"
],
"Resource": "arn:aws:iam::*:role/ecsExternalInstanceRole"
},
{
"Effect": "Allow",
"Action": ["iam:PassRole","ssm:CreateActivation"],
"Resource": "arn:aws:iam::*:role/ecsExternalInstanceRole"
}
]
}
```
------
## タスク定義を登録するために必要なアクセス許可
タスク定義を登録し、新しいタスク実行 (`ecsTaskExecutionRole`) ロールを作成する場合は、追加のアクセス許可が必要です。
以下に示す追加のアクセス許可が必要です。
+ `iam` — プリンシパルが IAM ロールとそれにアタッチするポリシーを作成し、一覧表示できるようにします。
+ iam:AttachRolePolicy
+ iam:CreateRole
+ iam:GetRole
**注記**
既存の `ecsTaskExecutionRole` を選択するには、`iam:GetRole` のアクセス許可が必要です。
次のポリシーには必要なアクセス許可が含まれており、アクションは `ecsTaskExecutionRole` ロールに限定されます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:GetRole"
],
"Resource": "arn:aws:iam::*:role/ecsTaskExecutionRole"
}
]
}
```
------
## Amazon Q Developer を使用して、コンソールで推奨事項を提供するために必要なアクセス許可
Amazon Q Developer が Amazon ECS で推奨事項を提供するには、IAM ユーザーまたはロールの正しい IAM アクセス許可を有効にする必要があります。`codewhisperer:GenerateRecommendations` アクセス許可を追加する必要があります。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Sid": "AmazonQDeveloperPermissions",
"Effect": "Allow",
"Action": ["codewhisperer:GenerateRecommendations"],
"Resource": "*"
}
]
}
```
------
Amazon ECS コンソールでインラインチャットを使用するには、IAM ユーザーまたはロールの正しい IAM アクセス許可を有効にする必要があります。`q:SendMessage` アクセス許可を追加する必要があります。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Sid": "AmazonQDeveloperInlineChatPermissions",
"Effect": "Allow",
"Action": ["q:SendMessage"],
"Resource": "*"
}
]
}
```
------
## スケジュールされたタスクの EventBridge ルールを作成するために必要なアクセス許可
タスクをスケジュールし、新しい CloudWatch Events ロール (`ecsEventsRole`) ロールを作成する場合は、追加のアクセス許可が必要です。
以下に示す追加のアクセス許可が必要です。
+ `iam` — プリンシパルが IAM ロールとそれにアタッチするポリシーを作成して一覧表示し、Amazon ECS がそのロールを他のサービスに渡してロールを引き継ぐことができるようにします。
**注記**
既存の `ecsEventsRole` を選択するには、`iam:GetRole` および `iam:PassRole` のアクセス許可が必要です。
次のポリシーには必要なアクセス許可が含まれており、アクションは `ecsEventsRole` ロールに限定されます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/ecsEventsRole"
}
]
}
```
------
## サービスデプロイを表示するために必要なアクセス許可
最小権限のベストプラクティスに従うと、コンソールでサービスデプロイを表示するには、アクセス許可を追加する必要があります。
次のアクションへのアクセスが必要です。
+ ListServiceDeployments
+ DescribeServiceDeployments
+ DescribeServiceRevisions
次のリソースへのアクセスが必要です。
+ サービス
+ サービスデプロイ
+ サービスリビジョン
次のポリシー例には必要なアクセス許可が含まれており、アクションは指定されたサービスに限定されます。
`account`、`cluster-name`、および `service-name` を独自の値に置き換えます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:ListServiceDeployments",
"ecs:DescribeServiceDeployments",
"ecs:DescribeServiceRevisions"
],
"Resource": [
"arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name",
"arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*",
"arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*"
]
}
]
}
```
------
## Amazon ECS ライフサイクルイベントを Container Insights で表示するには、以下のアクセス許可が必要です。
ライフサイクルイベントを表示するには、以下のアクセス権限が必要です。次のアクセス許可をインラインポリシーとしてロールに追加します。詳細については、「[IAM ポリシーの追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
+ events:DescribeRule
+ events:ListTargetsByRule
+ logs:DescribeLogGroups
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"events:DescribeRule",
"events:ListTargetsByRule",
"logs:DescribeLogGroups"
],
"Resource": "*"
}
]
}
```
------
## Amazon ECS ライフサイクルイベントを Container Insights で表示するために必要なアクセス許可
ライフサイクルイベントを設定するには、以下のアクセス権限が必要です。
+ events:PutRule
+ events:PutTargets
+ logs:CreateLogGroup
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:PutTargets",
"logs:CreateLogGroup"
],
"Resource": "*"
}
]
}
```
------
# CloudFormation を使用する Amazon ECS コンソールに必要なアクセス許可
AWS マネジメントコンソール を使用してリソースを作成する前に、適切な IAM アクセス許可を持っていることを確認する必要があります。最初に Amazon ECS コンソールのアクセス許可を設定する方法については、「[Amazon ECS コンソールに必要なアクセス許可](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/console-permissions.html)」を参照してください。
Amazon ECS コンソールは AWS CloudFormation を利用しているため、以下の場合には追加の IAM アクセス許可が必要になります。
+ クラスターの作成
+ サービスの作成
+ キャパシティープロバイダーの作成
追加のアクセス許可のポリシーを作成して、コンソールへのアクセスに使用する IAM ロールにアタッチできます。詳細については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start)」を参照してください。
## クラスターを作成するために必要なアクセス許可
コンソールでクラスターを作成するときには、CloudFormation スタックを管理するための追加のアクセス許可が必要です。
以下に示す追加のアクセス許可が必要です。
+ `cloudformation` — プリンシパルの作成と管理を許可する CloudFormation スタック。これは、AWS マネジメントコンソール を使用して Amazon ECS クラスターを作成し、それらのクラスターのその後の管理に必要です。
+ `ssm` – CloudFormation が最新の Amazon ECS 最適化 AMI を参照できるようにします。これは、AWS マネジメントコンソール を使用して Amazon ECS クラスターを作成するときに必要です。
次のポリシーには必要な CloudFormation アクセス許可が含まれており、アクションは Amazon ECS コンソールで作成されたリソースに限定されます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:DescribeStack*",
"cloudformation:UpdateStack"
],
"Resource": [
"arn:*:cloudformation:*:*:stack/Infra-ECS-Cluster-*"
]
},
{
"Effect": "Allow",
"Action": "ssm:GetParameters",
"Resource": [
"arn:aws:ssm:*:*:parameter/aws/service/ecs/optimized-ami/amazon-linux-2*/*",
"arn:aws:ssm:*:*:parameter/aws/service/ecs/optimized-ami/amazon-linux-2023*/*"
]
}
]
}
```
------
Amazon ECS コンテナインスタンスロール (`ecsInstanceRole`) をまだ作成していない状態で Amazon EC2 インスタンスを使用するクラスターを作成する場合は、コンソールがユーザーに代わってロールを作成します。
さらに、Auto Scaling グループを使用する場合は、クラスターの自動スケーリング機能を使用する際にコンソールが Auto Scaling グループにタグを追加できるようにするための追加のアクセス許可が必要です。
以下に示す追加のアクセス許可が必要です。
+ `autoscaling` — コンソールが Amazon EC2 Auto Scaling グループにタグ付けできるようにします。これは、クラスターのオートスケーリング機能を使用する場合、Amazon EC2 Auto Scaling グループを管理する場合に必要です。このタグは、ECS によって管理され、コンソールで作成されたことを示すためにコンソールによって自動的にグループに追加されます。
+ `iam` — プリンシパルに IAM ロールとアタッチされたポリシーの一覧表示を許可します。プリンシパルは、Amazon EC2 インスタンスで利用できるインスタンスプロファイルを一覧表示することもできます。
次のポリシーには必要な IAM アクセス許可が含まれており、アクションは `ecsInstanceRole` ロールに限定されます。
自動スケーリング許可は制限されません。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:CreateInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:ListInstanceProfilesForRole",
"iam:GetRole"
],
"Resource": "arn:aws:iam::*:role/ecsInstanceRole"
},
{
"Effect": "Allow",
"Action": "autoscaling:CreateOrUpdateTags",
"Resource": "*"
}
]
}
```
------
## サービスを作成するために必要なアクセス許可
コンソールでサービスを作成するときには、CloudFormation スタックを管理するための追加のアクセス許可が必要です。以下に示す追加のアクセス許可が必要です。
+ `cloudformation` — プリンシパルの作成と管理を許可する CloudFormation スタック。これは、AWS マネジメントコンソール を使用して Amazon ECS サービスを作成する際に、またその後それらのサービスを管理する際に必要です。
次のポリシーには必要なアクセス許可が含まれており、アクションは Amazon ECS コンソールで作成されたリソースに限定されます。
------
#### [ JSON ]
****
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:DescribeStack*",
"cloudformation:UpdateStack"
],
"Resource": [
"arn:*:cloudformation:*:*:stack/ECS-Console-V2-Service-*"
]
}
]
}
```
------
# Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可
Amazon ECS ブルー/グリーンデプロイでデプロイライフサイクルフックとして Lambda 関数を使用する場合は、特定のアクセス許可を持つ IAM ロールを作成する必要があります。このロールを使用することで、Amazon ECS はデプロイライフサイクルのさまざまな段階で Lambda 関数を呼び出すことができます。
以下に示す追加のアクセス許可が必要です。
+ `lambda:InvokeFunction` – Amazon ECS がデプロイプロセス中にライフサイクルフックとして設定された Lambda 関数を呼び出すことができるようになります。
信頼ポリシーでは、サービスが次のロールを引き受けられるように許可する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ecs.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
# Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可
Service Auto Scalingは、Amazon ECS、Amazon CloudWatch、およびアプリケーション Auto Scaling API の組み合わせによって可能になります。サービスは Amazon ECS で作成および更新され、アラームは CloudWatch で作成され、スケーリングポリシーは Application Auto Scaling で作成されます。
サービスの作成および更新のための標準の IAM アクセス許可に加えて、Service Auto Scaling 設定の操作には次のアクセス許可が必要です。
+ `application-autoscaling:*`
+ `ecs:DescribeServices`
+ `ecs:UpdateService`
+ `cloudwatch:DescribeAlarms`
+ `cloudwatch:PutMetricAlarm`
+ `cloudwatch:DeleteAlarms`
+ `cloudwatch:DescribeAlarmHistory`
+ `cloudwatch:DescribeAlarmsForMetric`
+ `cloudwatch:GetMetricStatistics`
+ `cloudwatch:ListMetrics`
+ `cloudwatch:DisableAlarmActions`
+ `cloudwatch:EnableAlarmActions`
+ `iam:CreateServiceLinkedRole`
+ `sns:CreateTopic`
+ `sns:Subscribe`
+ `sns:Get*`
+ `sns:List*`
Application Auto Scaling サービスには、Amazon ECS サービスおよび CloudWatch アラームを記述するアクセス許可が必要です。また、ユーザーの代わりにサービスの必要タスク数を変更するアクセス許可も必要です。`sns:` 権限は、しきい値を超えたときに CloudWatch が Amazon SNS トピックに送信する通知を対象とするものです。Amazon ECS サービスの自動スケーリングを使用にする場合、サービスにリンクされたロールが `AWSServiceRoleForApplicationAutoScaling_ECSService` という名前で作成されます。このサービスにリンクされたロールでは、ポリシーのアラームを記述し、サービスの現在実行中のタスクの数をモニタリングし、サービスの必要なタスクの数を変更するアクセス許可を Application Auto Scaling に付与します。Application Auto Scaling の元のマネージド型の Amazon ECS ロールは `ecsAutoscaleRole` ですが、これは不要になりました。サービスにリンクされたロールは、Application Auto Scaling のデフォルトロールです。詳細については、「Application Auto Scaling ユーザーガイド」の「[Application Auto Scaling 用のサービスリンクロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。
CloudWatch メトリクスが Amazon ECS で使用可能になる前に Amazon ECS コンテナインスタンスロールを作成した場合は、このアクセス `ecs:StartTelemetrySession` 許可の追加が必要になることがあります。詳細については、「[考慮事項](cloudwatch-metrics.md#enable_cloudwatch)」を参照してください。
# リソース作成時にタグ付けするための許可を付与する
次の作成時のタグ付けの Amazon ECS API アクションを使用すると、リソースの作成時にタグを指定できます。リソース作成アクションでタグが指定されている場合、AWS は追加の認可を実行して、タグを作成するための正しい許可が割り当てられていることを検証します。
+ `CreateCapacityProvider`
+ `CreateCluster`
+ `CreateService`
+ `CreateTaskSet`
+ `RegisterContainerInstance`
+ `RegisterTaskDefinition`
+ `RunTask`
+ `StartTask`
リソースタグを使用して、属性ベースの制御 (ABAC) を実装できます。詳細については、「[リソースタグを使用して Amazon ECS リソースへのアクセスを制御する](control-access-with-tags.md)」および「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。
作成時のタグ付けを許可するには、ポリシーを作成または変更して、`ecs:CreateCluster` や `ecs:RunTask` などのリソースを作成するアクションと `ecs:TagResource` アクションを使用するための両方の許可を含めます。
次の例は、ユーザーがクラスターを作成し、クラスター作成時にタグを追加できるポリシーを示しています。ユーザーには既存のリソースへのタグ付けが許可されません (`ecs:TagResource` アクションを直接呼び出すことはできません)。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ecs:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:CreateAction": [
"CreateCluster",
"CreateCapacityProvider",
"CreateService",
"CreateTaskSet",
"RegisterContainerInstance",
"RegisterTaskDefinition",
"RunTask",
"StartTask"
]
}
}
}
]
}
```
`ecs:TagResource` アクションはタグがリソース作成アクション時に適用された場合のみ評価されます。したがって、リクエストでタグが指定されていない場合、リソースを作成するアクセス許可を持っているユーザー (タグ付け条件がないと仮定) には`ecs:TagResource` アクションを実行するアクセス許可は必要ありません。ただし、ユーザーがタグを使用してリソースを作成しようとした場合、ユーザーが `ecs:TagResource` アクションを使用するアクセス許可を持っていない場合はリクエストに失敗します。
## 特定のタグへの Amazon ECS アクセス制御
IAM ポリシーの `Condition` 要素で追加の条件を使用して、リソースに適用できるタグキーとタグ値を制御できます。
次の条件キーは前のセクションの例で使用できます。
+ `aws:RequestTag`: 特定のタグキーまたはタグキーと値がリクエストに存在している必要があることを指定する場合に使用します。リクエストでは他のタグも指定できます。
+ `StringEquals` 条件演算子とともに使用して、特定のタグキーと値の組み合わせを適用します。例えば、タグ `cost-center`=`cc123`: を適用します。
```
"StringEquals": { "aws:RequestTag/cost-center": "cc123" }
```
+ `StringLike` 条件演算子とともに使用して、リクエストで特定のタグキーを適用します。例えば、タグキー `purpose` を適用します。
```
"StringLike": { "aws:RequestTag/purpose": "*" }
```
+ `aws:TagKeys`: リクエストで使用されるタグキーを適用する場合に使用します。
+ リクエストにタグが指定されている場合は`ForAllValues` 修飾子を使用して特定のタグキーのみを適用します (リクエストにタグが指定されている場合、特定のタグキーのみが許可されます。他のタグは許可されません)。例えば、タグキー `environment` または `cost-center` が適用されます:
```
"ForAllValues:StringEquals": { "aws:TagKeys": ["environment","cost-center"] }
```
+ `ForAnyValue` 修飾子とともに使用して、指定されたタグキーの少なくとも 1 つがリクエストに存在することを要求します。例えば、タグキー `environment` または `webserver` のうち少なくとも 1 つがリクエストに存在している必要があります。
```
"ForAnyValue:StringEquals": { "aws:TagKeys": ["environment","webserver"] }
```
これらの条件キーは、`ecs:TagResource` アクションだけでなく、タグ付けをサポートするリソース作成アクションにも適用できます。Amazon ECS API アクションがタグ付けをサポートしているかどうかについては、「[Amazon ECS のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html)」を参照してください。
リソースの作成時にタグを指定するようにユーザーに強制するにはリソース作成アクションで `aws:RequestTag` 修飾子とともに `aws:TagKeys` 条件キーまたは `ForAnyValue` 条件キーを使用する必要があります。ユーザーがリソース作成アクションのタグを指定しない場合、`ecs:TagResource` アクションは評価されません。
条件においては条件キーでは大文字と小文字が区別されず、条件値では大文字と小文字が区別されます。したがって、タグキーの大文字と小文字を区別するには条件の値としてタグキーが指定される `aws:TagKeys` 条件キーを使用します。
複数値条件の詳細については、「*IAM ユーザーガイド*」の「[複数のコンテキストキーまたは値による条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-logic-multiple-context-keys-or-values.html)」を参照してください。
# リソースタグを使用して Amazon ECS リソースへのアクセスを制御する
Amazon ECS リソースを使用するための許可をユーザーに付与する IAM ポリシーを作成する場合、ポリシーの `Condition` 要素にタグ情報を含めることで、タグに基づいてアクセスをコントロールできます。これは属性ベースのアクセス制御 (ABAC) と呼ばれます。ABAC を使用すると、ユーザーが変更、使用、または削除できるリソースをより適切に制御できます。詳細については[AWS の ABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)を参照してください。
例えば、ユーザーによるクラスターの削除を許可するが、クラスターにタグ `environment=production` がある場合はそのアクションを拒否するポリシーを作成できます。これを行うには`aws:ResourceTag` 条件キーを使用し、リソースにアタッチされているタグに基づいてリソースへのアクセスを許可または拒否します。
```
"StringEquals": { "aws:ResourceTag/environment": "production" }
```
Amazon ECS API アクションが `aws:ResourceTag` 条件キーを使用したアクセスの制御をサポートしているかどうかについては、「[Amazon ECS のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html)」を参照してください。`Describe` アクションはリソースレベルのアクセス権限をサポートしないため、条件のない別のステートメントでそれらのアクセス権限を指定する必要があることに注意してください。
IAM ポリシーの例は [Amazon ECS ポリシーの例](iam-policies-ecs-console.md) を参照してください。
タグに基づいてリソースへのユーザーのアクセスを許可または拒否する場合はユーザーが同じリソースに対してそれらのタグを追加または削除することを明示的に拒否することを検討する必要があります。そうしないと、ユーザーはそのリソースのタグを変更することで、制限を回避してリソースにアクセスできてしまいます。
# Amazon ECS ポリシーの例
IAM ポリシーを使用して、Amazon ECS コンソールで特定のリソースを表示、および操作するための許可をユーザーに付与することができます。上記のセクションのサンプルポリシーを使用することはできますが、これらは AWS CLI または AWS SDK で作成されたリクエスト向けに設計されています。
## 例: タグに基づいてユーザーが Amazon ECS クラスターを削除するのを許可する
次のポリシーは、タグに「Purpose/Testing」のキー/値のペアがある場合、ユーザーがクラスターを削除することを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ecs:DeleteCluster"
],
"Effect": "Allow",
"Resource": "arn:aws:ecs:us-east-1:111122223333:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Purpose": "Testing"
}
}
}
]
}
```
------
# Amazon Elastic Container Service のアイデンティティとアクセスのトラブルシューティング
次の情報は、Amazon ECS と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [Amazon ECS でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [自分の AWS アカウント 以外のユーザーに Amazon ECS リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
+ [Amazon ECS マネージドインスタンスのインスタンスプロファイルに問題がある](#security_iam_instance-profile)
+ [その他のトラブルシューティングリソース](#security_iam_troubleshoot-additional-errors)
## Amazon ECS でアクションを実行する権限がない
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して、ある `my-example-widget` リソースに関する詳細情報を表示しようとしたことを想定して、その際に必要な `ecs:GetWidget` アクセス許可を持っていない場合に発生するものです。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: ecs:GetWidget on resource: my-example-widget
```
この場合、`ecs:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスを許可するように、`mateojackson` ユーザーのポリシーを更新する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon ECS にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールやサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon ECS でアクションを実行しようする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## 自分の AWS アカウント 以外のユーザーに Amazon ECS リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Amazon ECS がこれらの機能をサポートしているかどうかについては、「[IAM を使用するAmazon Elastic Container Service](security_iam_service-with-iam.md)」を参照してください。
+ 所有している AWS アカウント 全体のリソースへのアクセス権を提供する方法については、*IAM ユーザーガイド* の [所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) を参照してください。
+ サードパーティの AWS アカウント にリソースへのアクセス権を提供する方法については、「*IAM ユーザーガイド*」の「[サードパーティが所有する AWS アカウント へのアクセス権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## Amazon ECS マネージドインスタンスのインスタンスプロファイルに問題がある
Amazon ECS が提供する `AmazonECSInfrastructureRolePolicyForManagedInstances` マネージドポリシーを使用する場合、インスタンスプロファイルにはプレフィックスとして `ecsInstanceRole` が必要です。これは、マネージドポリシーにはこのプレフィックスを持つロールを渡す権限のみが付与されているためです。
## その他のトラブルシューティングリソース
次のページに、エラーコードに関する情報が記載されています。
+ [Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md)
+ [Amazon ECS のサービスイベントメッセージを表示する](service-event-messages.md)
# Amazon ECS の IAM ベストプラクティス
AWS Identity and Access Management (IAM) を使用すると、認証と認可を目的としたルールベースのポリシーを通じて、AWS のサービスとリソースへのアクセスの管理と制御を行うことができます。具体的には、このサービスを通じてユーザー、グループ、またはロールに適用されるポリシーを使用して、AWS リソースへのアクセスを制御します。この 3 つのうち、ユーザーはリソースにアクセスできるアカウントです。また、IAM ロールは、認証された ID が引き受けることができる一連のアクセス許可であり、IAM 外の特定の ID には関連付けられていません。詳細については、「[Amazon ECS overview of access management: Permissions and policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html)」を参照してください。
## 最小権限アクセスのポリシーに従う
ユーザーが所定の仕事を遂行できるようにポリシーの範囲を設定してください。たとえば、開発者が定期的にタスクを停止する必要がある場合、その特定のアクションのみを許可するポリシーを作成します。次の例では、特定の Amazon リソースネーム (ARN) を持つクラスター上の 特定の `task_family` に属するタスクを停止させることができます。リソースレベルのアクセス許可を使用する別の例として、条件で ARN を参照することが挙げられます。リソースレベルのアクセス許可を使用して、アクションを適用するリソースを指定できます。詳細については、「[Amazon ECS のポリシーリソース](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_service-with-iam.html#security_iam_service-with-iam-id-based-policies-resources)」を参照してください。
## クラスターリソースを管理上の境界として使用する
ポリシーの範囲が狭すぎると、ロールが急増し、管理オーバーヘッドが増える可能性があります。特定のタスクやサービスのみを対象とするロールを作成するのではなく、クラスターを対象とするロールを作成し、そのクラスターを主要な管理上の境界として使用してください。
## 自動パイプラインを作成して API からエンドユーザーを隔離する
アプリケーションを自動的にパッケージ化して Amazon ECS クラスターにデプロイするパイプラインを作成することで、ユーザーが使用できるアクションを制限できます。これにより、タスクを作成、更新、削除するジョブをパイプラインに効果的に委任することができます。詳細については、「*AWS CodePipeline ユーザーガイド*」の「[チュートリアル: CodePipeline を使用した Amazon ECS 標準デプロイ](https://docs.aws.amazon.com/codepipeline/latest/userguide/ecs-cd-pipeline.html)」を参照してください。
## ポリシー条件を使用してセキュリティをより一層強化する
セキュリティを強化する必要がある場合は、ポリシーに条件を追加します。これは、権限のある操作を実行する場合や、特定のリソースに対して実行できるアクションを制限する必要がある場合に役立ちます。以下は、クラスターを削除する際に多要素認可を必要とするポリシーの例です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:DeleteCluster"
],
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
},
"Resource": ["*"]
}
]
}
```
------
サービスに適用されたタグは、そのサービスに含まれるすべてのタスクに反映されます。したがって、特定のタグを使用して Amazon ECS リソースを対象とするロールを作成できます。次のポリシーでは、タグキーが `Department` でタグ値が `Accounting` であるすべてのタスクを IAM プリンシパルが開始および停止します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:StartTask",
"ecs:StopTask",
"ecs:RunTask"
],
"Resource": "arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster",
"Condition": {
"StringEquals": {"ecs:ResourceTag/Department": "Accounting"}
}
}
]
}
```
------
## API へのアクセスを定期的に監査する
ユーザーがロールを変更する場合があります。ロールを変更した後、以前に付与されていたアクセス許可が適用されなくなる場合があります。どのユーザーが Amazon ECS API にアクセスでき、そのアクセスが引き続き保証されているかどうかを必ず監査してください。ユーザーが組織を離れると自動的にアクセス権を取り消すユーザーライフサイクル管理ソリューションと IAM を統合することを検討してください。詳細については、「AWS Identity and Access Management ユーザーガイド」の「[AWS セキュリティ監査のガイドライン](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-audit-guide.html)」を参照してください。**
# Amazon Elastic Container Service でのログとモニタリング
モニタリングは、Amazon Elastic Container Service および AWS ソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。マルチポイント障害が発生した場合は、その障害をより簡単にデバッグできるように、AWS ソリューションのすべての部分からモニタリングデータを収集する必要があります。AWS には、Amazon ECS リソースをモニタリングし、潜在的なインシデントに対応するための複数のツールが用意されています。
**Amazon CloudWatch アラーム**
指定した期間にわたって単一のメトリクスを監視し、複数の期間にわたり特定のしきい値に関連するメトリクス値に基づいて 1 つ以上のアクションを実行します。アクションは、Amazon Simple Notification Service (Amazon SNS) のトピックまたは Amazon EC2 Auto Scaling のポリシーに送信される通知です。CloudWatch アラームは、特定の状態にあるという理由だけでアクションを呼び出すことはありません。状態が変更され、指定された期間維持されている必要があります。詳細については、「[CloudWatch を使用して Amazon ECS をモニタリングする](cloudwatch-metrics.md)」を参照してください。
Fargate を使用するタスクがあるサービスでは、CloudWatch アラームを使用して、CPU やメモリの使用率などの CloudWatch メトリクスに基づいてサービス内のタスクをスケールインおよびスケールアウトできます。詳細については、「[Amazon ECS サービスを自動的にスケールする](service-auto-scaling.md)」を参照してください。
EC2 を使用するタスクまたはサービスがあるクラスターでは、CloudWatch アラームを使用して、クラスターのメモリ使用率などの CloudWatch メトリクスに基づいてコンテナインスタンスをスケールインおよびスケールアウトできます。
**Amazon CloudWatch Logs**
Amazon ECS タスク定義で `awslogs` ログドライバーを指定することで、Amazon ECS タスクのコンテナからのログファイルをモニタリング、保存、およびアクセスできます。詳細については、「[awslogs ログドライバーを使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html)」を参照してください。
Amazon ECS コンテナインスタンスからのオペレーティングシステムおよび Amazon ECS コンテナエージェントのログファイルをモニタリング、保存、アクセスすることもできます。このログへのアクセス方法は、EC2 を使用するコンテナの場合に使うことができます。
**Amazon CloudWatch Events**
イベントを一致させ、イベントを 1 つ以上のターゲット関数やストリームにルーティングして、変更を加えたり、状態情報を取得したり、修正アクションを実行したりします。詳細については、このガイドの「[EventBridge を使用して Amazon ECS エラーへの対応を自動化する](cloudwatch_event_stream.md)」および「*Amazon EventBridge ユーザーガイド*」の「[EventBridge は、Amazon CloudWatch Events の進化形です](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cwe-now-eb.html)」を参照してください。
**AWS CloudTrail ログ**
CloudTrail では、Amazon ECS のユーザー、ロール、または AWS のサービスによって実行されたアクションの記録を確認できます。CloudTrail で収集された情報を使用して、Amazon ECS に対するリクエスト、リクエスト元の IP アドレス、リクエスト者、リクエスト日時などの詳細を確認できます。詳細については、「[AWS CloudTrail を使用して Amazon ECS API コールをログに記録する](logging-using-cloudtrail.md)」を参照してください。
**AWS Trusted Advisor**
Trusted Advisor は、AWS の数十万のお客様にサービスを提供することにより得られた、運用実績から学んだベストプラクティスを活用しています。Trusted Advisor はお客様の AWS 環境を検査し、システムの可用性とパフォーマンスを向上させたりセキュリティギャップを埋めたりする機会がある場合には、推奨事項を作成します。すべての AWS のお客様は、Trusted Advisor の 5 つのチェックにアクセスできます。ビジネスまたはエンタープライズサポートプランをご利用のお客様は、すべての Trusted Advisor チェックを表示できます。
詳細については、*サポート ユーザーガイド*の [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#trusted-advisor) をご参照ください。
**AWS Compute Optimizer**
AWS Compute Optimizer は、AWS リソースの設定と使用率のメトリクスを分析するサービスです。Compute Optimizer は、リソースが最適かどうかを報告し、最適化に関するレコメンデーションを生成してコストを削減およびワークロードのパフォーマンスを改善します。
詳細については、「[Amazon ECS に関する AWS Compute Optimizer 推奨事項](ecs-recommendations.md)」を参照してください。
Amazon ECS のモニタリングでもう 1 つ重要な点は、CloudWatch のアラームの対象外の項目を手動でモニタリングすることです。Trusted Advisor、CloudWatch、その他の AWS コンソールのダッシュボードには、AWS 環境の状態が一目でわかるように表示されます。コンテナインスタンスおよびタスクのコンテナのログファイルも確認することをお勧めします。
# Amazon Elastic Container Service でのコンプライアンス検証
AWS のサービス が特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「[コンプライアンスプログラムによる AWS のサービス対象範囲内のサービス ](https://aws.amazon.com/compliance/services-in-scope/)」を参照して、関心のあるコンプライアンスプログラムを選択してください。一般的な情報については、[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) を参照してください。
AWS Artifact を使用して、サードパーティの監査レポートをダウンロードできます。詳細については、「[AWS Artifact でレポートをダウンロードする](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」「」を参照してください。
AWS のサービスを使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目的、適用可能な法律および規制によって決定されます。AWS のサービス を使用する際のコンプライアンス責任の詳細については、「[AWS セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# Amazon ECS のセキュリティとコンプライアンスのベストプラクティス
Amazon ECS を使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目標、および該当する法規制によって決定されます。
## 決済カード業界のデータセキュリティ基準 (PCI DSS)
PCI DSS を順守する際には、環境内のカード所有者データ (CHD) の流れ全体を理解することが重要です。CHD フローは PCI DSS の適用性を決定し、カード会員データ環境 (CDE) の境界と構成要素を定義し、PCI DSS 評価の範囲を定義します。PCI DSS の範囲を正確に決定することは、セキュリティ体制を定義し、最終的に評価を成功させるための鍵となります。範囲の完全性を保証し、範囲からの変更や逸脱を検出する範囲決定手順は、お客様で用意する必要があります。
コンテナ化されたアプリケーションは一時的な性質を持つため、構成の監査がさらに複雑になります。そのため、コンテナのライフサイクルの全段階でコンプライアンス要件に対応できるよう、お客様はコンテナのすべての設定パラメータを常に把握しておく必要があります。
Amazon ECS での PCI DSS コンプライアンスの達成方法の詳細については、次のホワイトペーパーを参照してください。
+ [Amazon ECS での PCI DSS コンプライアンスに向けたアーキテクチャ構築]( https://d1.awsstatic.com/whitepapers/compliance/architecting-on-amazon-ecs-for-pci-dss-compliance.pdf)
## HIPAA (米国の医療保険の相互運用性と説明責任に関する法令)
Amazon ECS で保護対象医療情報 (PHI) を処理するワークロードを使用する場合、追加の設定は不要です。Amazon ECS は、Amazon EC2 でのコンテナの起動を調整するオーケストレーションサービスとして機能します。オーケストレーション対象のワークロード内のデータに対して動作したり、データに基づいて動作したりすることはありません。HIPAA 規制および AWS ビジネスアソシエイト補遺に従い、Amazon ECS で起動されたコンテナが PHI にアクセスする場合は、転送中も保存中も暗号化する必要があります。
AWS ストレージオプションごとに Amazon S3、Amazon EBS、AWS KMS など、保存時の暗号化のためのさまざまなメカニズムを利用できます。オーバーレイネットワーク (VNS3 や Weave Net など) をデプロイして、コンテナ間で転送される PHI を完全に暗号化したり、あるいは暗号化の冗長レイヤーを提供することもできます。完全なログを使用し、すべてのコンテナログが Amazon CloudWatch に送信されるようにしてください。インフラストラクチャセキュリティのベストプラクティスの使用については、「*セキュリティの柱 – AWS Well-Architected フレームワーク*」の「[インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
## AWS Security Hub CSPM
AWS Security Hub CSPM を使用します。この AWS のサービス は、AWS 内のセキュリティ状態の包括的なビューを提供します。Security Hub CSPM では、セキュリティコントロールを使用して AWS リソースを評価し、セキュリティ業界標準とベストプラクティスに対するコンプライアンスをチェックします。サポートされているサービスとコントロールの一覧については、「[Security Hub CSPM のコントロールリファレンス](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html)」を参照してください。
## Amazon ECS Runtime Monitoring を使用した Amazon GuardDuty
Amazon GuardDuty は、AWS 環境内のアカウント、コンテナ、ワークロード、データを保護する脅威検知サービスです。GuardDuty は、機械学習（ML）モデル、異常および脅威検出機能を使用して、さまざまなログソースとランタイムアクティビティを継続的に監視し、環境内の潜在的なセキュリティリスクと悪意のあるアクティビティを特定して優先順位を付けます。
GuardDuty のランタイムモニタリングを使用して、悪意のある、または不正な動作を特定します。ランタイムモニタリングは、AWS ログとネットワークアクティビティを継続的に監視して悪意のある動作や不正な動作を特定することで、Fargate および EC2 で実行されているワークロードを保護します。ランタイムモニタリングは、軽量でフルマネージド型の GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、ネットワーク接続などのホスト上動作を分析します。これは、Amazon EC2 インスタンスおよびコンテナワークロードでの権限の昇格、流出した認証情報の使用、悪意のある IP アドレスやドメインとの通信、マルウェアの存在などの問題に対応しています。詳細については、「*GuardDuty ユーザーガイド*」の「[GuardDuty ランタイムモニタリング](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)」を参照してください。
## コンプライアンスに関する推奨事項
関連するコンプライアンスプログラムを効果的に運用するには、早めに社内のコンプライアンスプログラムの所有者に働きかけることで、AWS 責任共有モデルを利用してコンプライアンス管理責任の所在を明確化することをお勧めします。詳細については、「[Amazon ECS の AWS 責任共有モデル。](security-shared-model.md)」を参照してください。
# AWS Fargate 連邦情報処理標準 (FIPS-140)
連邦情報処理規格 (Federal Information Processing Standards/FIPS–140) は、機密情報を保護する暗号モジュールのセキュリティ要件を規定する、米国およびカナダ政府の基準です。FIPS-140 は、転送中のデータと保管中のデータの暗号化に使用できる、一連の検証済みの暗号化関数を定めています。
FIPS-140 コンプライアンスをオンにすると、FIPS-140 に準拠した態様で Fargate でワークロードを実行できます。FIPS-140 コンプライアンスの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
## AWS Fargate FIPS-140 に関する考慮事項
Fargate で FIPS-140 コンプライアンスを使用する場合は、次の点を考慮してください。
+ FIPS-140 コンプライアンスは、AWS GovCloud (US) リージョンでのみ利用できます。
+ Fargate が FIPS-140 バージョン 140.3 をサポート
+ FIPS-140 コンプライアンスは、デフォルトでオフになっています。オンにする必要があります。
+ Amazon CloudWatch は、FIPS–140 コンプライアンスを使用する IPv6 のみの設定で、Amazon ECS タスクのモニタリングに使用できるデュアルスタック FIPS エンドポイントをサポートしていません。
+ タスクでは、FIPS-140 コンプライアンスのために次の設定を使用する必要があります。
+ `operatingSystemFamily` は `LINUX` でなければなりません。
+ `cpuArchitecture` は `X86_64` でなければなりません。
+ Fargate プラットフォームバージョンは `1.4.0` 以降である必要があります。
## Fargate で FIPS を使用する
Fargate で FIPS-140 コンプライアンスを使用するには、次の手順を実行します。
1. FIPS-140 コンプライアンスをオンにします。詳細については、「[AWS Fargate 連邦情報処理標準 (FIPS-140) コンプライアンス](ecs-account-settings.md#fips-setting)」を参照してください。
1. オプションで、ECS Exec を使用して次のコマンドを実行し、クラスターの FIPS-140 コンプライアンスステータスを検証できます。
*cluster-name* をクラスターの名前に、*task-id* をタスクの ID または ARN に、*container-name* をコマンドを実行するタスク内のコンテナ名に置き換えます。
戻り値「1」は、FIPS が使用されていることを示します。
```
aws ecs execute-command \
--cluster cluster-name \
--task task-id \
--container container-name \
--interactive \
--command "cat /proc/sys/crypto/fips_enabled"
```
## Fargate FIPS-140 監査に CloudTrail を使用する
CloudTrail は、アカウント作成時に AWS で有効になります。Amazon ECS で API およびコンソールアクティビティが発生すると、そのアクティビティは **[イベント履歴]** で AWS のその他のサービスのイベントとともに CloudTrail イベントにレコードされます。最近のイベントは、AWS アカウントで表示、検索、ダウンロードできます。詳細については、[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)を参照してください。
Amazon ECS のイベントを含む、AWS アカウントでのイベントを継続的に記録するために、CloudTrail がログファイルを Amazon S3 バケットに配信する際に使用する証跡を作成します。デフォルトでは、コンソールで追跡を作成するときに、追跡がすべてのリージョンに適用されます。証跡は、AWS パーティションのすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集したイベントデータをより詳細に分析し、それに基づいて対応するため、他の AWS サービスを構成できます。詳細については、「[AWS CloudTrail を使用して Amazon ECS API コールをログに記録する](logging-using-cloudtrail.md)」を参照してください。
`PutAccountSettingDefault` API アクションを示す CloudTrail ログエントリの例を次に示します。
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAIV5AJI5LXF5EXAMPLE",
"arn": "arn:aws:iam::123456789012:user/jdoe",
"accountId": "123456789012",
"accessKeyId": "AKIAIPWIOFC3EXAMPLE",
},
"eventTime": "2023-03-01T21:45:18Z",
"eventSource": "ecs.amazonaws.com",
"eventName": "PutAccountSettingDefault",
"awsRegion": "us-gov-east-1",
"sourceIPAddress": "52.94.133.131",
"userAgent": "aws-cli/2.9.8 Python/3.9.11 Windows/10 exe/AMD64 prompt/off command/ecs.put-account-setting",
"requestParameters": {
"name": "fargateFIPSMode",
"value": "enabled"
},
"responseElements": {
"setting": {
"name": "fargateFIPSMode",
"value": "enabled",
"principalArn": "arn:aws:iam::123456789012:user/jdoe"
}
},
"requestID": "acdc731e-e506-447c-965d-f5f75EXAMPLE",
"eventID": "6afced68-75cd-4d44-8076-0beEXAMPLE",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"clientProvidedHostHeader": "ecs-fips.us-gov-east-1.amazonaws.com"
}
}
```
# Amazon Elastic Container Service におけるインフラストラクチャセキュリティ
マネージドサービスとして、Amazon Elastic Container Service は AWS グローバルネットワークセキュリティによって保護されています。AWSセキュリティサービスと AWS がインフラストラクチャを保護する方法については、[AWS クラウドセキュリティ](https://aws.amazon.com/security/) を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには *セキュリティの柱 - AWS 適切なアーキテクチャを備えたフレームワーク* の [インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) を参照してください。
AWS が公開している API コールを使用し、ネットワーク経由で Amazon ECS にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
これらの API オペレーションは任意のネットワークの場所から呼び出すことができます。Amazon ECS は、リソースベースのアクセスポリシーをサポートしており、送信元 IP アドレスに基づく制限を含めることができるため、ポリシーがネットワークロケーションの IP アドレスを考慮していることを確認してください。また、Amazon ECS ポリシーを使用して、特定の Amazon Virtual Private Cloud エンドポイントまたは特定の VPC からのアクセスを制御することもできます。これにより、実質的に AWS ネットワーク内の特定の VPC からの特定の Amazon ECS リソースへのネットワークアクセスが分離されます。詳細については、「[Amazon ECS とインターフェイス VPC エンドポイント (AWS PrivateLink)](vpc-endpoints.md)」を参照してください。
# Amazon ECS とインターフェイス VPC エンドポイント (AWS PrivateLink)
インターフェイス VPC エンドポイントを使用するように Amazon ECS を設定することで、VPC のセキュリティ体制を強化できます。インターフェイスエンドポイントは、AWS PrivateLink (プライベート IP アドレスを使用した Amazon ECS API へのプライベートなアクセスを可能にするテクノロジ) により動作しています。AWS PrivateLink は、VPC とAmazon ECS 間のすべてのネットワークトラフィックを、Amazon ネットワークに制限します。インターネットゲートウェイ、NAT デバイス、または仮想プライベートゲートウェイは必要ありません。
AWS PrivateLink および VPC エンドポイントの詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html#concepts-vpc-endpoints)」を参照してください。
## 考慮事項
### 2023 年 12 月 23 日以降に導入されたリージョンのエンドポイントに関する考慮事項
Amazon ECS 用のインターフェイス VPC エンドポイントを設定する前に、以下の考慮事項に注意してください：
+ 次のリージョン固有の VPC エンドポイントが必要です。
**注記**
すべてのエンドポイントを設定しなかった場合、トラフィックが経由するのは VPC エンドポイントではなく、パブリックエンドポイントになります。
+ `com.amazonaws.region.ecs-agent`
+ `com.amazonaws.region.ecs-telemetry`
+ `com.amazonaws.region.ecs`
例えば、カナダ西部 (カルガリー) (ca-west-1) リージョンでは、次の VPC エンドポイントが必要です。
+ `com.amazonaws.ca-west-1.ecs-agent`
+ `com.amazonaws.ca-west-1.ecs-telemetry`
+ `com.amazonaws.ca-west-1.ecs`
+ テンプレートを使用して新しいリージョンに AWS リソースを作成する際に、2023 年 12 月 23 日以前に導入されたリージョンのテンプレートをコピーした場合は、コピー元のリージョンに応じて次のいずれかの操作を実行してください。
例えば、コピー元のリージョンが米国東部 (バージニア北部) (us-east-1) であるとします。コピー先のリージョンは、カナダ西部 (カルガリー) (ca-west-1) です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/vpc-endpoints.html)
### Fargate の Amazon ECS VPC エンドポイントに関する考慮事項
Fargate タスクがデプロイされているのと同じ VPC に `ecr.dkr` および `ecr.api` の VPC エンドポイントがある場合は、その VPC エンドポイントが使用されます。VPC エンドポイントがない場合は、Fargate インターフェースが使用されます。
Amazon ECS 用のインターフェイス VPC エンドポイントを設定する前に、以下の考慮事項に注意してください：
+ Fargate を使用するタスクでは、Amazon ECS 用のインターフェイス VPC エンドポイントは必要ありませんが、以下のように Amazon ECR のインターフェイス VPC エンドポイント、Secrets Manager、または Amazon CloudWatch Logs が必要になる場合があります。
+ Amazon ECR からプライベートイメージをプルできるようにするには、Amazon ECR 用のインターフェイス VPC エンドポイントを 作成する必要があります。詳細については、*Amazon Elastic Container Registry ユーザーガイド*の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)」を参照してください。
**重要**
インターフェイス VPC エンドポイントを使用するよう Amazon ECR を設定する場合、特定の VPC または VPC エンドポイントへのアクセスを制限する条件キーを含むタスク実行ロールを作成できます。詳細については、「[インターフェイスエンドポイントのアクセス許可によって Amazon ECR イメージをプルする Fargate タスクです。](task_execution_IAM_role.md#task-execution-ecr-conditionkeys)」を参照してください。
タスクが IPv6 のみの設定で、Amazon ECR デュアルスタックイメージ URI を使用している場合、Amazon ECR はデュアルスタックインターフェイス VPC エンドポイントに対応しませんので注意してください。詳しくは *Amazon Elastic Container Registry ユーザーガイド*の「[IPv6 を使用したリクエストの実行の開始方法](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started)」をご確認ください。
+ タスクで Secrets Manager から機密データをプルできるようにするには、Secrets Manager 用のインターフェイス VPC エンドポイントを作成する必要があります。詳細については、[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html)の *VPC EndpointでSecrets Managerを使用する* を参照してください。
+ VPC にインターネットゲートウェイがなく、タスクで `awslogs` ログドライバーを使用してログ情報を CloudWatch Logs に送信する場合は、CloudWatch Logs 用のインターフェイス VPC エンドポイントを作成する必要があります。詳細については、[Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)の「*インターフェイス VPC エンドポイントでの CloudWatch Logs の使用*」を参照してください。
+ 現在、VPC エンドポイントはクロスリージョンリクエストをサポートしていません。Amazon ECS に対して API コールを発行するリージョンと同じリージョンにエンドポイントを作成してください。 例えば、タスクを米国東部 (バージニア北部) で実行することを考えてみます。その場合、Amazon ECS VPC エンドポイントは、米国東部 (バージニア北部) に作成する必要があります。他のリージョンで作成された Amazon ECS VPC エンドポイントは、米国東部 (バージニア北部) 内のタスクを実行できません。
+ VPC エンドポイントでは、Amazon Route 53 を介して Amazon 提供の DNS のみがサポートされています。独自の DNS を使用したい場合は、条件付き DNS 転送を使用できます。詳細については、*Amazon VPC ユーザーガイド* の [DHCP Options Sets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) を参照してください。
+ VPC エンドポイントにアタッチされたセキュリティグループは、VPCのプライベートサブネットからの着信接続をポート 443 で許可する必要があります。
+ Envoy プロキシの Service Connect 管理では、`com.amazonaws.region.ecs-agent` VPC エンドポイントを使用します。VPC エンドポイントを使用しない場合、Envoy プロキシの Service Connect 管理は、そのリージョンの `ecs-sc` エンドポイントを使用します。各リージョンの Amazon ECS エンドポイントのリストについては、「[Amazon ECS のエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html)」を参照してください。
### EC2 の Amazon ECS VPC エンドポイントに関する考慮事項
Amazon ECS 用のインターフェイス VPC エンドポイントを設定する前に、以下の考慮事項に注意してください：
+ EC2 を使用するタスクでは、起動されたコンテナインスタンスが Amazon ECS コンテナエージェントのバージョン `1.25.1` 以降を実行する必要があります。詳細については、「[Amazon ECS Linux コンテナインスタンスの管理](manage-linux.md)」を参照してください。
+ タスクで Secrets Manager から機密データをプルできるようにするには、Secrets Manager 用のインターフェイス VPC エンドポイントを作成する必要があります。詳細については、[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html)の *VPC EndpointでSecrets Managerを使用する* を参照してください。
+ VPC にインターネットゲートウェイがなく、タスクで `awslogs` ログドライバーを使用してログ情報を CloudWatch Logs に送信する場合は、CloudWatch Logs 用のインターフェイス VPC エンドポイントを作成する必要があります。詳細については、[Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)の「*インターフェイス VPC エンドポイントでの CloudWatch Logs の使用*」を参照してください。
+ 現在、VPC エンドポイントはクロスリージョンリクエストをサポートしていません。Amazon ECS に対して API コールを発行するリージョンと同じリージョンにエンドポイントを作成してください。 例えば、タスクを米国東部 (バージニア北部) で実行することを考えてみます。その場合、Amazon ECS VPC エンドポイントは、米国東部 (バージニア北部) に作成する必要があります。他のリージョンで作成された Amazon ECS VPC エンドポイントは、米国東部 (バージニア北部) 内のタスクを実行できません。
+ VPC エンドポイントでは、Amazon Route 53 を介して Amazon 提供の DNS のみがサポートされています。独自の DNS を使用したい場合は、条件付き DNS 転送を使用できます。詳細については、*Amazon VPC ユーザーガイド* の [DHCP Options Sets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) を参照してください。
+ VPC エンドポイントにアタッチされたセキュリティグループは、VPCのプライベートサブネットからの着信接続をポート 443 で許可する必要があります。
## Amazon ECS エンドポイントの命名パターンについて
Amazon ECS エージェントは、次のような番号付きサフィックスを備えたエンドポイントにリクエストを行う場合があることを理解することが重要です。
+ エージェントエンドポイントの場合 `ecs-a-1.region.amazonaws.com`、`ecs-a-2.region.amazonaws.com` など
+ テレメトリエンドポイントの場合 `ecs-t-1.region.amazonaws.com`、`ecs-t-2.region.amazonaws.com` など
この動作は、Amazon ECS エージェントが [DiscoverPollEndpoint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DiscoverPollEndpoint.html) API を使用して接続する特定のエンドポイントを動的に決定するため発生します。VPC エンドポイントがこれらの番号付きエンドポイントのバリエーションを適切に処理しない場合、ベース名に VPC エンドポイントを設定していても、エージェントはパブリックエンドポイントの使用にフォールバックします。
### DiscoverPollEndpoint API の役割
[DiscoverPollEndpoint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DiscoverPollEndpoint.html) API は、タスクをポーリングする適切なエンドポイントを検出するため Amazon ECS エージェントによって使用されます。エージェントがこの API を呼び出すと、番号付きサフィックスを含む場合がある特定のエンドポイント URL を受け取ります。VPC エンドポイントが正しく動作するようにするには、ネットワーク設定でエージェントに以下を許可する必要があります。
1. DiscoverPollEndpoint API へのアクセス
1. 番号付きサフィックスを含む、返されたエンドポイント URL への接続
VPC エンドポイントの接続の問題をトラブルシューティングする場合は、エージェントがベースエンドポイントと、DiscoverPollEndpoint API によって返される可能性のある番号付きバリエーションの両方に到達できることを確認します。
## Amazon ECS 用の VPC エンドポイントの作成
Amazon ECS サービス用の VPC エンドポイントを作成するには、「*Amazon VPC ユーザーガイド*」の「[インターフェイス VPC エンドポイント手順を使用して AWS サービスにアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)」の手順を使用して、以下のエンドポイントを作成します。VPC 内に既存のコンテナインスタンスがある場合は、一覧表示されている順にエンドポイントを作成する必要があります。VPC エンドポイントが作成された後にコンテナインスタンスを作成する場合、順序は関係ありません。
**注記**
すべてのエンドポイントを設定しなかった場合、トラフィックが経由するのは VPC エンドポイントではなく、パブリックエンドポイントになります。
エンドポイントを作成すると、Amazon ECS はエンドポイントのプライベート DNS 名も作成します。例えば、ecs-agent の `ecs-a.region.amazonaws.com` とecs-telemetry の `ecs-t.region.amazonaws.com` です。
+ `com.amazonaws.region.ecs-agent`
+ `com.amazonaws.region.ecs-telemetry`
+ `com.amazonaws.region.ecs`
**注記**
*region* は、米国東部 (オハイオ) リージョンの `us-east-2` のように、Amazon ECS でサポートされている AWS リージョンのリージョン識別子を表します。
`ecs-agent` エンドポイントは `ecs:poll` API を使用し、`ecs-telemetry` エンドポイントは `ecs:poll` および `ecs:StartTelemetrySession` API を使用します。
EC2 起動タイプを使用する既存のタスクがある場合は、VPC エンドポイントを作成した後に、各コンテナインスタンスで新しい設定が選択される必要があります。そのためには、各コンテナインスタンスを再起動するか、各コンテナインスタンスで Amazon ECS コンテナエージェントを再起動する必要があります。コンテナエージェントを再起動するには、以下を実行します。
**Amazon ECS コンテナエージェントを再起動するには**
1. SSH 経由でコンテナインスタンスにログインします。
1. コンテナエージェントを停止します。
```
sudo docker stop ecs-agent
```
1. コンテナエージェントを開始します。
```
sudo docker start ecs-agent
```
VPC エンドポイントを作成し、各コンテナインスタンスで Amazon ECS コンテナエージェントを再起動したら、新しく起動されるすべてのタスクで新しい設定が選択されます。
## Amazon ECS 用の VPC エンドポイントポリシーの作成
VPC エンドポイントに Amazon ECS へのアクセスをコントロールするエンドポイントポリシーをアタッチできます。このポリシーでは、以下の情報を指定します。
+ アクションを実行できるプリンシパル。
+ 実行可能なアクション。
+ アクションを実行できるリソース。
詳細については、*Amazon VPC ユーザーガイド*の「[VPC エンドポイントによるサービスのアクセスコントロール](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。
**例: Amazon ECS アクションの VPC エンドポイントポリシー**
Amazon ECS のエンドポイントポリシーの例を次に示します。このポリシーは、エンドポイントに接続すると、クラスターの作成や一覧表示が行えるようにアクセスを許可します。`CreateCluster` と `ListClusters` のアクションはリソースを受け入れないため、すべてのリソースでリソース定義は \$1 に設定されます。
```
{
"Statement":[
{
"Principal":"*",
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:ListClusters"
],
"Resource": [
"*"
]
}
]
}
```
# Amazon ECS の AWS 責任共有モデル。
セキュリティとコンプライアンスに関して、AWS とお客様の間で責任を共有します。この共有モデルにより、ホストオペレーティングシステムや仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまで、さまざまなコンポーネントを AWS が運用、管理、制御するため、お客様の運用の負担が軽減されます。お客様は、AWS が提供するセキュリティグループのファイアウォール設定に加えて、ゲストオペレーティングシステム (更新やセキュリティパッチを含む) およびその他の関連アプリケーションソフトウェアを管理し、責任を持って管理する必要があります。お客様の責任範囲は、使用するサービス、IT 環境へのサービス統合、適用される法規制に応じて異なります。このため、お客様は選択するサービスを注意深く検討する必要があります。この責任共有モデルの性質によって柔軟性が得られ、お客様はデプロイを統制できます。
## Fargate
次の図は、Fargate 起動タイプの責任共有モデルを示しています。Fargate は分離されたハードウェア仮想化環境で各ワークロードを実行します。その結果、各タスクは専用のインフラストラクチャキャパシティを取得します。Fargate で実行されているコンテナ化されたワークロードは、オペレーティングシステム、Linux カーネル、ネットワークインターフェイス、エフェメラルストレージ、CPU、またはメモリを他のタスクと共有しません。Fargate を使用する場合、お客様はコンテナを実行するコンピューティングインフラストラクチャのセキュリティを管理する責任を負いません。Fargate は、お客様のワークロードを実行するインフラストラクチャをプロビジョニングしてパッチを適用します。詳細については、「[AWS Fargate on Amazon ECS のタスクの廃止とメンテナンス](task-maintenance.md)」を参照してください。
お客様は次のリソースを管理する責任があります。
+ VPC、NACL、セキュリティグループ、ルートテーブルなどのネットワーク設定
+ クライアントとサービスストレージの暗号化。詳細については、「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
+ コンテナイメージ 詳細については、「[Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス](security-tasks-containers.md)」を参照してください。
+ タスクロールを使用したアプリケーションの IAM アクセス許可。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
![\[Amazon ECS での Fargate の責任共有モデルを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/fargate-shared-responsibility.png)
## EC2
次の図は、EC2 の責任共有を示しています。EC2 インスタンスでタスクを実行する場合、次のリソースに加えて EC2 インスタンスを保守する責任があります。
+ Amazon ECS エージェント。
+ • パッチ適用と強化を含む EC2 インスタンス AMI。
+ VPC、NACL、セキュリティグループ、ルートテーブルなどのネットワーク設定。
+ クライアントとサービスストレージの暗号化。詳細については、「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
+ コンテナイメージ 詳細については、「[Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス](security-tasks-containers.md)」を参照してください。
+ タスクロールを使用したアプリケーションの IAM アクセス許可。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
![\[Amazon ECS 用の EC2 の責任共有モデルを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/ec2-shared-responsibility.png)
# Amazon ECS マネージドインスタンスの責任共有モデル
Amazon ECS マネージドインスタンスは、Fargate のシンプルな運用と、幅広い Amazon EC2 インスタンスタイプと機能へのアクセスを組み合わせて、コンテナ化されたワークロードによるマネージドソリューションを提供します。AWS はインフラストラクチャのプロビジョニング、パッチ適用、スケーリング、メンテナンスを処理し、お客様はアプリケーションと特定の設定を制御します。
Fargate とは異なり、Amazon ECS マネージドインスタンスで実行されているコンテナ化されたワークロードは、オペレーティングシステム、Linux カーネル、ネットワークインターフェイス、エフェメラルストレージ、CPU、メモリ、GPU リソースを、同じインスタンス上の他のタスクと共有します。Amazon ECS は、未使用の容量を最小限に抑えるために、より大きいインスタンスに複数のタスクを配置することで、インフラストラクチャの使用率を最適化します。
## AWS の責任
Amazon ECS マネージドインスタンスを使用する場合、AWS は以下を担当します。
+ インスタンスのプロビジョニングとライフサイクル管理
+ オペレーティングシステムのパッチ適用とセキュリティ更新
+ インフラストラクチャのスケーリングと最適化
+ インスタンスの置換とメンテナンス (最大 21 日間のインスタンス有効期間)
+ アクセスコントロールの制限 (SSH アクセスなし、SSM セッションマネージャーのアクセスなし)
+ Amazon EC2 インスタンスストレージは暗号化され、インスタンスに直接アタッチされたストレージとなります。詳細については、「[Amazon EC2 でのデータ保護](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html)」を参照してください。
+ Amazon ECS は、ルートボリュームやデータボリュームなど、作成時に Amazon EC2 インスタンスにアタッチされたボリュームを管理します。
+ Amazon ECS は内部で Amazon EC2 マネージドインスタンスを使用します。Amazon EC2 マネージドインスタンスの詳細については、「[Amazon EC2 のセキュリティ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)」を参照してください。
## お客様の責任
お客様は次のリソースを管理する責任があります。
+ VPC、NACL、セキュリティグループ、ルートテーブルなどのネットワーク設定
+ クライアントとサービスストレージの暗号化。詳細については、「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
+ コンテナイメージ 詳細については、「[Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス](security-tasks-containers.md)」を参照してください。
+ タスクロールを使用したアプリケーションの IAM アクセス許可。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
+ アプリケーションレベルの設定とモニタリング
+ タスクとサービスの定義
+ 基盤となるインスタンスリソースを共有するワークロードに関するセキュリティ上の考慮事項
+ 有効な場合の特権コンテナ設定と拡張 Linux 機能 (CAP\$1NET\$1ADMIN、CAP\$1BPF など)
+ Amazon ECS API による管理オペレーション (SSH または SSM 経由のインスタンスへの直接アクセスは利用できません)
# Amazon ECS のネットワークセキュリティのベストプラクティス
ネットワークセキュリティは、いくつかのサブトピックを含む幅広いトピックです。これには、転送中の暗号化、ネットワークのセグメンテーションと分離、ファイアウォール、トラフィックルーティング、オブザーバビリティなどが含まれます。
## 転送中の暗号化
ネットワークトラフィックを暗号化することで、データがネットワーク経由で送信されるときに、権限のないユーザーにデータを傍受されて読み取られることを防ぎます。Amazon ECS では、次のいずれかの方法でネットワーク暗号化を実装できます。
+ **Nitro インスタンスを使用する:**
デフォルトでは、C5n、G4、I3en、M5dn、M5n、P3dn、R5dn、R5n の Nitro インスタンスタイプ間のトラフィックは自動的に暗号化されます。トラフィックがトランジットゲートウェイ、ロードバランサー、または同様の仲介を経由する場合、トラフィックは暗号化されません。
+ [転送時の暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit)
+ [2019年の新発表](https://aws.amazon.com/about-aws/whats-new/2019/10/introducing-amazon-ec2-m5n-m5dn-r5n-and-r5dn-instances-featuring-100-gbps-of-network-bandwidth/)
+ [「リ・インフォース 2019」からの会話](https://youtu.be/oqHLLbOoxDg?si=Us1YhSiY4deXLFA7)
+ **Application Load Balancer で Server Name Indication (SNI) を使用する**
Application Load Balancer (ALB) と Network Load Balancer (NLB) は、Server Name Indication (SNI) をサポートします。SNI を使用すると、複数の安全なアプリケーションを 1 つのリスナーのバックグラウンドに配置できます。そのため、各リスナーには独自の TLS 証明書があります。AWS Certificate Manager (ACM) を使用してロードバランサーの証明書をプロビジョニングし、リスナーの証明書リストに追加することをお勧めします。AWS ロードバランサーは、SNI を使用するスマート証明書の選択アルゴリズムを使用します。クライアントから提供されたホスト名と一致する証明書がリスト内にひとつだけある場合、ロードバランサーはこの証明書を選択します。クライアントが提供するホスト名と一致する証明書がリスト内に複数ある場合、ロードバランサーはクライアントがサポートできる証明書を選択します。例として、自己署名証明書や ACM を通じて生成された証明書などがあげられます。
+ [Application Load Balancer で SNI を使用する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#https-listener-certificates)
+ [Network Load Balancer で SNI を使用する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-listener.html)
+ **TLS 証明書を使用したエンドツーエンド暗号化:**
これには、タスクとともに TLS 証明書をデプロイすることが含まれます。自己署名証明書でも、信頼できる認証局からの証明書でもかまいません。証明書のシークレットを参照することで証明書を取得できます。それ以外の場合は、ACM に証明書署名リクエスト (CSR) を発行し、その結果得られたシークレットを共有ボリュームにマウントするコンテナを実行することもできます。
+ [Amazon ECS でNetwork Load Balancer を使用してコンテナまでトランスポートレイヤーのセキュリティを維持する (パート 1)](https://aws.amazon.com/blogs//compute/maintaining-transport-layer-security-all-the-way-to-your-container-using-the-network-load-balancer-with-amazon-ecs/)
+ [コンテナまで Transport Layer Security (TLS) を維持する (パート 2): AWS Private Certificate Authority を使用する](https://aws.amazon.com/blogs//compute/maintaining-transport-layer-security-all-the-way-to-your-container-part-2-using-aws-certificate-manager-private-certificate-authority/)
## タスクネットワーク
以下の推奨事項は Amazon ECS の仕組みに関する考慮したものです。Amazon ECS はオーバーレイネットワークを使用しません。代わりに、タスクは異なるネットワークモードで動作するように設定されます。たとえば、`bridge` モードを使用するように設定されたタスクは、各ホストで実行される Docker ネットワークからルーティングできない IP アドレスを取得します。`awsvpc` ネットワークモードを使用するように設定されたタスクは、ホストのサブネットから IP アドレスを取得します。`host` ネットワークを使用して構成されたタスクはホストのネットワークインターフェースを使用します。`awsvpc` が推奨ネットワークモードです。これは、タスクにセキュリティグループを割り当てるのに使用できる唯一のモードであるため推奨されます。また、Amazon ECS の AWS Fargate タスクで使用できる唯一のモードでもあります。
### タスクのセキュリティグループ
`awsvpc` ネットワークモードを使用するようにタスクを設定することをお勧めします。このモードを使用するようにタスクを設定すると、Amazon ECS エージェントは自動的に Elastic Network Interface (ENI) をプロビジョニングしてタスクにアタッチします。ENI がプロビジョニングされると、タスクは AWS セキュリティグループに登録されます。セキュリティグループは、インバウンドトラフィックとアウトバウンドトラフィックをコントロールするための仮想ファイアウォールとして機能します。
タスクまたはサービスでカスタムファイアウォールを使用する場合は、Amazon ECS エージェント管理エンドポイント (「`ecs-a-*.region.amazonaws.com`」)、テレメトリエンドポイント (「`ecs-t-*.region.amazonaws.com`」)、および Service Connect Envoy 管理エンドポイント (「`ecs-sc.region.api.aws`」) のトラフィックを許可するアウトバウンドルールを追加します。
## AWS PrivateLink および Amazon ECS
AWS PrivateLink は Amazon ECS を含むさまざまな AWS サービスのプライベートエンドポイントを作成できるようにするネットワーク技術です。エンドポイントは、Amazon VPC に Internet Gateway (IGW) が接続されておらず、インターネットへの代替ルートもないサンドボックス環境で必要となります。AWS PrivateLink を使用することで、Amazon ECS サービスへの呼び出しが Amazon VPC 内にとどまり、インターネットを経由しないことが保証されます。Amazon ECS およびその他の関連サービスの AWS PrivateLink エンドポイントを作成する方法については、「[Amazon ECS インターフェイス Amazon VPC エンドポイント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html)」を参照してください。
**重要**
AWS Fargate タスクには Amazon ECS の AWS PrivateLink エンドポイントは必要ありません。
Amazon ECR と Amazon ECS はどちらもエンドポイントポリシーをサポートしています。これらのポリシーにより、サービスの API へのアクセスを絞り込むことができます。たとえば、特定の AWS アカウントのレジストリにのみイメージをプッシュすることを許可する Amazon ECR のエンドポイントポリシーを作成できます。このようなポリシーは、コンテナイメージを通じてデータが流出するのを防ぎつつ、ユーザーが許可された Amazon ECR レジストリにプッシュできるようにするために使用できます。詳細については、「[VPC エンドポイントポリシーの使用](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#vpc-endpoint-policies)」を参照してください。
以下のポリシーでは、アカウントのすべての AWS プリンシパルが Amazon ECR リポジトリに対してのみ、すべてのアクションを実行できるようにします。
```
{
"Statement": [
{
"Sid": "LimitECRAccess",
"Principal": "*",
"Action": "*",
"Effect": "Allow",
"Resource": "arn:aws:ecr:region:account_id:repository/*"
},
]
}
```
新しい `PrincipalOrgID` プロパティを使用する条件を設定することで、これをさらに強化できます。これにより、ユーザーの AWS Organizations の一部ではない IAM プリンシパルによるイメージのプッシュやプルを防ぐことができます。詳細については、「[aws:PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid)」を参照してください。
`com.amazonaws.region.ecr.dkr` と `com.amazonaws.region.ecr.api` エンドポイントの両方に同じポリシーを適用することをお勧めします。
## コンテナエージェントの設定
Amazon ECS コンテナエージェント設定ファイルには、ネットワークセキュリティに関連する複数の環境変数が含まれています。`ECS_AWSVPC_BLOCK_IMDS` と `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST` は、Amazon EC2 メタデータへのタスクのアクセスをブロックするために使用されます。`HTTP_PROXY` は、HTTP プロキシを経由してインターネットに接続するようにエージェントを設定するために使用されます。エージェントと Docker ランタイムをプロキシ経由でルーティングするように設定する方法については、「[HTTP プロキシ設定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/http_proxy_config.html)」を参照してください。
**重要**
AWS Fargate を使用する場合は、これらの設定を使用することはできません。
## ネットワークセキュリティに関する推奨事項
Amazon VPC、ロードバランサー、ネットワークを設定するときは、次のことを行うことをお勧めします。
### Amazon ECS で必要に応じてネットワーク暗号化を使用する
必要に応じてネットワーク暗号化を使用してください。PCI DSS などの特定のコンプライアンスプログラムでは、データにカード所有者のデータが含まれている場合、転送中のデータを暗号化する必要があります。ワークロードに同様の要件がある場合は、ネットワーク暗号化を設定してください。
最新のブラウザでは、安全でないサイトに接続するとユーザーに警告が表示されます。公開されているロードバランサーがサービスのフロントエンドで使用されている場合は、TLS/SSL を使用してクライアントのブラウザーからロードバランサーへのトラフィックを暗号化し、必要に応じてバックエンドで再暗号化します。
### `awsvpc` ネットワークモードとセキュリティグループを使用して、Amazon ECS のタスクと他のリソース間のトラフィックを制御する
タスク間のトラフィック、またはタスクと他のネットワークリソース間のトラフィックを制御する必要がある場合は、`awsvpc` ネットワークモードとセキュリティグループを使用してください。サービスが ALB の内部にある場合は、セキュリティグループを使用して、ALB と同じセキュリティグループを使用する他のネットワークリソースからのインバウンドトラフィックのみを許可します。アプリケーションが NLB の背後にある場合は、Amazon VPC CIDR 範囲からのインバウンドトラフィックと NLB に割り当てられた静的 IP アドレスのみを許可するようにタスクのセキュリティグループを設定します。
セキュリティグループは、タスクと Amazon VPC 内の他のリソース (Amazon RDS データベースなど) との間のトラフィックを制御するためにも使用する必要があります。
### ネットワークトラフィックを厳密に分離する必要がある場合に、別の Amazon VPC に Amazon ECS クラスターを作成する
ネットワークトラフィックを厳密に分離する必要がある場合は、別の Amazon VPC にクラスターを作成してください。セキュリティ要件が厳しいワークロードを、その要件を満たす必要のないワークロードを含むクラスターで実行することは避けてください。ネットワークの厳密な分離が必須の場合は、別の Amazon VPC にクラスターを作成し、Amazon VPC エンドポイントを使用して他の Amazon VPC にサービスを選択的に公開します。詳細については、「[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html#concepts-vpc-endpoints)」を参照してください。
### Amazon ECS で必要に応じて AWS PrivateLink エンドポイントを設定する
AWS PrivateLink エンドポイントは、必要に応じて設定してください。セキュリティポリシーにより Amazon VPC にインターネットゲートウェイ (IGW) をアタッチできない場合は、Amazon ECS や Amazon ECR、AWS Secrets Manager、Amazon CloudWatch などの他のサービスの AWS PrivateLink エンドポイントを設定します。
### Amazon VPC フローログを使用して、Amazon ECS の長時間実行されるタスクとの間のトラフィックを分析する
長時間実行されるタスクとの間のトラフィックを分析するには、Amazon VPC フローログを使用してください。`awsvpc` ネットワークモードを使用するタスクには独自の ENI が割り当てられます。これにより、Amazon VPC フローログを使用して個々のタスクに出入りするトラフィックをモニタリングできます。Amazon VPC フローログ (v3) の最新アップデートでは、VPC ID、サブネット ID、インスタンス ID などのトラフィックメタデータがログに追加されました。このメタデータを使用して、調査を絞り込むことができます。詳細については、「[Amazon VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-logs-basics)」を参照してください。
**注記**
コンテナは一時的な性質を持つため、フローログは、異なるコンテナの間やコンテナとその他のネットワークリソースの間のトラフィックパターンを分析するうえで必ずしも効果的な方法であるとは限りません。
# Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス
コンテナイメージは、攻撃に対する防御の最前線と見なしてください。安全性が低く、構築が不十分なイメージがあると、攻撃者はコンテナの境界を抜け出し、ホストにアクセスできるようになる可能性があります。これが発生するリスクを軽減するには、次のことを行う必要があります。
タスクとコンテナを設定するときは、次のことを行うことをお勧めします。
## 最小限のイメージを作成するか、distroless のイメージを使用する
まず、コンテナイメージから不要なバイナリをすべて削除します。Amazon ECR Public Gallery にある見慣れないイメージを使用している場合は、そのイメージを調べてコンテナの各レイヤーの内容を参照してください。これには [Dive](https://github.com/wagoodman/dive) などのアプリケーションを使用できます。
あるいは、アプリケーションとそのランタイム依存関係のみを含む **distroless** イメージを使用することもできます。パッケージマネージャーやシェルは含まれません。Distroless イメージは、「スキャナーの信号対雑音比を向上させ、必要なものだけを調達する負担を軽減する」ことができます。詳細については、GitHub の [distroless](https://github.com/GoogleContainerTools/distroless) に関するドキュメントを参照してください。
Docker には、**scratch** と呼ばれる、予約済みの最小限のイメージからイメージを作成するメカニズムがあります。詳細については、Docker ドキュメントの「[**scratch** を使用した単純な親イメージの作成](https://docs.docker.com/develop/develop-images/baseimages/#create-a-simple-parent-image-using-scratch)」を参照してください。Go などの言語では、静的にリンクされたバイナリを作成して Dockerfile で参照できます。以下の例で、その方法を示します。
```
############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder
# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache git
WORKDIR $GOPATH/src/mypackage/myapp/
COPY . .
# Fetch dependencies.
# Using go get.
RUN go get -d -v
# Build the binary.
RUN go build -o /go/bin/hello
############################
# STEP 2 build a small image
############################
FROM scratch
# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello
# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]
This creates a container image that consists of your application and nothing else, making it extremely secure.
```
前の例も、マルチステージビルドの例です。これらのタイプのビルドは、コンテナレジストリにプッシュされる最終イメージのサイズを最小限に抑えることができるため、セキュリティの観点からは魅力的です。コンテナイメージからビルドツールやその他の無関係なバイナリを省くことで、イメージのアタックサーフェスが減り、セキュリティ対策を強化することができます。マルチステージビルドの詳細については、Docker ドキュメントの「[Multi-stage builds](https://docs.docker.com/build/building/multi-stage/)」を参照してください。
## イメージをスキャンして脆弱性がないか調べる
対応する仮想マシンと同様に、コンテナイメージには脆弱性のあるバイナリやアプリケーションライブラリが含まれていたり、時間の経過とともに脆弱性が生じたりする可能性があります。エクスプロイトから保護する最善の方法は、イメージスキャナーでイメージを定期的にスキャンすることです。
Amazon ECR には、共通脆弱性識別子 (CVE) データベースを使用する 2 つのバージョンの基本スキャンが用意されています。
+ **AWS ネイティブ基本スキャン** – AWS ネイティブテクノロジーを使用してください。これは現在一般提供中であり、推奨されるアプローチです。この改善された基本スキャンは、さまざまな人気のオペレーティングシステムにおいてより優れたスキャン結果と脆弱性検出を提供するよう設計されています。これにより、お客様はコンテナイメージのセキュリティをさらに強化できます。すべての新しい顧客レジストリは、デフォルトでこの改善されたバージョンにオプトインされます。
+ **Clair 基本スキャン** – オープンソースの Clair プロジェクトを使用する旧バージョンの基本スキャン。Clair の詳細については、GitHub の [Clair](https://github.com/quay/clair) を参照してください。
AWS ネイティブスキャンと Clair 基本スキャンは、2024 年 9 月以降に新たに追加されたリージョンを除き、「[リージョン別 AWS サービス](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」にリストされているすべてのリージョンでサポートされています。Clair のサポートは非推奨であるため、Clair は追加された新しいリージョンではサポートされておらず、また 2025 年 10 月 1 日をもってすべてのリージョンでのサポートを停止します。
Amazon ECR では、アップストリームのディストリビューションソースからの CVE の重要度が使用されます (使用可能な場合)。それ以外の場合は、共通脆弱性評価システム (CVSS) のスコアが使用されます。CVSS スコアは、NVD 脆弱性の重大度評価を取得するために使用できます。詳細については、「[NVD 脆弱性の重大度](https://nvd.nist.gov/vuln-metrics/cvss)」を参照してください。
また、Amazon ECR コンソール内から、あるいは [DescribeImageScanFindings API](https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_DescribeImageScanFindings.html) を呼び出して、スキャンの結果を確認することもできます。脆弱性が `HIGH` または `CRITICAL` のイメージは、削除するか再構築する必要があります。デプロイされたイメージに脆弱性が生じた場合は、できるだけ早く交換する必要があります。
[Docker Desktop Edge バージョン 2.3.6.0](https://www.docker.com/products/docker-desktop/) 以降では、ローカルイメージを[スキャン](https://docs.docker.com/engine/scan/)できます。スキャンはアプリケーションセキュリティサービスの [Snyk](https://snyk.io/) によって行われます。脆弱性が発見されると、Snyk は Dockerfile 内の脆弱性のあるレイヤーと依存関係を識別します。また、脆弱性が少なく、よりスリムなベースイメージを使用したり、特定のパッケージを新しいバージョンにアップグレードしたりするなど、安全な代替手段も推奨します。Docker スキャンを使用すれば、開発者はイメージをレジストリにプッシュする前に、潜在的なセキュリティ問題を解決できます。
+ [Amazon ECR と AWS Security Hub CSPM を使用してイメージコンプライアンスを自動化する](https://aws.amazon.com/blogs/containers/automating-image-compliance-for-amazon-eks-using-amazon-elastic-container-registry-and-aws-security-hub/)では、AWS Security Hub CSPM の Amazon ECR から脆弱性情報を検出し、脆弱なイメージへのアクセスをブロックすることで修復を自動化する方法について説明します。
## イメージから特別な権限を削除する
アクセス権フラグ`setuid` と `setgid` は、実行ファイルの所有者またはグループの権限で実行できるようにします。これらのアクセス権限を持つバイナリは権限昇格に利用される可能性があるため、イメージからすべてのバイナリを削除してください。悪意のある目的に使用される可能性のある、`nc` や `curl` などのシェルやユーティリティをすべて削除することを検討してください。次のコマンドを使用すると `setuid` および `setgid` アクセス権のあるファイルを見つけることができます。
```
find / -perm /6000 -type f -exec ls -ld {} \;
```
これらのファイルから、これらの特別な権限を削除するには、以下のディレクティブをコンテナイメージに追加します。
```
RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true
```
## キュレーションされたイメージのセットを作成する
開発者が独自のイメージを作成できるようにするのではなく、組織内のさまざまなアプリケーションスタック用に、検証済みのイメージセットを作成することができます。そうすることで、開発者は Dockerfile の作成方法を学ぶ必要がなくなり、コードの記述に集中できます。変更がコードベースにマージされると、CI/CD パイプラインがアセットを自動的にコンパイルし、アーティファクトリポジトリに保存できます。最後に、アーティファクトを適切なイメージにコピーしてから、Amazon ECR などの Docker レジストリにプッシュします。少なくとも、開発者が独自の Dockerfile を作成できるようなベースイメージのセットを作成する必要があります。Docker Hub からイメージをプルすることは避けてください。イメージに含まれている内容が常に明らかであるとは限りません。イメージが脆弱性を抱えている可能性もあります。
## アプリケーションパッケージとライブラリをスキャンして脆弱性がないか調べる
オープンソースライブラリの使用は今や一般的になっています。オペレーティングシステムや OS パッケージと同様に、これらのライブラリには脆弱性が潜んでいる可能性があります。開発ライフサイクルの一環として、重大な脆弱性が見つかった場合は、これらのライブラリをスキャンして更新する必要があります。
Docker Desktop は Snyk を使用してローカルスキャンを実行します。また、オープンソースライブラリの脆弱性や潜在的なライセンス問題の検出にも使用できます。開発者のワークフローに直接統合できるため、オープンソースライブラリがもたらすリスクを軽減できます。詳細については、以下の各トピックを参照してください。
+ [オープンソースのアプリケーションセキュリティツール](https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools)には、アプリケーションの脆弱性を検出するためのツールのリストが含まれています。
## 静的コード分析を行う
コンテナイメージを構築する前に、静的コード分析を実行する必要があります。これはソースコードに対して実行され、コーディングエラーや、フォールトインジェクションなどの悪意のある攻撃者に悪用される可能性のあるコードの特定に使用されます。Amazon Inspector を使用できます。詳細については、「Amazon Inspector ユーザーガイド」の「[Amazon Inspector による Amazon ECR コンテナイメージのスキャン](https://docs.aws.amazon.com/inspector/latest/user/scanning-ecr.html)」を参照してください。**
## 非ルートユーザーとしてコンテナを実行する
コンテナを実行するときは、非ルートユーザーとして実行してください。デフォルトでは、Dockerfile に `USER` ディレクティブが含まれていない限り、コンテナは `root` ユーザーとして実行されます。Docker によって割り当てられるデフォルトの Linux 機能では、`root` として実行できるアクションが制限されますが、制限されるのはごくわずかです。例えば、`root` として実行しているコンテナは、デバイスにアクセスすることがまだできません。
CI/CD パイプラインの一部として、Dockerfiles をリントして `USER` ディレクティブを探し、見つからない場合はビルドを失敗させる必要があります。詳細については、以下の各トピックを参照してください。
+ [Dockerfile-lint](https://github.com/projectatomic/dockerfile_lint) は RedHat のオープンソースツールで、ファイルがベストプラクティスに準拠しているかどうかを確認するために使用できます。
+ [Hadolint](https://github.com/hadolint/hadolint) も、ベストプラクティスに準拠した Docker イメージを構築するためのツールです。
## 読み取り専用のルートファイルシステムを使用する
読み取り専用のルートファイルシステムを使用してください。コンテナのルートファイルシステムは、デフォルトでは書き込み可能です。コンテナに `RO` (読み取り専用) ルートファイルシステムを設定すると、データを保存できる場所を明示的に定義する必要性が生じます。これにより、権限が具体的に付与されない限りコンテナのファイルシステムに書き込みができなくなるため、アタックサーフェスが減少します。
**注記**
ルートファイルシステムが読み取り専用であると、そのファイルシステムへの書き込みが可能であることを想定している特定の OS パッケージで問題が発生する可能性があります。読み取り専用のルートファイルシステムを使用する予定がある場合は、事前に十分にテストしてください。
## CPU とメモリの制限を設定してタスクを設定する (Amazon EC2)
以下のリスクを最小限に抑えるには、CPU とメモリの制限を設定してタスクを設定する必要があります。タスクのリソース制限は、タスク内のすべてのコンテナで予約できる CPU とメモリの量の上限を設定します。制限が設定されていない場合、タスクはホストの CPU とメモリにアクセスできます。これにより、共有ホストにデプロイされたタスクが他のタスクのシステムリソースを枯渇させるという問題が発生する可能性があります。
**注記**
Amazon ECS on AWS Fargate Tasks では CPU とメモリの制限を指定する必要があります。これらの値は請求目的で使用されるためです。Amazon ECS Fargate では、1 つのタスクがすべてのシステムリソースを占有しても問題にはなりません。各タスクは専有インスタンスで実行されるからです。メモリ制限を指定しない場合、Amazon ECS は各コンテナに最低 4MB を割り当てます。同様に、タスクに CPU 制限が設定されていない場合、Amazon ECS コンテナエージェントはタスクに最低 2 つの CPU を割り当てます。
## Amazon ECR でイミュータブルタグを使用する
Amazon ECR では、イミュータブルタグを使用してイメージを設定することができるので、これを使用するようにしてください。これにより、変更または更新されたバージョンの画像が、同一のタグで画像リポジトリにプッシュされるのを防ぐことができます。また、攻撃者が侵害されたバージョンのイメージを同じタグが付いたイメージにプッシュすることを防ぐことができます。イミュータブルタグを使用すれば、変更するたびに異なるタグが付いた新しいイメージを効果的にプッシュできます。
## コンテナを特権として実行することは避けてください (Amazon EC2)
コンテナを特権として実行することは避けてください。バックグラウンドでは、`privileged` として実行されるコンテナは、ホスト上で拡張された権限でされます。つまり、ホスト上で `root` に割り当てられた Linux 機能がすべてコンテナに継承されるということです。その使用は厳しく制限するか禁止してください。Amazon ECS コンテナエージェント環境変数 `ECS_DISABLE_PRIVILEGED` を `true` に設定して、`privileged` が必要がない場合はコンテナが `privileged` として特定のホストで実行されないようにすることをお勧めします。あるいは、AWS Lambda を使用してタスク定義をスキャンして `privileged` パラメータを使用することもできます。
**注記**
AWS Fargate 上の Amazon ECS では、コンテナを `privileged` として実行することはサポートされていません。
## 不要な Linux 機能をコンテナから削除する
Docker コンテナに割り当てられているデフォルトの Linux 機能のリストを以下に示します。各機能の詳細については、「[Linux 機能の概要](https://man7.org/linux/man-pages/man7/capabilities.7.html)」を参照してください。
```
CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL,
CAP_SETGID, CAP_SETUID, CAP_SETPCAP, CAP_NET_BIND_SERVICE,
CAP_NET_RAW, CAP_SYS_CHROOT, CAP_MKNOD, CAP_AUDIT_WRITE,
CAP_SETFCAP
```
コンテナが上記の Docker カーネル機能のすべてを必要としない場合は、それらをコンテナから削除することを検討してください。各 Docker カーネル機能の詳細については、「[KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html)」を参照してください。次の操作を実行することで、どの機能が使われているかを確認できます。
+ OS パッケージ [libcap-ng](https://people.redhat.com/sgrubb/libcap-ng) をインストールし、`pscap` ユーティリティを実行して各プロセスが使用している機能を一覧表示します。
+ [capsh](https://www.man7.org/linux/man-pages/man1/capsh.1.html) を使用して、プロセスが使用している機能を解読することもできます。
## カスタマーマネージドキー (CMK) を使用して Amazon ECR にプッシュされるイメージを暗号化する
Amazon ECR にプッシュされるイメージの暗号化には、カスタマーマネージドキー (CMK) を使用してください。Amazon ECR にプッシュされたイメージは、保存時に AWS Key Management Service (AWS KMS) 管理キーで自動的に暗号化されます。独自のキーを使用したい場合は、Amazon ECR ではカスタマーマネージドキー (CMK) による AWS KMS 暗号化がサポートされています。CMK によるサーバー側の暗号化を有効にする前に、[「保管データ暗号化」](https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html)に関するドキュメントに記載されている考慮事項を確認してください。