Menu
AWS CodePipeline
User Guide (API Version 2015-07-09)

Using Identity-Based Policies (IAM Policies) for AWS CodePipeline

This topic provides examples of identity-based policies that demonstrate how an account administrator can attach permissions policies to IAM identities (that is, users, groups, and roles).

Important

We recommend that you first review the introductory topics that explain the basic concepts and options available to manage access to your AWS CodePipeline resources. For more information, see Overview of Managing Access Permissions to Your AWS CodePipeline Resources

The sections in this topic cover the following:

The following shows an example of a permissions policy that allows a user to enable and disable all stage transitions in the pipeline named MyFirstPipeline in the us-west-2 region:

Copy
{ "Version": "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "codepipeline:EnableStageTransition", "codepipeline:DisableStageTransition" ], "Resource" : [ "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline" ] } ] }

Permissions Required to Use the AWS CodePipeline Console

For a user to work with AWS CodePipeline in the AWS CodePipeline console, that user must have a minimum set of permissions that allows the user to describe other AWS resources for their AWS account. In order to use AWS CodePipeline in the AWS CodePipeline console, you must have permissions from the following services:

  • AWS Identity and Access Management

  • Amazon Simple Storage Service

Depending on the other services you incorporate into your pipelines, you may need permissions from one or more of the following:

  • AWS CodeCommit

  • AWS CodeBuild

  • AWS CloudFormation

  • AWS CodeDeploy

  • AWS Elastic Beanstalk

  • AWS Lambda

  • AWS OpsWorks

If you create an IAM policy that is more restrictive than the minimum required permissions, the console won't function as intended for users with that IAM policy. To ensure that those users can still use the AWS CodePipeline console, also attach the AWSCodePipelineReadOnlyAccess managed policy to the user, as described in AWS Managed (Predefined) Policies for AWS CodePipeline.

You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS CodePipeline API.

AWS Managed (Predefined) Policies for AWS CodePipeline

AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. Managed policies grant necessary permissions for common use cases so you can avoid having to investigate what permissions are needed. For more information, see AWS Managed Policies in the IAM User Guide.

The following AWS managed policies, which you can attach to users in your account, are specific to AWS CodePipeline:

  • AWSCodePipelineFullAccess – Grants full access to AWS CodePipeline.

  • AWSCodePipelineCustomActionAccess – Grants permission to an IAM user to create custom actions in AWS CodePipeline or integrate Jenkins resources for build or test actions.

  • AWSCodePipelineReadOnlyAccess – Grants read-only access to AWS CodePipeline.

  • AWSCodePipelineApproverAccess – Grants permission to an IAM user to approve or reject a manual approval action.

Manage the AWS CodePipeline Service Role

Permissions for some aspects of the pipeline execution process are granted to another role type that acts on behalf of AWS CodePipeline, rather than to IAM users. The Service role is an IAM role that gives AWS CodePipeline permission to use resources in your account. Service role creation is only required the first time you create a pipeline in AWS CodePipeline.

AWS CodePipeline uses this service role when processing revisions through the stages and actions in a pipeline. That role is configured with one or more policies that control access to the AWS resources used by the pipeline. You might want to attach additional policies to this role, edit the policy attached to the role, or configure policies for other service roles in AWS. You might also want to attach a policy to a role when configuring cross-account access to your pipeline.

Important

Modifying a policy statement or attaching another policy to the role can prevent your pipelines from functioning. Be sure that you understand the implications before you modify the service role for AWS CodePipeline in any way. Make sure you test your pipelines after making any changes to the service role.

Review the Default AWS CodePipeline Service Role Policy

By default, the policy statement for the IAM service role for AWS CodePipeline, AWS-CodePipeline-Service, includes permissions needed for AWS CodePipeline to use other resources in your account.

AWS-CodePipeline-Service currently includes the following policy statement:

Copy
{ "Statement": [ { "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetBucketVersioning" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::codepipeline*", "arn:aws:s3:::elasticbeanstalk*" ], "Effect": "Allow" }, { "Action": [ "codecommit:CancelUploadArchive", "codecommit:GetBranch", "codecommit:GetCommit", "codecommit:GetUploadArchiveStatus", "codecommit:UploadArchive" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetApplicationRevision", "codedeploy:GetDeployment", "codedeploy:GetDeploymentConfig", "codedeploy:RegisterApplicationRevision" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "elasticbeanstalk:*", "ec2:*", "elasticloadbalancing:*", "autoscaling:*", "cloudwatch:*", "s3:*", "sns:*", "cloudformation:*", "rds:*", "sqs:*", "ecs:*", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "lambda:InvokeFunction", "lambda:ListFunctions" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "opsworks:CreateDeployment", "opsworks:DescribeApps", "opsworks:DescribeCommands", "opsworks:DescribeDeployments", "opsworks:DescribeInstances", "opsworks:DescribeStacks", "opsworks:UpdateApp", "opsworks:UpdateStack" ], "Resource": "*", "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": "*", "Effect": "Allow" }, { "Action": [ "codebuild:BatchGetBuilds", "codebuild:StartBuild" ], "Resource": "*", "Effect": "Allow" } ], "Version": "2012-10-17" }

Add Permissions for Other AWS Services

You must update your service role policy statement with permissions for an AWS service not already included in the default service role policy statement before you can use it in your pipelines.

This is especially important if the service role you use for your pipelines was created before support was added to AWS CodePipeline for an AWS service.

The following table shows when support was added for other AWS services.

AWS Service AWS CodePipeline Support Date
AWS CodeCommit April 18, 2016
AWS OpsWorks June 2, 2016
AWS CloudFormation November 3, 2016
AWS CodeBuild December 1, 2016

To add permissions for an additional supported service, follow these steps:

  1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

  2. In the IAM console, in the navigation pane, choose Roles, and then choose your AWS-CodePipeline-Service role from the list of roles.

  3. On the Permissions tab, in Inline Policies, in the row for your service role policy, choose Edit Policy.

    Note

    Your service role has a name in a format similar to oneClick_AWS-CodePipeline-1111222233334.

  4. Add the required permissions in the Policy Document box. For example, for AWS CodeCommit support, add the following to your policy statement:

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

    For AWS OpsWorks support, add the following to your policy statement:

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

    For AWS CloudFormation support, add the following to your policy statement:

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

    For AWS CodeBuild support, add the following to your policy statement:

    Copy
    { "Action": [ "codebuild:BatchGetBuilds", "codebuild:StartBuild" ], "Resource": "*", "Effect": "Allow" },
  5. Choose Validate Policy to ensure the policy contains no errors. When the policy is error-free, choose Apply Policy.

Remove Permissions for Unused AWS Services

You can edit the service role statement to remove access to resources you do not use. For example, if none of your pipelines include Elastic Beanstalk, you could edit the policy statement to remove the section that grants Elastic Beanstalk resources. For example, you could remove the following section from the policy statement:

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

Similarly, if none of your pipelines includes AWS CodeDeploy, you can edit the policy statement to remove the section that grants AWS CodeDeploy resources:

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

For more information about IAM roles, see IAM Roles.

Customer Managed Policy Examples

In this section, you can find example user policies that grant permissions for various AWS CodePipeline actions. These policies work when you are using the AWS CodePipeline API, AWS SDKs, or the AWS CLI. When you are using the console, you need to grant additional permissions specific to the console, which is discussed in Permissions Required to Use the AWS CodePipeline Console.

Note

All examples use the US West (Oregon) Region (us-west-2) and contain fictitious account IDs.

Examples

Example 1: Grant Permissions to Get the State of a Pipeline

The following example grants permissions to get the state of the pipeline named MyFirstPipeline:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipelineState" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline" } ] }

Example 2: Grant Permissions to Enable and Disable Transitions Between Stages

The following example grants permissions to disable and enable transitions between all stages in the pipeline named MyFirstPipeline:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:DisableStageTransition", "codepipeline:EnableStageTransition" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*" } ] }

To allow the user to disable and enable transitions for a single stage in a pipeline, you must specify the stage. For example, to allow the user to enable and disable transitions for a stage named Staging in a pipeline named MyFirstPipeline:

Copy
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"

Example 3: Grant Permissions to Get a List of All Available Action Types

The following example grants permissions to get a list of all available action types available for pipelines in the us-west-2 region:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:ListActionTypes" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*" } ] }

Example 4: Grant Permissions to Approve or Reject Manual Approval Actions

The following example grants permissions to approve or reject manual approval actions in a stage named Staging in a pipeline named MyFirstPipeline:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PutApprovalResult" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*" } ] }

Example 5: Grant Permissions to Poll for Jobs for a Custom Action

The following example grants permissions to poll for jobs for the custom action named TestProvider, which is a Test action type in its first version, across all pipelines:

Note

The job worker for a custom action might be configured under a different AWS account or require a specific IAM role in order to function.

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForJobs" ], "Resource": [ "arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1" ] } ] }

Example 6: Attach or Edit a Policy for Jenkins Integration with AWS CodePipeline

If you configure a pipeline to use Jenkins for build or test, create a separate IAM user for that integration and attach an IAM policy that has the minimum permissions required for integration between Jenkins and AWS CodePipeline. This policy is the same as the AWSCodePipelineCustomActionAccess managed policy. The following example shows a policy to attach to an IAM user that will be used for Jenkins integration:

Copy
{ "Statement": [ { "Action": [ "codepipeline:AcknowledgeJob", "codepipeline:GetJobDetails", "codepipeline:PollForJobs", "codepipeline:PutJobFailureResult", "codepipeline:PutJobSuccessResult" ], "Effect": "Allow", "Resource": "*" } ], "Version": "2012-10-17" }

Example 7: Configure Cross-Account Access to a Pipeline

You can configure access to pipelines for users and groups in another AWS account. The recommended way of doing so is to create a role in the account where the pipeline was created that allows users from the other AWS account to assume that role and access the pipeline. For more information, see Walkthrough: Cross-Account Access Using Roles.

The following example shows a policy in the 80398EXAMPLE account that allows users to view, but not change, the pipeline named MyFirstPipeline in the AWS CodePipeline console. This policy is based on the AWSCodePipelineReadOnlyAccess managed policy, but because it is specific to the MyFirstPipeline pipeline, it cannot use the managed policy directly. If you do not want to restrict the policy to a specific pipeline, strongly consider using one of the managed policies created and maintained by AWS CodePipeline. For more information, see Working with Managed Policies. You must attach this policy to an IAM role you create for access, for example a role named CrossAccountPipelineViewers:

Copy
{ "Statement": [ { "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" ], "Effect": "Allow", "Resource": "arn:aws:codepipeline:us-east-2:80398EXAMPLE:MyFirstPipeline" } ], "Version": "2012-10-17" }

Once you create this policy, create the IAM role in the 80398EXAMPLE account and attach the policy to that role. In the role's trust relationships, you must add the AWS account that will assume this role. The following example shows a policy that allows users from the 111111111111 AWS account to assume roles defined in the 80398EXAMPLE account:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole" } ] }

The following example shows a policy created in the 111111111111 AWS account that allows users to assume the role named CrossAccountPipelineViewers in the 80398EXAMPLE account:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::80398EXAMPLE:role/CrossAccountPipelineViewers" } ] }

Example 8: Use AWS Resources Associated with Another Account in a Pipeline

You can configure policies that allow a user to create a pipeline that uses resources in another AWS account. This requires configuring policies and roles in both the account that will create the pipeline (AccountA) and the account that created the resources to be used in the pipeline (AccountB). You must also create a customer-managed key in AWS Key Management Service to use for cross-account access. For more information and step-by-step examples, see Create a Pipeline in AWS CodePipeline That Uses Resources from Another AWS Account and Encryption for Artifacts Stored in Amazon S3 for AWS CodePipeline.

The following example shows a policy configured by AccountA for an Amazon S3 bucket used to store pipeline artifacts that grants access to AccountB (where the ARN for AccountB. In the following example, the ARN is for AccountB is 012ID_ACCOUNT_B. The ARN for the Amazon S3 bucket is codepipeline-us-east-2-1234567890. Replace these ARNs with the ARN for the account you want to allow access and for the Amazon S3 bucket:

Copy
{ "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" } ] }

The following example shows a policy configured by AccountA that allows AccountB to assume a role. This policy must be applied to the service role for AWS CodePipeline (AWS-CodePipeline-Service). For more information about how to apply policies to roles in IAM, see Modifying a Role. In the following example, 012ID_ACCOUNT_B is the ARN for AccountB:

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::012ID_ACCOUNT_B:role/*" ] } }

The following example shows a policy configured by AccountB and applied to the Amazon EC2 instance role for AWS CodeDeploy. This policy grants access to the Amazon S3 bucket used by AccountA to store pipeline artifacts (codepipeline-us-east-2-1234567890):

Copy
{ "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" ] } ] }

The following example shows a policy for AWS KMS where arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE is the ARN of the customer-managed key created in AccountA and configured to allow AccountB to use it:

Copy
{ "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" ] } ] }

The following example shows an inline policy for an IAM role (CrossAccount_Role) created by AccountB that allows access to AWS CodeDeploy actions required by the pipeline in AccountA.

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

The following example shows an inline policy for an IAM role (CrossAccount_Role) created by AccountB that allows access to the Amazon S3 bucket in order to download input artifacts and upload output artifacts:

Copy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east-2-1234567890/*" ] } ] }

For more information about how to edit a pipeline for cross-account access to resources after you have created the necessary policies, roles, and AWS Key Management Service customer-managed key, see Step 2: Edit the Pipeline .