Customer managed policy examples - Amazon CodeCommit
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Customer managed policy examples

You can create your own custom IAM policies to allow permissions for CodeCommit actions and resources. You can attach these custom policies to the IAM users or groups that require those permissions. You can also create your own custom IAM policies for integration between CodeCommit and other Amazon services.

Customer managed identity policy examples

The following example IAM policies grant permissions for various CodeCommit actions. Use them to limit CodeCommit access for your IAM users and roles. These policies control the ability to perform actions with the CodeCommit console, API, Amazon SDKs, or the Amazon CLI.

Note

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

Examples

Example 1: Allow a user to perform CodeCommit operations in a single Amazon Web Services Region

The following permissions policy uses a wildcard character ("codecommit:*") to allow users to perform all CodeCommit actions in the us-east-2 Region and not from other Amazon Web Services Regions.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "codecommit:*", "Resource": "arn:aws:codecommit:us-east-2:111111111111:*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" } } }, { "Effect": "Allow", "Action": "codecommit:ListRepositories", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" } } } ] }

Example 2: Allow a user to use Git for a single repository

In CodeCommit, the GitPull IAM policy permissions apply to any Git client command where data is retrieved from CodeCommit, including git fetch, git clone, and so on. Similarly, the GitPush IAM policy permissions apply to any Git client command where data is sent to CodeCommit. For example, if the GitPush IAM policy permission is set to Allow, a user can push the deletion of a branch using the Git protocol. That push is unaffected by any permissions applied to the DeleteBranch operation for that IAM user. The DeleteBranch permission applies to actions performed with the console, the Amazon CLI, the SDKs, and the API, but not the Git protocol.

The following example allows the specified user to pull from, and push to, the CodeCommit repository named MyDemoRepo:

{ "Version": "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "codecommit:GitPull", "codecommit:GitPush" ], "Resource" : "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo" } ] }

Example 3: Allow a user connecting from a specified IP address range access to a repository

You can create a policy that only allows users to connect to a CodeCommit repository if their IP address is within a certain IP address range. There are two equally valid approaches to this. You can create a Deny policy that disallows CodeCommit operations if the IP address for the user is not within a specific block, or you can create an Allow policy that allows CodeCommit operations if the IP address for the user is within a specific block.

You can create a Deny policy that denies access to all users who are not within a certain IP range. For example, you could attach the AWSCodeCommitPowerUser managed policy and a customer-managed policy to all users who require access to your repository. The following example policy denies all CodeCommit permissions to users whose IP addresses are not within the specified IP address block of 203.0.113.0/16:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codecommit:*" ], "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "203.0.113.0/16" ] } } } ] }

The following example policy allows the specified user to access a CodeCommit repository named MyDemoRepo with the equivalent permissions of the AWSCodeCommitPowerUser managed policy only if their IP address is within the specified address block of 203.0.113.0/16:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codecommit:BatchGetRepositories", "codecommit:CreateBranch", "codecommit:CreateRepository", "codecommit:Get*", "codecommit:GitPull", "codecommit:GitPush", "codecommit:List*", "codecommit:Put*", "codecommit:Post*", "codecommit:Merge*", "codecommit:TagResource", "codecommit:Test*", "codecommit:UntagResource", "codecommit:Update*" ], "Resource": "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "Condition": { "IpAddress": { "aws:SourceIp": [ "203.0.113.0/16" ] } } } ] }

Example 4: Deny or allow actions on branches

You can create a policy that denies users permissions to actions you specify on one or more branches. Alternatively, you can create a policy that allows actions on one or more branches that they might not otherwise have in other branches of a repository. You can use these policies with the appropriate managed (predefined) policies. For more information, see Limit pushes and merges to branches in Amazon CodeCommit.

For example, you can create a Deny policy that denies users the ability to make changes to a branch named main, including deleting that branch, in a repository named MyDemoRepo. You can use this policy with the AWSCodeCommitPowerUser managed policy. Users with these two policies applied would be able to create and delete branches, create pull requests, and all other actions as allowed by AWSCodeCommitPowerUser, but they would not be able to push changes to the branch named main, add or edit a file in the main branch in the CodeCommit console, or merge branches or a pull request into the main branch. Because Deny is applied to GitPush, you must include a Null statement in the policy, to allow initial GitPush calls to be analyzed for validity when users make pushes from their local repos.

Tip

If you want to create a policy that applies to all branches named main in all repositories in your Amazon Web Services account, for Resource, specify an asterisk ( * ) instead of a repository ARN.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codecommit:GitPush", "codecommit:DeleteBranch", "codecommit:PutFile", "codecommit:Merge*" ], "Resource": "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "Condition": { "StringEqualsIfExists": { "codecommit:References": [ "refs/heads/main" ] }, "Null": { "codecommit:References": "false" } } } ] }

The following example policy allows a user to make changes to a branch named main in all repositories in an Amazon Web Services account. It does not allow changes to any other branches. You might use this policy with the AWSCodeCommitReadOnly managed policy to allow automated pushes to the repository in the main branch. Because the Effect is Allow, this example policy would not work with managed policies such as AWSCodeCommitPowerUser.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codecommit:GitPush", "codecommit:Merge*" ], "Resource": "*", "Condition": { "StringEqualsIfExists": { "codecommit:References": [ "refs/heads/main" ] } } } ] }

Example 5: Deny or allow actions on repositories with tags

You can create a policy that allows or denies actions on repositories based on the Amazon tags associated with those repositories, and then apply those policies to the IAM groups you configure for managing IAM users. For example, you can create a policy that denies all CodeCommit actions on any repositories with the Amazon tag key Status and the key value of Secret, and then apply that policy to the IAM group you created for general developers (Developers). You then need to make sure that the developers working on those tagged repositories are not members of that general Developers group, but belong instead to a different IAM group that does not have the restrictive policy applied (SecretDevelopers).

The following example denies all CodeCommit actions on repositories tagged with the key Status and the key value of Secret:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codecommit:Associate*", "codecommit:Batch*", "codecommit:CancelUploadArchive", "codecommit:CreateBranch", "codecommit:CreateCommit", "codecommit:CreatePullRequest*", "codecommit:CreateRepository", "codecommit:CreateUnreferencedMergeCommit", "codecommit:DeleteBranch", "codecommit:DeleteCommentContent", "codecommit:DeleteFile", "codecommit:DeletePullRequest*", "codecommit:DeleteRepository", "codecommit:Describe*", "codecommit:DisassociateApprovalRuleTemplateFromRepository", "codecommit:EvaluatePullRequestApprovalRules", "codecommit:GetBlob", "codecommit:GetBranch", "codecommit:GetComment*", "codecommit:GetCommit", "codecommit:GetDifferences*", "codecommit:GetFile", "codecommit:GetFolder", "codecommit:GetMerge*", "codecommit:GetObjectIdentifier", "codecommit:GetPullRequest*", "codecommit:GetReferences", "codecommit:GetRepository*", "codecommit:GetTree", "codecommit:GetUploadArchiveStatus", "codecommit:Git*", "codecommit:ListAssociatedApprovalRuleTemplatesForRepository", "codecommit:ListBranches", "codecommit:ListPullRequests", "codecommit:ListTagsForResource", "codecommit:Merge*", "codecommit:OverridePullRequestApprovalRules", "codecommit:Post*", "codecommit:Put*", "codecommit:TagResource", "codecommit:TestRepositoryTriggers", "codecommit:UntagResource", "codecommit:UpdateComment", "codecommit:UpdateDefaultBranch", "codecommit:UpdatePullRequest*", "codecommit:UpdateRepository*", "codecommit:UploadArchive" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Status": "Secret" } } } ] }

You can further refine this strategy by specifying specific repositories, rather than all repositories, as resources. You can also create policies that allow CodeCommit actions on all repositories that are not tagged with specific tags. For example, the following policy allows the equivalent of AWSCodeCommitPowerUser permissions for CodeCommit actions, except that it only allows CodeCommit actions on repositories not tagged with the specified tags:

Note

This policy example only includes actions for CodeCommit. It does not include actions for other Amazon services that are included in the AWSCodeCommitPowerUser managed policy. For more information, see .Amazon managed policy: AWSCodeCommitPowerUser.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codecommit:Associate*", "codecommit:Batch*", "codecommit:CancelUploadArchive", "codecommit:CreateBranch", "codecommit:CreateCommit", "codecommit:CreatePullRequest*", "codecommit:CreateRepository", "codecommit:CreateUnreferencedMergeCommit", "codecommit:DeleteBranch", "codecommit:DeleteCommentContent", "codecommit:DeleteFile", "codecommit:DeletePullRequest*", "codecommit:Describe*", "codecommit:DisassociateApprovalRuleTemplateFromRepository", "codecommit:EvaluatePullRequestApprovalRules", "codecommit:GetBlob", "codecommit:GetBranch", "codecommit:GetComment*", "codecommit:GetCommit", "codecommit:GetDifferences*", "codecommit:GetFile", "codecommit:GetFolder", "codecommit:GetMerge*", "codecommit:GetObjectIdentifier", "codecommit:GetPullRequest*", "codecommit:GetReferences", "codecommit:GetRepository*", "codecommit:GetTree", "codecommit:GetUploadArchiveStatus", "codecommit:Git*", "codecommit:ListAssociatedApprovalRuleTemplatesForRepository", "codecommit:ListBranches", "codecommit:ListPullRequests", "codecommit:ListTagsForResource", "codecommit:Merge*", "codecommit:OverridePullRequestApprovalRules", "codecommit:Post*", "codecommit:Put*", "codecommit:TagResource", "codecommit:TestRepositoryTriggers", "codecommit:UntagResource", "codecommit:UpdateComment", "codecommit:UpdateDefaultBranch", "codecommit:UpdatePullRequest*", "codecommit:UpdateRepository*", "codecommit:UploadArchive" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceTag/Status": "Secret", "aws:ResourceTag/Team": "Saanvi" } } }, { "Effect": "Allow", "Action": [ "codecommit:CreateApprovalRuleTemplate", "codecommit:GetApprovalRuleTemplate", "codecommit:ListApprovalRuleTemplates", "codecommit:ListRepositories", "codecommit:ListRepositoriesForApprovalRuleTemplate", "codecommit:UpdateApprovalRuleTemplateContent", "codecommit:UpdateApprovalRuleTemplateDescription", "codecommit:UpdateApprovalRuleTemplateName" ], "Resource": "*" } ] }

Customer managed integration policy examples

This section provides example customer-managed user policies that grant permissions for integrations between CodeCommit and other Amazon services. For specific examples of policies that allow cross-account access to a CodeCommit repository, see Configure cross-account access to an Amazon CodeCommit repository using roles.

Note

All examples use the US West (Oregon) Region (us-west-2) when an Amazon Web Services Region is required, and contain fictitious account IDs.

Examples

Example 1: Create a policy that enables cross-account access to an Amazon SNS topic

You can configure a CodeCommit repository so that code pushes or other events trigger actions, such as sending a notification from Amazon Simple Notification Service (Amazon SNS). If you create the Amazon SNS topic with the same account used to create the CodeCommit repository, you do not need to configure additional IAM policies or permissions. You can create the topic, and then create the trigger for the repository. For more information, see Create a trigger for an Amazon SNS topic.

However, if you want to configure your trigger to use an Amazon SNS topic in another Amazon Web Services account, you must first configure that topic with a policy that allows CodeCommit to publish to that topic. From that other account, open the Amazon SNS console, choose the topic from the list, and for Other topic actions, choose Edit topic policy. On the Advanced tab, modify the policy for the topic to allow CodeCommit to publish to that topic. For example, if the policy is the default policy, you would modify the policy as follows, changing the items in red italic text to match the values for your repository, Amazon SNS topic, and account:

{ "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__default_statement_ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "sns:Subscribe", "sns:ListSubscriptionsByTopic", "sns:DeleteTopic", "sns:GetTopicAttributes", "sns:Publish", "sns:RemovePermission", "sns:AddPermission", "sns:SetTopicAttributes" ], "Resource": "arn:aws:sns:us-east-2:111111111111:NotMySNSTopic", "Condition": { "StringEquals": { "AWS:SourceOwner": "111111111111" } } }, { "Sid": "CodeCommit-Policy_ID", "Effect": "Allow", "Principal": { "Service": "codecommit.amazonaws.com" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-2:111111111111:NotMySNSTopic", "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "AWS:SourceAccount": "111111111111" } } } ] }

Example 2: Create an Amazon Simple Notification Service (Amazon SNS) topic policy to allow Amazon CloudWatch Events to publish CodeCommit events to the topic

You can configure CloudWatch Events to publish to an Amazon SNS topic when events occur, including CodeCommit events. To do so, you must make sure that CloudWatch Events has permission to publish events to your Amazon SNS topic by creating a policy for the topic or modifying an existing policy for the topic similar to the following:

{ "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__default_statement_ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-2:123456789012:MyTopic", "Condition": { "StringEquals": { "AWS:SourceOwner": "123456789012" } } }, { "Sid": "Allow_Publish_Events", "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-2:123456789012:MyTopic" } ] }

For more information about CodeCommit and CloudWatch Events, see CloudWatch Events Event Examples From Supported Services. For more information about IAM and policy language, see Grammar of the IAM JSON Policy Language.

Example 3: Create a policy for Amazon Lambda integration with a CodeCommit trigger

You can configure a CodeCommit repository so that code pushes or other events trigger actions, such as invoking a function in Amazon Lambda. For more information, see Create a trigger for a Lambda function. This information is specific to triggers, and not CloudWatch Events.

If you want your trigger to run a Lambda function directly (instead of using an Amazon SNS topic to invoke the Lambda function), and you do not configure the trigger in the Lambda console, you must include a statement similar to the following in the function's resource-based policy:

{ "Statement":{ "StatementId":"Id-1", "Action":"lambda:InvokeFunction", "Principal":"codecommit.amazonaws.com", "SourceArn":"arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "SourceAccount":"111111111111" } }

When manually configuring a CodeCommit trigger that invokes a Lambda function, you must also use the Lambda AddPermission command to grant permission for CodeCommit to invoke the function. For an example, see the To allow CodeCommit to run a Lambda function section of Create a trigger for an existing Lambda function.

For more information about resource policies for Lambda functions, see AddPermission and The Pull/Push Event Models in the Amazon Lambda Developer Guide.