翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS CodePipeline アイデンティティベースポリシーの例
デフォルトでは、IAMユーザーとロールには CodePipeline リソースを作成または変更するアクセス許可がありません。また、 AWS Management Console、 AWS CLI、または を使用してタスクを実行することはできません AWS API。IAM 管理者は、ユーザーとロールに必要な特定のリソースに対して特定のAPIオペレーションを実行するアクセス許可を付与するIAMポリシーを作成する必要があります。その後、管理者は、これらのアクセス許可を必要とするIAMユーザーまたはグループにこれらのポリシーをアタッチする必要があります。
これらのポリシードキュメント例を使用して IAM ID ベースのJSONポリシーを作成する方法については、IAM「 ユーザーガイド」のJSON「 タブでのポリシーの作成」を参照してください。
別のアカウントのリソースを使用するパイプラインを作成する方法、および関連するポリシーの例については、「」を参照してください別の AWS アカウントのリソース CodePipeline を使用するパイプラインを に作成する。
トピック
カスタマーマネージドポリシーの例
このセクションでは、さまざまな CodePipeline アクションのアクセス許可を付与するユーザーポリシーの例を確認できます。これらのポリシーは CodePipeline API、、 AWS SDKs、または を使用している場合に機能します AWS CLI。コンソールを使用している場合は、コンソールに固有の追加のアクセス許可を付与する必要があります。詳細については、「 CodePipeline コンソールの使用に必要な許可」を参照してください。
注記
すべての例では、米国西部 (オレゴン) リージョン (us-west-2
) を使用し、架空のアカウント が含まれていますIDs。
例
例 1: パイプラインの状態を取得するアクセス許可を付与する
以下の例では、パイプライン (MyFirstPipeline
) の状態を取得する権限を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipelineState" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline" } ] }
例 2: ステージ間の移行を有効または無効にするアクセス許可を付与する
以下の例では、パイプライン (MyFirstPipeline
) のすべてのステージ間での移行を無効化または有効化するアクセス許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:DisableStageTransition", "codepipeline:EnableStageTransition" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*" } ] }
ユーザーが、パイプラインの 1 つのステージでの移行を無効化または有効化できるようにするには、ステージを指定する必要があります。例えば、ユーザーがパイプライン Staging
のステージ MyFirstPipeline
の移行を有効化または無効化できるようにするには、以下を行います。
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"
例 3: 使用可能なすべてのアクションタイプのリストを取得するアクセス許可を付与する
以下の例では、us-west-2
リージョンのパイプラインで利用できるすべてのアクションの種類のリストを取得するためのアクセス許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:ListActionTypes" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*" } ] }
例 4: 手動の承認アクションを承認または拒否するアクセス許可を付与する
以下の例では、パイプライン MyFirstPipeline
のステージ Staging
で手動の承認アクションを承認または拒否するためのアクセス許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PutApprovalResult" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*" } ] }
例 5: カスタムアクションのジョブをポーリングするアクセス許可を付与する
以下の例では、カスタムアクション TestProvider
のジョブをポーリングするためのアクセス許可を付与します。これは、すべてのパイプラインで最初のバージョンのアクションの種類である Test
です。
注記
カスタムアクションのジョブワーカーは、別の AWS アカウントで設定するか、機能するために特定のIAMロールを必要とする場合があります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForJobs" ], "Resource": [ "arn:aws:codepipeline:us-west-2:111222333444:actionType:
Custom
/Test
/TestProvider
/1
" ] } ] }
例 6: と Jenkins 統合のポリシーをアタッチまたは編集する AWS CodePipeline
Jenkins を使用してビルドまたはテストを行うようにパイプラインを設定する場合は、その統合用に別の ID を作成し、Jenkins と の統合に必要な最小限のアクセス許可を持つIAMポリシーをアタッチします CodePipeline。このポリシーは、AWSCodePipelineCustomActionAccess
マネージドポリシーと同じです。以下の例では、Jenkins との統合で使用するポリシーを示します。
{ "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:AcknowledgeJob", "codepipeline:GetJobDetails", "codepipeline:PollForJobs", "codepipeline:PutJobFailureResult", "codepipeline:PutJobSuccessResult" ], "Resource": "*" } ], "Version": "2012-10-17" }
例 7: パイプラインへのクロスアカウントアクセスを設定する
別の AWS アカウントのユーザーおよびグループのパイプラインへのアクセスを設定できます。推奨される方法は、パイプラインが作成されたアカウントにロールを作成することです。ロールは、他の AWS アカウントのユーザーがそのロールを引き受けてパイプラインにアクセスすることを許可する必要があります。詳細については、「ウォークスルー: ロールを使用したクロスアカウントアクセス」を参照してください。
次の例は、80398EXAMPLE アカウントのポリシーを示しています。このポリシーでは、ユーザーが CodePipeline コンソールMyFirstPipeline
で という名前のパイプラインを表示することはできますが、変更することはできません。このポリシーは、AWSCodePipeline_ReadOnlyAccess
マネージドポリシーに基づいていますが、パイプライン MyFirstPipeline
に固有であるため、このマネージドポリシーを直接使用することはできません。ポリシーを特定のパイプラインに制限しない場合は、 によって作成および維持される管理ポリシーのいずれかを使用することを検討してください CodePipeline。詳細については、「マネージドポリシーの使用」を参照してください。このポリシーは、 という名前のIAMロールなど、アクセス用に作成したロールにアタッチする必要がありますCrossAccountPipelineViewers
。
{ "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipeline", "codepipeline:GetPipelineState", "codepipeline:ListActionTypes", "codepipeline:ListPipelines", "iam:ListRoles", "s3:GetBucketPolicy", "s3:GetObject", "s3:ListAllMyBuckets", "s3:ListBucket", "codedeploy:GetApplication", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "elasticbeanstalk:DescribeApplications", "elasticbeanstalk:DescribeEnvironments", "lambda:GetFunctionConfiguration", "lambda:ListFunctions" ], "Resource": "arn:aws:codepipeline:us-east-2:80398EXAMPLE:MyFirstPipeline" } ], "Version": "2012-10-17" }
このポリシーを作成したら、80398EXAMPLE アカウントにIAMロールを作成し、そのロールにポリシーをアタッチします。ロールの信頼関係では、このロールを引き受ける AWS アカウントを追加する必要があります。次の例は、 のユーザーを許可するポリシーを示しています。111111111111
AWS 8039EXAMPLE8 アカウントで定義されたロールを引き受ける アカウント:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
111111111111
:root" }, "Action": "sts:AssumeRole" } ] }
次の例は、 で作成されたポリシーを示しています。111111111111
AWS ユーザーが 80398EXAMPLE アカウントCrossAccountPipelineViewers
で という名前のロールを引き受けることを許可する アカウント:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::80398EXAMPLE:role/
CrossAccountPipelineViewers
" } ] }
例 8: 別のアカウントに関連付けられた AWS リソースをパイプラインで使用する
ユーザーが別の AWS アカウントのリソースを使用するパイプラインを作成できるようにするポリシーを設定できます。これを行うには、パイプライン (AccountA) を作成するアカウントと、パイプラインで使用するリソースを作成したアカウント (AccountB) の両方にポリシーおよびロールを設定する必要があります。また、クロスアカウントアクセスに使用する AWS Key Management Service には、 でカスタマーマネージドキーを作成する必要があります。詳細と step-by-step例については、別の AWS アカウントのリソース CodePipeline を使用するパイプラインを に作成する「」および「」を参照してくださいの Amazon S3 に保存されているアーティファクトのサーバー側の暗号化を設定する CodePipeline。
次の例は、パイプラインアーティファクトを保存するために使用される S3 バケットに対して AccountA によって設定されたポリシーを示しています。このポリシーは、AccountB へのアクセスを許可します。次の例では、AccountB ARNの は です012ID_ACCOUNT_B
。S3 バケットARNの は ですcodepipeline-us-east-2-1234567890
。アクセスを許可する S3 ARNs バケットとアカウントの ARNsに置き換えます。
{ "Version": "2012-10-17", "Id": "SSEAndSSLPolicy", "Statement": [ { "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::
codepipeline-us-east-2-1234567890
/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890
/*", "Condition": { "Bool": { "aws:SecureTransport": false } } }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012ID_ACCOUNT_B:root
" }, "Action": [ "s3:Get*", "s3:Put*" ], "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890
/*" }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012ID_ACCOUNT_B:root
" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890
" } ] }
以下の例では、AccountA が設定したポリシーを示します。このポリシーは、AccountB がロールを継承できるようにします。このポリシーは、 CodePipeline () のサービスロールに適用する必要がありますCodePipeline_Service_Role
。のロールにポリシーを適用する方法の詳細についてはIAM、「ロールの変更」を参照してください。次の例では、 012ID_ACCOUNT_B
は AccountB ARNの です。 AccountB
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::
012ID_ACCOUNT_B
:role/*" ] } }
次の例は、AccountB によって設定され、 のEC2インスタンスロールに適用されるポリシーを示しています CodeDeploy。このポリシーは、AccountA S3がパイプラインアーティファクト (codepipeline-us-east-2-1234567890
):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*" ], "Resource": [ "arn:aws:s3:::
codepipeline-us-east-2-1234567890
/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east-2-1234567890
" ] } ] }
次の例は、AccountA で作成され、AccountB AWS KMS が使用できるように設定されたカスタマーマネージドキーARNの
が である のポリシーを示しています。arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:DescribeKey", "kms:GenerateDataKey*", "kms:Encrypt", "kms:ReEncrypt*", "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:
012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE
" ] } ] }
次の例は、AccountA のパイプラインで必要なアクションへのアクセスを許可する AccountB によって作成されたIAMロール (CrossAccount_Role
) AccountA のインラインポリシーを示しています。 CodeDeploy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetDeployment", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision" ], "Resource": "*" } ] }
次の例は、AccountB によって作成されたIAMロール (CrossAccount_Role
) のインラインポリシーを示しています。これにより、S3 バケットにアクセスして入力アーティファクトをダウンロードし、出力アーティファクトをアップロードできます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::
codepipeline-us-east-2-1234567890
/*" ] } ] }
リソースへのクロスアカウントアクセスのパイプラインを編集する方法の詳細については、「ステップ 2: パイプラインを編集する 」を参照してください。