AWS CodePipeline の Identity and Access Management - AWS CodePipeline

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

AWS CodePipeline の Identity and Access Management

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

Audience

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

サービスユーザー— CodePipeline サービスを使用してジョブを実行する場合は、必要なアクセス許可と認証情報を管理者が用意します。作業を実行するためにさらに多くの CodePipeline 機能を使用するにつれて、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。CodePipeline の機能にアクセスできない場合は、AWS CodePipeline Identity and Access のトラブルシューティング

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

IAM 管理者IAM 管理者の場合は、CodePipeline へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。IAM で使用できる CodePipeline アイデンティティベースのポリシーの例を表示するには、を参照してください。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 のサービスとリソースに対して完全なアクセス権限を持つシングルサインインアイデンティティで始めます。このアイデンティティは AWS アカウント ルートユーザーと呼ばれ、アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことです。代わりに、最初の IAM ユーザーを作成するためにのみ、ルートユーザーを使用するというベストプラクティスに従います。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。

IAM ユーザーとグループ

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

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

ユーザーは、ロールとは異なります。ユーザーは 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、エンタープライズユーザーディレクトリ、またはウェブ ID プロバイダーからの既存のアイデンティティを使用できます。このようなユーザーはフェデレーティッドユーザーと呼ばれます。AWS では、ID プロバイダーを通じてアクセスがリクエストされたとき、フェデレーティッドユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、IAM ユーザーガイドフェデレーティッドユーザーとロールを参照してください。

  • クロスアカウントアクセス – 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 ユーザーの作成が適している場合 (ロールではなく)」を参照してください。

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

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

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

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

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

ID ベースのポリシー

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

アイデンティティベースのポリシーは、さらにインラインポリシーまたは管理ポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、スタンドアロンポリシーです。このポリシーは、 AWS アカウント 。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。管理ポリシーまたはインラインポリシーのいずれかを選択する方法については、IAM ユーザーガイド管理ポリシーとインラインポリシーの比較を参照してください。

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

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

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

その他のポリシータイプ

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

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

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

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

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

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

重要

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

注記

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

2018 年 9 月以降に作成されたサービスロールは、サービスロール名の形式 AWSCodePipelineServiceRole-Region-Pipeline_Name を使用します。たとえば、という名前のパイプラインに対してMyFirstPipelineeu-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 CloudFormationStackSets アクション 2020 年 12 月 30 日
CodeCommit 完全クローン出力アーティファクト形式 2020 年 11 月 11 日
CodeBuild ing バッチビルド 2020 年 7 月 30 日
AWS AppConfig 2020 年 6 月 22 日
AWS Step Functions 2020 年 5 月 27 日
AWS CodeStar Connections 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. 必要なアクセス許可をポリシードキュメントボックスに移動するとそのように表示されます。

    注記

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

    たとえば、CodeCommit がサポートされるように、以下をポリシーステートメントに追加します。

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

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

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

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

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

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

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

    バッチビルドSupport されるように、後日追加されました。バッチビルドのサービスロールに追加するアクセス許可については、ステップ 11 を参照してください。

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

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

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

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

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

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

    また、追加する必要がありますiam:PassRoleタスク用の IAM ロールを使用するには、アクセス許可が必要です。詳細については、「」を参照してください。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アクション (青/緑のデプロイ) では、CodeDeploy to Amazon ECS Blue/Green デプロイアクションを持つパイプラインを作成するために必要な最低限のアクセス許可は以下のとおりです。

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

    また、追加する必要がありますのiam:PassRoleタスク用の IAM ロールを使用するには、アクセス許可が必要です。詳細については、「」を参照してください。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": [ { "Action": [ "iam:PassRole" ], "Resource": "*", "Effect": "Allow", "Condition": { "StringEqualsIfExists": { "iam:PassedToService": [ "cloudformation.amazonaws.com", "elasticbeanstalk.amazonaws.com", "ec2.amazonaws.com", "ecs-tasks.amazonaws.com" ] } } },
  8. AWS CodeStar 接続の場合、Bitbucket などの接続を使用するソースとのパイプラインを作成するには、次のアクセス許可が必要です。

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

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

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

    { "Action": [ "states:DescribeStateMachine", "states:DescribeExecution", "states:StartExecution" ], "Resource": "*", "Effect": "Allow" },
  10. 向けのAppConfigアクションでは、以下がパイプラインの作成に必要な最小限のアクセス許可です。AWSAppConfig はアクションを呼び出します。

    { "Action": [ "appconfig:StartDeployment", "appconfig:GetDeployment", "appconfig:StopDeployment" ], "Resource": "*", "Effect": "Allow" },
  11. バッチビルドのCodeBuild がサポートされるように、以下をポリシーステートメントに追加します。

    { "Action": [ "codebuild:BatchGetBuildBatches", "codebuild:StartBuildBatch" ], "Resource": "*", "Effect": "Allow" },
  12. を使用する場合AWS CloudFormationStackSets アクションを使用するには、以下の最小権限が必要です。

    • 向けのCloudFormationStackSetアクションを実行するには、以下をポリシーステートメントに追加します。

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

      { "Action": [ "cloudformation:CreateStackInstances", "cloudformation:DescribeStackSetOperation" ], "Resource": "*", "Effect": "Allow" },
  13. フルクローンオプションの CodeCommit がサポートされるように、以下をポリシーステートメントに追加します。

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

    CodeBuild アクションが CodeCommit ソースで完全クローンオプションを使用できるようにするには、codecommit:GitPull 権限をプロジェクトの CodeBuild サービスロールのポリシーステートメントに追加します。

  14. Elastic Beanstalk では、ElasticBeanstalkデプロイアクション。

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

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

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