AWS CodePipeline アイデンティティベースポリシーの例 - AWS CodePipeline

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

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

デフォルトでは、IAM ユーザーとロールには CodePipeline リソースを作成または変更するアクセス許可はありません。また、、 AWS Management Console AWS CLI、または AWS API を使用してタスクを実行することはできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチする必要があります。

JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースポリシーを作成する方法については、「IAM ユーザーガイド」の「JSON タブでのポリシーの作成」を参照してください。

別のアカウントのリソースを使用するパイプラインを作成する方法、および関連するポリシーの例については、「」を参照してください別の AWS アカウントのリソース CodePipeline を使用するパイプラインを に作成する

カスタマーマネージドポリシーの例

このセクションでは、さまざまな CodePipeline アクションのアクセス許可を付与するユーザーポリシーの例を示します。これらのポリシーは、 CodePipeline API、 AWS SDKs、または を使用している場合に機能します AWS CLI。コンソールを使用している場合は、コンソールに固有の追加のアクセス許可を付与する必要があります。詳細については、「 CodePipeline コンソールの使用に必要な許可」を参照してください。

注記

各例は全て、米国西部 (オレゴン) リージョン (us-west-2) を使用し、架空のアカウント ID を使用しています。

例 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 アカウントのユーザーがそのロールを引き受けてパイプラインにアクセスすることを許可する必要があります。詳細については、「ウォークスルー: ロールを使用したクロスアカウントアクセス」を参照してください。

次の例は、MyFirstPipeline CodePipeline 80398EXAMPLE アカウントのポリシーを示しています。このポリシーでは、コンソールで という名前のパイプラインを表示することはできますが、変更することはできません。このポリシーは、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 アカウントのユーザーが 80398EXAMPLE アカウントで定義されたロールを引き受けることを許可するポリシーを示しています。

{ "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 です。これらの ARN を、アクセスを許可するアカウントおよび S3 バケットの ARN に置き換えます。

{ "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 です。

{ "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-east2-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) のインラインポリシーを示しています。 CodeDeploy AccountA

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetDeployment", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision" ], "Resource": "*" } ] }

次の例では、AccountBによって作成された ロール (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: パイプラインを編集する 」を参照してください。