AWS CodePipeline のためのアイデンティティおよびアクセス管理 - AWS CodePipeline

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

AWS CodePipeline のためのアイデンティティおよびアクセス管理

AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービス です。IAM 管理者は誰ができるかをコントロールします認証済み(サインイン) と認可使用する (権限を持っている) CodePipeline リソースの料金を見積もることができます。IAM は、追加費用なしで使用できる AWS のサービス です。

対象者

AWS Identity and Access Management (IAM) の用途は、 CodePipeline で行う作業によって異なります。

サービスユーザー—... を使用した場合 CodePipeline サービスを実行し、必要なアクセス許可と認証情報を管理者が用意します。もっと使うにつれて CodePipeline 機能作業を実行するには、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解しておくと、管理者に適切な許可をリクエストするうえで役立ちます。 CodePipeline の特徴にアクセスできない場合は、「AWS CodePipeline アイデンティティとアクセスに関するトラブルシューティング」を参照してください。

サービス管理者— あなたが担当している場合 CodePipeline 社内リソースは、おそらくへのフルアクセスがあります CodePipeline。どちらを決定するのは管理者の仕事です CodePipeline サービスユーザーがアクセスする必要がある機能およびリソース。その後、IAM 管理者にリクエストを送信して、サービスユーザーの許可を変更する必要があります。このページの情報を確認して、IAM の基本概念を理解してください。お客様の会社で IAM を利用する方法の詳細については CodePipeline、を参照してくださいAWS CodePipeline と IAM の連携について

IAM 管理者 - 管理者は、 CodePipeline へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。例を表示するには CodePipeline IAM で使用できる ID ベースのポリシー。を参照してください。AWS CodePipeline アイデンティティベースポリシーの例

アイデンティティを使用した認証

認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。AWS Management Console を使用したサインインの詳細については、「IAM ユーザーガイド」の「IAM ユーザーまたはルートユーザーとして AWS Management Console にサインインする」を参照してください。

ユーザーは AWS のルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、認証を受ける (AWS アカウント にサインインする) 必要があります。会社のシングルサインオン認証を使用したり、Google や Facebook を使用したりしてサインインすることもできます。このような場合、管理者が事前に IAM ロールを使用して ID フェデレーションを設定している必要があります。他の会社の認証情報を使用して AWS にアクセスした場合、ロールは間接的に割り当てられています。

AWS Management Console に直接サインインするには、パスワードとルートユーザーの E メールまたは IAM ユーザー名を使用します。ルートユーザーまたは IAM ユーザーのアクセスキーを使用して AWS にプログラムからアクセスできます。AWS では、ユーザーの認証情報を使用してリクエストに暗号的に署名するための SDK とコマンドラインツールが提供されます。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。これには、インバウンド API リクエストを認証するためのプロトコルである署名バージョン 4 を使用します。リクエストの認証の詳細については、「AWS 全般のリファレンス」の「署名バージョン 4 の署名プロセス」を参照してください。

使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。例えば、AWS は、アカウントのセキュリティを強化するために多要素認証 (MFA) を使用することをお勧めします。詳細については、「IAM ユーザーガイド」の「AWS での多要素認証 (MFA) の使用」を参照してください。

AWS アカウント ルートユーザー

AWS アカウント を作成する場合は、このアカウントのすべての AWS のサービス とリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。この ID は AWS アカウント ルートユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインすることによってアクセスできます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザーの認証情報を保護し、それらを使用してルートユーザーのみが実行できるタスクを実行します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、AWS 全般のリファレンスの「ルートユーザー認証情報が必要なタスク」を参照してください。

IAM ユーザーとグループ

IAM ユーザーは、1 人のユーザーまたは 1 つのアプリケーションに対して特定の許可を持つ AWS アカウント 内のアイデンティティです。IAM ユーザーは、ユーザー名とパスワード、アクセスキーのセットなど、長期的な認証情報を持つことができます。アクセスキーの生成方法の詳細については、「IAM ユーザーガイド」の「IAM ユーザーのアクセスキーの管理」を参照してください。IAM ユーザーにアクセスキーを生成する際は、必ずキーペアを表示して安全に保存してください。後になって、シークレットアクセスキーを回復することはできません。新しいアクセスキーペアを生成する必要があります。

IAM グループは、IAM ユーザーの集団を指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に許可を指定できます。多数のユーザーグループがある場合、グループを使用することで許可の管理が容易になります。例えば、IAMAdmins という名前のグループを設定して、そのグループに IAM リソースを管理する許可を与えることができます。

ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時的な認証情報が提供されます。詳細については、「IAM ユーザーガイド」の「IAM ユーザー (ロールではなく) の作成が適している場合」を参照してください。

IAM ロール

IAM ロールは、特定の許可を持つ、AWS アカウント 内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーには関連付けられていません。ロールを切り替えることによって、AWS Management Console で IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「IAM ユーザーガイド」の「IAM ロールの使用」を参照してください。

IAM ロールと一時的な認証情報は、次の状況で役立ちます。

  • 一時的な IAM ユーザー許可 - IAM ユーザーは、特定のタスクに対して複数の異なる許可を一時的に IAM ロールで引き受けることができます。

  • フェデレーションユーザーアクセス - IAM ユーザーを作成する代わりに、AWS Directory Service、エンタープライズユーザーディレクトリ、ウェブアイデンティティプロバイダー、IAM アイデンティティセンターのアイデンティティストアのいずれから既存のアイデンティティを使用できます。これらのアイデンティティは「フェデレーテッドアイデンティティ」と呼ばれます。フェデレーテッドアイデンティティに許可を割り当てるには、ロールを作成してそのロールの許可を定義できます。外部アイデンティティが認証されると、そのアイデンティティはロールに関連付けられ、ロールで定義されている許可が付与されます。IAM アイデンティティセンターを使用する場合、許可セットを設定します。IAM アイデンティティセンターは、許可セットを IAM のロールに関連付けて、アイデンティティが認証後にアクセスできるものを制御します。ID フェデレーションの詳細については、「IAM ユーザーガイド」の「Creating a role for a third-party Identity Provider」(サードパーティーアイデンティティプロバイダー向けロールの作成) を参照してください。IAM Identity Center の詳細については、「AWS IAM Identity Center (successor to AWS Single Sign-On) ユーザーガイド」の「What is IAM Identity Center?」(IAM Identity Center とは) を参照してください。

  • クロスアカウントアクセス - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の AWS のサービス では、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接添付できます。クロスアカウントアクセスにおけるロールとリソースベースのポリシーの違いについては、「IAM ユーザーガイド」の「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

  • クロスサービスアクセス - 一部の AWS のサービス では、他の AWS のサービス の機能を使用します。例えば、サービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスでは、呼び出し元プリンシパルの許可、サービスロール、またはサービスにリンクされたロールを使用してこれを行う場合があります。

    • プリンシパル許可 - IAM ユーザーまたはロールを使用して AWS でアクションを実行する場合、そのユーザーはプリンシパルとみなされます。ポリシーによって、プリンシパルに許可が付与されます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。この場合、両方のアクションを実行するための許可が必要です。アクションがポリシーで追加の依存アクションを必要とするかどうかを確認するには、サービス認証リファレンスの「AWS CodePipeline のアクション、リソース、および条件キー」をご参照ください。

    • サービスロール - サービスがユーザーに代わってアクションを実行するために引き受ける IAM ロールです。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイドの「AWS のサービス に許可を委任するロールの作成」を参照してください。

    • サービスにリンクされたロール - サービスにリンクされたロールは、AWS のサービス にリンクされたサービスロールの一種です。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールの許可を表示できますが、編集することはできません。

  • Amazon EC2 で実行されているアプリケーション - EC2 インスタンスで実行され、AWS CLI または AWS API 要求を行っているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得することができます。詳細については、「IAM ユーザーガイド」の「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する」を参照してください。

IAM ロールと IAM ユーザーのどちらを使用するかについては、「IAM ユーザーガイド」の「(IAM ユーザーではなく) IAM ロールをいつ作成したら良いのか?」を参照してください。

ポリシーを使用したアクセスの管理

AWS でアクセスをコントロールするには、ポリシーを作成して AWS アイデンティティまたはリソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うと、これらのポリシーを評価します。ポリシーでの許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「IAM ユーザーガイド」の「JSON ポリシー概要」を参照してください。

管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

すべての IAM エンティティ (ユーザーまたはロール) は、許可のない状態からスタートします。デフォルトでは、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行する許可をユーザーに付与するには、管理者がユーザーに許可ポリシーを添付する必要があります。また、管理者は、必要な許可があるグループにユーザーを追加できます。管理者がグループに許可を付与すると、そのグループ内のすべてのユーザーにこれらの許可が付与されます。

IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、iam:GetRole アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS Management Console、AWS CLI、または AWS API からロールの情報を取得できます。

アイデンティティベースのポリシー

アイデンティティベースポリシーは、IAM ユーザー、ユーザーのグループ、ロールなど、アイデンティティに添付できる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「IAM ポリシーの作成」を参照してください。

アイデンティティベースのポリシーは、さらにインラインポリシーまたはマネージドポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれます。マネージドポリシーは、AWS アカウント 内の複数のユーザー、グループ、およびロールに添付できるスタンドアロンポリシーです。マネージドポリシーには、AWS マネージドポリシーとカスタマーマネージドポリシーがあります。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、「IAM ユーザーガイド」の「マネージドポリシーとインラインポリシーの比較」を参照してください。

リソースベースのポリシー

リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM ロールの信頼ポリシーや Amazon S3 バケットポリシーがあげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。ポリシーが添付されているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービス を含めることができます。

リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS マネージドポリシーを使用することはできません。

その他のポリシータイプ

AWS では、その他の一般的ではないポリシータイプもサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の許可を設定できます。

  • 許可の境界 - 許可の境界は、アイデンティティベースのポリシーによって IAM エンティティ (IAM ユーザーまたはロール) に付与できる許可の上限を設定する高度な機能です。エンティティに許可の境界を設定できます。結果として許可される範囲は、エンティティのアイデンティティベースポリシーとその許可の境界の共通部分になります。Principal フィールドでユーザーまたはロールを指定するリソースベースのポリシーでは、許可の境界は制限されません。これらのポリシーのいずれかを明示的に拒否した場合、許可は無効になります。許可の境界の詳細については、「IAM ユーザーガイド」の「IAM エンティティの許可の境界」を参照してください。

  • サービスコントロールポリシー (SCP) - SCP は、AWS Organizations で組織や組織単位 (OU) の最大許可を指定する JSON ポリシーです。AWS Organizations は、お客様のビジネスが所有する複数の AWS アカウント をグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP ではメンバーアカウントのエンティティ (各 AWS アカウント ルートユーザーなど) に対する許可が制限されます。Organizations と SCP の詳細については、AWS Organizations ユーザーガイドの「SCP の仕組み」を参照してください。

  • セッションポリシー - セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果としてセッションの許可される範囲は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分になります。また、リソースベースのポリシーから許可が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、許可は無効になります。詳細については、IAM ユーザーガイドの「セッションポリシー」を参照してください。

の管理 CodePipeline サービスロール

- CodePipeline サービスロールは、へのアクセスをコントロールする 1 つ以上のポリシーで設定されていますAWSパイプラインが使用するリソース。このロールにさらにポリシーをアタッチする、ロールにアタッチされているポリシーを編集する、または AWS の他のサービスロールのポリシーを設定することができます。また、パイプラインへクロスアカウントアクセスを設定する際に、ポリシーをロールにアタッチすることもできます。

重要

ポリシーステートメントを変更するか、他のポリシーをロールにアタッチすると、パイプラインの動作が停止することがあります。のサービスロールは、必ず影響を理解した上で変更するようにしてください。 CodePipeline どんな方法でも。パイプラインは、必ずサービスロールに変更を加えてからテストします。

注記

コンソールでは、2018 年 9 月より前に作成されたサービスロールは、oneClick_AWS-CodePipeline-Service_ID-Number という名前で作成されています。

2018 年 9 月以降に作成されたサービスロールは、サービスロール名の形式 AWSCodePipelineServiceRole-Region-Pipeline_Name を使用します。例えば、MyFirstPipeline という名前のパイプラインが eu-west-2 にある場合、コンソールはロールとポリシー AWSCodePipelineServiceRole-eu-west-2-MyFirstPipeline の名前を付けます。

CodePipeline サービスロールからアクセス許可を削除する

サービスロールのステートメントを編集して、使用していないリソースへのアクセスを削除します。例えば、いずれのパイプラインにも Elastic Beanstalk が含まれていない場合は、ポリシーステートメントを編集して Elastic Beanstalk リソースへのアクセスを許可するセクションを削除できます。

同様に、どのパイプラインにも含まれていない場合 CodeDeploy、ポリシーステートメントを編集して、アクセスを許可するセクションを削除できます CodeDeploy リソース:

{ "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetApplicationRevision", "codedeploy:GetDeployment", "codedeploy:GetDeploymentConfig", "codedeploy:RegisterApplicationRevision" ], "Resource": "*", "Effect": "Allow" },

CodePipeline サービスロールにアクセス許可を追加する

サービスロールのポリシーステートメントは、パイプラインで使用する前に、デフォルトのサービスロールのポリシーステートメントに含まれていない AWS サービスのアクセス許可で更新する必要があります。

これは、パイプラインで使用しているサービスロールが、サポートが追加される前に作成された場合に特に重要です。 CodePipeline 男性用AWSのサービス。

以下のテーブルは、他の AWS サービスにサポートが追加された場合の例を示しています。

AWS のサービス CodePipeline Support 日
AWS CloudFormation StackSets 行動 2020 年 12 月 30 日
CodeCommit フルクローン出力アーティファクト形式 2020 年 11 月 11 日
CodeBuild バッチビルド 2020 年 7 月 30 日
AWS AppConfig 2020年6月22日
AWS Step Functions 2020 年 5 月 27 日
AWS CodeStar 接続 2019 年 12 月 18 日
CodeDeployToECS アクション 2018 年 11 月 27 日
Amazon ECR 2018 年 11 月 27 日
AWS Service Catalog 2018 年 10 月 16 日
AWS Device Farm 2018 年 7 月 19 日
Amazon ECS 2017 年 12 月 12 日
CodeCommit 2016 年 4 月 18 日
AWS OpsWorks 2016 年 6 月 2 日
AWS CloudFormation 2016 年 11 月 3 日
AWS CodeBuild 2016 年 12 月 1 日
Elastic Beanstalk 初回サービスの起動

サポートされているサービスのアクセス許可を追加するには、次の手順に従います。

  1. AWS Management Console にサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. IAM コンソールのナビゲーションペインで、[ロール] を選択し、ロールのリストから AWS-CodePipeline-Service ロール を選択します。

  3. [アクセス権限] タブの [インラインポリシー] で、サービスロールポリシーの列の [ポリシーの編集] を選択します。

  4. [Policy Document] ボックスに必要なアクセス許可を追加します。

    注記

    IAM ポリシーを作成するとき、最小限の特権を認めるという標準的なセキュリティアドバイスに従いましょう。そうすれば、タスクを実行するというリクエストのアクセス許可のみを認めることができます。一部の API コールはリソースベースのアクセス許可をサポートしており、アクセスを制限できます。たとえば、この場合、DescribeTasks および ListTasks を呼び出す際のアクセス許可を制限するために、ワイルドカード文字 (*) をリソース ARN またはワイルドカード文字 (*) を含むリソース ARN に置き換えることができます。最小権限アクセスを付与するポリシーの作成の詳細については、https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege を参照してください。

    たとえば、のを設定します。 CodeCommit サポート、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "codecommit:GetBranch", "codecommit:GetCommit", "codecommit:UploadArchive", "codecommit:GetUploadArchiveStatus", "codecommit:CancelUploadArchive" ], "Resource": "resource_ARN" },

    AWS OpsWorks がサポートされるように、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "opsworks:CreateDeployment", "opsworks:DescribeApps", "opsworks:DescribeCommands", "opsworks:DescribeDeployments", "opsworks:DescribeInstances", "opsworks:DescribeStacks", "opsworks:UpdateApp", "opsworks:UpdateStack" ], "Resource": "resource_ARN" },

    AWS CloudFormation がサポートされるように、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "cloudformation:CreateStack", "cloudformation:DeleteStack", "cloudformation:DescribeStacks", "cloudformation:UpdateStack", "cloudformation:CreateChangeSet", "cloudformation:DeleteChangeSet", "cloudformation:DescribeChangeSet", "cloudformation:ExecuteChangeSet", "cloudformation:SetStackPolicy", "cloudformation:ValidateTemplate", "iam:PassRole" ], "Resource": "resource_ARN" },

    にとって CodeBuild サポート、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "codebuild:BatchGetBuilds", "codebuild:StartBuild" ], "Resource": "resource_ARN" },
    注記

    バッチビルド対応が後日追加されました。バッチビルドのサービスロールに追加する権限については、手順 11 を参照してください。

    AWS Device Farm がサポートされるように、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "devicefarm:ListProjects", "devicefarm:ListDevicePools", "devicefarm:GetRun", "devicefarm:GetUpload", "devicefarm:CreateUpload", "devicefarm:ScheduleRun" ], "Resource": "resource_ARN" },

    AWS Service Catalog がサポートされるように、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "servicecatalog:ListProvisioningArtifacts", "servicecatalog:CreateProvisioningArtifact", "servicecatalog:DescribeProvisioningArtifact", "servicecatalog:DeleteProvisioningArtifact", "servicecatalog:UpdateProduct" ], "Resource": "resource_ARN" }, { "Effect": "Allow", "Action": [ "cloudformation:ValidateTemplate" ], "Resource": "resource_ARN" }
  5. Amazon ECR がサポートされるように、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "ecr:DescribeImages" ], "Resource": "resource_ARN" },
  6. Amazon ECS では、Amazon ECS デプロイアクションを使用してパイプラインを作成するために必要な最小限のアクセス権限は次のとおりです。

    { "Effect": "Allow", "Action": [ "ecs:DescribeServices", "ecs:DescribeTaskDefinition", "ecs:DescribeTasks", "ecs:ListTasks", "ecs:RegisterTaskDefinition", "ecs:UpdateService" ], "Resource": "resource_ARN" },

    また、タスクに IAMロールを使用するための iam:PassRole アクセス許可を追加する必要があります。詳細については、「Amazon ECS タスク実行 IAM ロールそしてタスクの IAM ロール」を参照してください。以下のポリシーテキストを使用します。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": [ "arn:aws:iam::aws_account_ID:role/ecsTaskExecutionRole_or_TaskRole_name" ] } ] }
  7. 向けのCodeDeployToECSアクション (Blue/Green デプロイメント)、を使用してパイプラインを作成するために必要な最小限のアクセス許可は次のとおりです CodeDeploy Amazon ECS Blue/Green デプロイアクションへ。

    { "Effect": "Allow", "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetDeployment", "codedeploy:GetApplication", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:GetDeploymentConfig", "ecs:RegisterTaskDefinition" ], "Resource": "resource_ARN" },

    また、タスクに IAMロールを使用するための iam:PassRole アクセス許可を追加する必要があります。詳細については、「Amazon ECS タスク実行 IAM ロールそしてタスクの IAM ロール」を参照してください。以下のポリシーテキストを使用します。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": [ "arn:aws:iam::aws_account_ID:role/ecsTaskExecutionRole_or_TaskRole_name" ] } ] }

    この例に示すように、ecs-tasks.amazonaws.comiam:PassedToService 条件下のサービスのリストへ追加することができます。

    { "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "resource_ARN", "Condition": { "StringEqualsIfExists": { "iam:PassedToService": [ "cloudformation.amazonaws.com", "elasticbeanstalk.amazonaws.com", "ec2.amazonaws.com", "ecs-tasks.amazonaws.com" ] } } },
  8. AWS の場合 CodeStar 接続。Bitbucket などの接続を使用するソースとのパイプラインを作成するには、次のアクセス許可が必要です。

    { "Effect": "Allow", "Action": [ "codestar-connections:UseConnection" ], "Resource": "resource_ARN" },

    接続に関する IAM アクセス許可の詳細については、「接続のアクセス許可のリファレンス」を参照してください。

  9. StepFunctions アクションでは、Step Functions 呼び出しアクションを使用してパイプラインを作成するために必要な最小限のアクセス許可は次のとおりです。

    { "Effect": "Allow", "Action": [ "states:DescribeStateMachine", "states:DescribeExecution", "states:StartExecution" ], "Resource": "resource_ARN" },
  10. 向けのAppConfigアクションでは、を使用してパイプラインを作成するために必要な最小限のアクセス許可は次のとおりですAWS AppConfig アクションを呼び出します。

    { "Effect": "Allow", "Action": [ "appconfig:StartDeployment", "appconfig:GetDeployment", "appconfig:StopDeployment" ], "Resource": "resource_ARN" },
  11. にとって CodeBuild バッチビルドへ対応については、以下をポリシーステートメントに追加します。

    { "Effect": "Allow", "Action": [ "codebuild:BatchGetBuildBatches", "codebuild:StartBuildBatch" ], "Resource": "resource_ARN" },
  12. にとってAWS CloudFormation StackSets アクションの場合、以下の最小権限が必要です。

    • CloudFormationStackSet のアクションについては、以下をポリシーステートメントに追加します。

      { "Effect": "Allow", "Action": [ "cloudformation:CreateStackSet", "cloudformation:UpdateStackSet", "cloudformation:CreateStackInstances", "cloudformation:DescribeStackSetOperation", "cloudformation:DescribeStackSet", "cloudformation:ListStackInstances" ], "Resource": "resource_ARN" },
    • CloudFormationStackInstances のアクションについては、以下をポリシーステートメントに追加します。

      { "Effect": "Allow", "Action": [ "cloudformation:CreateStackInstances", "cloudformation:DescribeStackSetOperation" ], "Resource": "resource_ARN" },
  13. にとって CodeCommit フルクローンオプションへ対応については、ポリシーステートメントに以下を追加してください。

    { "Effect": "Allow", "Action": [ "codecommit:GetRepository" ], "Resource": "resource_ARN" },
    注記

    確認するには CodeBuild アクションは、[完全クローン] オプションを使用できます。 CodeCommit ソース、も追加する必要がありますcodecommit:GitPullプロジェクトのポリシーステートメントへの許可 CodeBuild サービスロール。

  14. Elastic Beanstalk では、ElasticBeanstalk デプロイアクションを使用してパイプラインを作成するために必要な最小限のアクセス許可は次のとおりです。

    { "Effect": "Allow", "Action": [ "elasticbeanstalk:*", "ec2:*", "elasticloadbalancing:*", "autoscaling:*", "cloudwatch:*", "s3:*", "sns:*", "cloudformation:*", "rds:*", "sqs:*", "ecs:*" ], "Resource": "resource_ARN" },
    注記

    リソースポリシーのワイルドカードは、アクセスを制限するアカウントのリソースに置き換える必要があります。最小権限アクセスを付与するポリシーの作成の詳細については、https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege を参照してください。

  15. [Review policy] (ポリシーの確認) を選択して、ポリシーにエラーがないことを確認します。ポリシーにエラーがなければ、ポリシーの適用 を選択します。