You started using AWS CodeCommit as your remote private Git repository and liked its cost-effective, easy to manage, and serverless nature. Now you would like to invite other developers to your project and collaborate with them. How can you achieve this?
In this post, I will talk about the steps you need to make your repository accessible to other developers. Let’s start!
AWS CodeCommit: Your private Git repository on AWS!
AWS CodeCommit is the private Git repository of AWS. It is a managed service, you do not need to maintain any web servers, and it is cost-effective. Your first five active users are free per month regardless of the number of repositories they access, and above this limit, you pay only $1 per active user per month.
You can also integrate AWS CodeCommit with AWS CodePipeline and other AWS services to create a CI/CD pipeline for your applications. You align permissions to your repositories through IAM, and you can use standard git commands or AWS Management Console to change files and commit them. Hence, once you get used to it, AWS CodeCommit will speed up your software projects.
Now, let’s remember how you connect to your AWS CodeCommit repositories yourself as an owner and then explain what you need to do for other developers without the same level of access to it.
Managing Your Developers’ Permissions Through IAM
Like other AWS services, you manage access to your AWS CodeCommit repositories through IAM. I assume that you have an IAM user with administrator privileges on your account as an owner. Your IAM user has the privileges to create and delete AWS CodeCommit repositories, and you created one for your application.
However, your developers will mostly need only to pull the code, push their changes, maybe create branches or tags, etc. They will not need admin-level access like you, create new repositories, or delete existing ones. Therefore, you need to create separate IAM users for each of your developers to separate their permissions from yours, and they do not have to be account-level administrators.
At this stage, creating an IAM group, such as
Developers, and placing your developers in it would be efficient to manage their permissions. You will only assign permissions to this IAM group and manage them centrally. When someone joins your team, all you need to do will be adding your his/her IAM user to this group. Similarly, you can remove him/her from the group if he/she leaves the team.
IAM Policies for Your Developers Group
OK, you created the Developers group on AWS IAM and placed your developer IAM users in it. Then, which permissions will you need to assign to this group? Let’s talk about the choices we have.
AWS-Managed AWS CodeCommit Policies
There are AWS-managed policies for AWS CodeCommit like most AWS services. You can use them for your IAM groups directly according to the level you need to set for your IAM users. Let me explain these one by one.
AWSCodeCommitPowerUser: This policy suits well to the developers scenario in this blog post. It contains most of the privileges for an existing AWS CodeCommit repository. It grants privileges related to using standard Git commands such as Git pull, Git push, create/delete branch/tags, and AWS CodeCommit-specific features, like configuring notifications, triggers, etc. However, it does not allow deleting AWS CodeCommit repositories in your AWS account or creating/deleting CodeCommit related resources in other AWS services.
AWSCodeCommitFullAccess: This policy assigns owner-level privileges to AWS CodeCommit. Your users with this policy will be able to do all the actions AWSCodeCommitPowerUser provides and create or delete repositories. Please be cautious about assigning this policy as it will grant full access to your developers. They can delete repositories they should not even have access to.
AWSCodeCommitReadOnly: As its name suggests, this policy grants read access to your repositories. If you would like to grant a developer access to your repository, for example, for discussing a project but not giving him/her any privileges to push/pull code, etc., this policy may help you.
Using AWS-managed policies is fine, but they are valid for all AWS CodeCommit repositories in your AWS account. Hence, creating a custom policy either by importing AWSCodeCommitPowerUser and editing or selecting the actions you need one by one and allowing only them would be more appropriate to apply the principle of least privilege.
Customer-managed Policies From AWSCodeCommitPowerUser
Customer-managed IAM policies are the custom policies you define in your AWS account specialized to your needs. As AWS-managed policies span all resources, you can create a customer-managed policy by importing
AWSCodeCommitPowerUser and limiting the CodeCommit actions to only the AWS CodeCommit repository (or repositories) needed by your developers.
You can do this by clicking the
Import managed policy link while creating a customer-managed policy on the IAM Console.
Then, you can search and choose the
AWSCodeCommitPowerUser policy from the list opened.
After that you can edit this policy and limit the
codecommit: actions only to a single repository by changing the
Resource attribute in that statement. Your final IAM policy will be similar to below. I replaced the statements’ contents with dots to keep this post readable. Please note the
<your-repo-arn> part in the first statement, which grants access to CodeCommit actions. You should replace it with the ARN of your AWS CodeCommit repository to limit those permissions only to your repository.
This is also the view from the IAM Console. It shows an error because
<your-repo-arn> should be replaced with a valid AWS CodeCommit repository ARN.
A Customer-managed Policy With Fewer Permissions
As you see above, the AWSCodeCommitPowerUser policy is not limited to CodeCommit actions. It also allows the user access to CodeStar, CodeGuruReviewer, SNS subscriptions, etc., as well as the IAM console to create credentials for himself/herself. In some situations, you may find these unnecessary and would like to limit the policy with few actions. So, alternatively, you can create a shorter version of this policy, only allowing the CodeCommit actions you would like to assign. However, keeping the actions allowing the users to create their own Git credentials would also be feasible. They should not be emailing you every time they need to recreate them.
The policy below allows Git client-related and read-only actions to an AWS CodeCommit repository. Besides, it also grants permissions to upload SSH keys, create IAM access keys and Git credentials on the IAM console to the user signed in, whichever method the developer prefers to connect to your AWS CodeCommit repository. You can add more actions if you need.
How will your developers connect to your AWS CodeCommit repository?
After assigning permissions to your IAM group, all your developers need to choose a connection method for your AWS CodeCommit repository. If they use the
CodeCommit repository's HTTPS URL, they will need to create
Git credentials on AWS IAM Console. Likewise, if they prefer
SSH keys, they can upload one there. They can even use their IAM programmatic access keys using
git-remote-codecommit helper. It is just like how you connect to your repository.
Join my online course to learn using AWS CodeCommit with AWS CodePipeline
Would you like to learn AWS CodeCommit and how to connect to it with your Git credentials? You can even create a CI/CD pipeline with AWS CodePipeline that triggers upon Git pushes to your repository and automatically deploy them to S3 or EC2 instances.
If you are interested, please checkout my AWS CodePipeline Step by Step course on Udemy . The link also contains a special discount for you as a reader of this post.
I have been using AWS CodeCommit repositories for years when I need to keep my repositories private. At some point, you always need to collaborate with other people, either by joining a new project or inviting others to yours. I hope this post helps you align permissions for other developers to grant access to your AWS CodeCommit repositories.
Thanks for reading!