AWS CodePipelineのためのアイデンティティおよびアクセス管理 - AWS CodePipeline
対象者アイデンティティを使用した認証ポリシーを使用したアクセスの管理CodePipeline サービスロールを管理する

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

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

AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を 認証 (サインイン) し、誰に CodePipeline リソースの使用を 承認する (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで AWS のサービス 使用できる です。

トピック

対象者

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

[Service user] (サービスユーザー) - CodePipeline サービスを使用してジョブを実行する場合は、必要なアクセス許可と認証情報を管理者が用意します。さらに多くの CodePipeline 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者に適切なアクセス許可をリクエストするのに役に立ちます。CodePipeline の機能にアクセスできない場合は、AWS CodePipeline ID とアクセスのトラブルシューティング を参照してください。

サービス管理者 - 社内の CodePipeline リソースを担当している場合は、通常、CodePipeline へのフルアクセスがあります。サービスのユーザーが CodePipeline のどの機能やリソースにアクセスするかを決めるのは管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。会社で CodePipeline を使用して IAM を利用する方法の詳細については、と IAM の AWS CodePipeline 連携方法 を参照してください。

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

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

認証とは、ID 認証情報 AWS を使用して にサインインする方法です。として、IAM ユーザーとして AWS アカウントのルートユーザー、または IAM ロールを引き受けて認証 （サインイン AWS) される必要があります。

ID ソースを介して提供された認証情報を使用して、フェデレーティッド ID AWS として にサインインできます。 AWS IAM Identity Center （IAM Identity Center) ユーザー、会社のシングルサインオン認証、Google または Facebook 認証情報は、フェデレーティッド ID の例です。フェデレーティッド ID としてサインインする場合、IAM ロールを使用して、前もって管理者により ID フェデレーションが設定されています。フェデレーション AWS を使用して にアクセスすると、間接的にロールを引き受けます。

ユーザーのタイプに応じて、 AWS Management Console または AWS アクセスポータルにサインインできます。へのサインインの詳細については AWS、「 ユーザーガイド」の「 にサインインする方法 AWS アカウント」を参照してください。 AWS サインイン

AWS プログラムで にアクセスする場合、 は Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) AWS を提供し、認証情報を使用してリクエストに暗号で署名します。 AWS ツールを使用しない場合は、自分でリクエストに署名する必要があります。リクエストに自分で署名する推奨方法の使用の詳細については、「IAM ユーザーガイド」の「API リクエストに対するAWS Signature Version 4」を参照してください。

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

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

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

IAM ユーザーとグループ

IAM ユーザーは、単一のユーザーまたはアプリケーションに特定のアクセス許可 AWS アカウント を持つ 内のアイデンティティです。可能であれば、パスワードやアクセスキーなどの長期的な認証情報を保有する IAM ユーザーを作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、IAM ユーザーでの長期的な認証情報が必要な特定のユースケースがある場合は、アクセスキーをローテーションすることをお勧めします。詳細については、「IAM ユーザーガイド」の「長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションする」を参照してください。

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

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

IAM ロール

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

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

  • フェデレーションユーザーアクセス – フェデレーティッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーティッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションのロールについては、「IAM ユーザーガイド」の「サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する」を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「AWS IAM Identity Center User Guide」の「Permission sets」を参照してください。

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

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

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

    • 転送アクセスセッション (FAS) – IAM ユーザーまたはロールを使用してアクションを実行すると AWS、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストのリクエストリクエストを使用します。FAS リクエストは、サービスが他の AWS のサービス またはリソースとのやり取りを完了する必要があるリクエストを受け取った場合にのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「転送アクセスセッション」を参照してください。

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

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

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

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

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

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

デフォルトでは、ユーザーやロールに権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに 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 エンティティのアクセス許可の境界」を参照してください。

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

  • リソースコントロールポリシー (RCP) – RCP は、所有する各リソースにアタッチされた IAM ポリシーを更新することなく、アカウント内のリソースに利用可能な最大数のアクセス許可を設定するために使用できる JSON ポリシーです。RCP は、メンバーアカウントのリソースのアクセス許可を制限し、組織に属しているかどうかにかかわらず AWS アカウントのルートユーザー、 を含む ID の有効なアクセス許可に影響を与える可能性があります。RCP をサポートする のリストを含む Organizations と RCP の詳細については、AWS Organizations RCPs「リソースコントロールポリシー (RCPs」を参照してください。 AWS のサービス

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

CodePipeline サービスロールを管理する

CodePipeline サービスロールには、パイプラインで使用される AWS リソースへのアクセスを制御する 1 つ以上のポリシーが設定されています。このロールにさらにポリシーをアタッチしたり、ロールにアタッチされたポリシーを編集したり、 で他のサービスロールのポリシーを設定したりできます 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 のサポート日付
Amazon Elastic Container Registry ECRBuildAndPublishAction アクション 2024 年 11 月 22 日
Amazon Inspector InspectorScanアクション 2024 年 11 月 22 日
コマンドアクション 2024 年 10 月 3 日
AWS CloudFormation 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 日
Service Catalog 2018 年 10 月 16 日
AWS Device Farm 2018 年 7 月 19 日
Amazon ECS 2017 年 12 月 12 日 / 2017 年 7 月 21 日から開始されたタグ付け承認のオプトインのための更新
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 し、https://console.aws.amazon.com/iam/ で 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:DescribeStackEvents",
        "cloudformation:DescribeStacks",
        "cloudformation:UpdateStack",
        "cloudformation:CreateChangeSet",
        "cloudformation:DeleteChangeSet",
        "cloudformation:DescribeChangeSet",
        "cloudformation:ExecuteChangeSet",
        "cloudformation:SetStackPolicy",
        "cloudformation:ValidateTemplate",
        "iam:PassRole"
    ],
    "Resource": "resource_ARN"
},

    cloudformation:DescribeStackEvents アクセス許可はオプションであることに注意してください。これにより、 AWS CloudFormation アクションはより詳細なエラーメッセージを表示できます。パイプラインのエラーメッセージにリソースの詳細を表示したくない場合は、このアクセス許可を IAM ロールから取り消すことができます。詳細については、「AWS CloudFormation デプロイアクションリファレンス」を参照してください。

    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"
},

    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:TagResource",
        "ecs:UpdateService"
    ],
    "Resource": "resource_ARN"
},

    Amazon ECS でタグ付け承認の使用をオプトインできます。オプトインする場合、ecs:TagResource というアクセス許可を付与する必要があります。オプトインの方法、必要になるアクセス許可、タグ付け承認の詳細については、Amazon Elastic Container Service 開発者ガイドの「タグ付け承認のタイムライン」を参照してください。

    また、タスクに 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",
        "ecs:TagResource"
    ],
    "Resource": "resource_ARN"
},

    Amazon ECS でタグ付け承認の使用をオプトインできます。オプトインする場合、ecs:TagResource というアクセス許可を付与する必要があります。オプトインの方法、必要になるアクセス許可、タグ付け承認の詳細については、Amazon Elastic Container Service 開発者ガイドの「タグ付け承認のタイムライン」を参照してください。

    また、タスクに 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.com を iam: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 Cloud などの接続を使用するソースでパイプラインを作成するには、次のアクセス許可が必要です。

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

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

  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 ソースで完全クローンオプションを使用できるようにするには、プロジェクトの CodeBuild サービスロールのポリシーステートメントに対する codecommit:GitPull アクセス許可を追加する必要があります。

  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. CloudWatch Logs 用に設定するパイプラインの場合、CodePipeline サービスロールに追加する必要がある最小限のアクセス許可は以下のとおりです。

    {
    "Effect": "Allow",
    "Action": [
        "logs:DescribeLogGroups",
        "logs:PutRetentionPolicy"
    ],
    "Resource": "resource_ARN"
},
    注記

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

  16. コマンドアクションのサポートについては、以下をポリシーステートメントに追加します。

    {
    "Effect": "Allow",
    "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
    ],
    "Resource": [
        "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME",
        "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*"
   ]
}
    注記

    サービスロールポリシーステートメントでリソースベースのアクセス許可を使用して、アクセス許可の範囲をパイプラインリソースレベルに絞り込みます。詳細については、「サービスロールのポリシーのアクセス許可」のポリシー例を参照してください。

  17. ECRBuildAndPublish アクションをサポートするには、ポリシーステートメントに以下を追加します。

    {
    "Statement": [
         {
            "Sid": "ECRRepositoryAllResourcePolicy",
            "Effect": "Allow",
            "Action": [
                "ecr:DescribeRepositories",
                "ecr:GetAuthorizationToken",
                "ecr-public:DescribeRepositories",
                "ecr-public:GetAuthorizationToken"
            ],
        "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchCheckLayerAvailability"
            ],
            "Resource": "PrivateECR_Resource_ARN"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ecr-public:GetAuthorizationToken",
                "ecr-public:DescribeRepositories",
                "ecr-public:InitiateLayerUpload",
                "ecr-public:UploadLayerPart",
                "ecr-public:CompleteLayerUpload",
                "ecr-public:PutImage",
                "ecr-public:BatchCheckLayerAvailability",
                "sts:GetServiceBearerToken"
            ],
            "Resource": "PublicECR_Resource_ARN"
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:GetServiceBearerToken"
            ],
            "Resource": "*"
        }
    ]
}

    さらに、 コマンドアクションにまだ追加されていない場合は、CloudWatch ログを表示するために、サービスロールに次のアクセス許可を追加します。

    {
    "Effect": "Allow",
    "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream", 
        "logs:PutLogEvents"
    ],
    "Resource": "resource_ARN"
},
    注記

    サービスロールポリシーステートメントでリソースベースのアクセス許可を使用して、アクセス許可の範囲をパイプラインリソースレベルに絞り込みます。

  18. InspectorScan アクションをサポートするには、ポリシーステートメントに以下を追加します。

    {
        "Effect": "Allow",
        "Action": "inspector-scan:ScanSbom",
        "Resource": "*"
    },
    {
        "Effect": "Allow",
        "Action": [
            "ecr:GetDownloadUrlForLayer",
            "ecr:BatchGetImage",
            "ecr:BatchCheckLayerAvailability"
        ],
        "Resource": "resource_ARN"
    },

    さらに、 コマンドアクションにまだ追加されていない場合は、CloudWatch ログを表示するために、サービスロールに次のアクセス許可を追加します。

    {
    "Effect": "Allow",
    "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream", 
        "logs:PutLogEvents"
    ],
    "Resource": "resource_ARN"
},
    注記

    サービスロールポリシーステートメントでリソースベースのアクセス許可を使用して、アクセス許可の範囲をパイプラインリソースレベルに絞り込みます。

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