IAM Policies for AWS CodeCommit

ACM.263 Creating granular permissions for AWS CodeCommit and cross-account options

Part of my series on Automating Cybersecurity Metrics. Git. Also Deploying a Static Website. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

In the last post we took at look at network restrictions available for AWS CodeCommit and contrasted that with the network restrictions available for a publicly hosted GitHub repository.

In this post I want to see what we can do to restrict and grant access to AWS CodeCommit repositories.

Encryption for AWS CodeCommit Repositories

We’ve already looked at networking which is one of the primary security controls for preventing data breaches. The next is encryption. Unfortunately I don’t see the option to protect your AWS CodeCommit repositories with a customer managed KMS key. That would be a great feature to add. #awswishlist

However, as I was reviewing all the documentation for AWS CodeCommit (and yes I mean all), I noticed is that CodeCommit requires KMS permissions. If the user trying to access a CodeCommit responsitory does not have KMS permissions, then they won’t be able to access the repository.

What KMS permissions exactly? It doesn’t say.

My intention was to manage all KMS keys from a single account with cross-account access (presuming some errors with logging cross-account access have been resolved). Will this impact my plan? Does the user need the ability to create or just use KMS keys? Encrypt and decrypt? I presume this is managed by AWS and I cannot limit access to specific keys in this case?

You can find some details in this documentation:

Luckily key creation is not required. We need to allow some access to AWS but not the ability to create and administer KMS keys so that’s good.

Here we find explicit documentation stating what already seems obvious based on the CloudFormation documentation.

You cannot use a customer managed key in AWS KMS to encrypt or decrypt data in CodeCommit repositories.

But you can see the key that AWS is using for your repositories.

Head over to KMS and look at the AWS Managed Keys:

There you can see that a key exists for aws/codecommit. One key. For all your repositories in that account.

In a prior post I was pondering whether to deploy repositories. Presumably we can create a policy that only grants access to the above key to specific principals. Since there is one key for the whole account, if we want to use different keys and permissions for Dev, QA, and Prod, then we need to create repositories in three separate accounts.

You may have certain individuals that need to review the code across all environments and be able to decrypt the encrypted code to review it. Perhaps security teams or architects or senior developers or DevOps engineers need such access. But does every junior developer need access to production code? Perhaps you have a mechanism to allow access to the code when needed using some just-in-time mechanism.

This aspect of AWS CodeCommit must be taken into consideration as you architect your AWS account structure and deployment systems if you are going to use AWS CodeCommit and want to restrict access to production encyrption keys.

What other permissions are required for AWS CodeCommit?

Let’s look at the built in roles for AWS CodeCommit in the IAM dashboard. When I filter on codecommit three come up.

The read only user has access to list a lot of resources in the account. This is all read only access but this policy does grant access to all resources, not only those related to AWS CodeCommit.

A PowerUser can check in code, I presume. Well, actually, the list of permissions that the AWS CodeCommit power user is so long I can’t capture it all in a screen shot.

It includes Route 53 domains.

I warned you about the security issues with that privilege in a prior post. This is a very powerful privilege as is all access to Route 53.

Full EC2 access includes changing any network configuration in the account.

There’s KMS and oh by the way RDS IAM authentication.

I would say the CodeCommit Power User is not specific to CodeCommit permissions at all. You should definitely consider creating your own policies for AWS CodeCommit with only what is required.

What permissions are actually required?

For a complete list of required permission check out this list:

For example for Git commands:

The nice thing here is that you can restrict the action to particular resources. So for example, I prefixed the name of the repository in a prior post with the environment name:

What that means is that I could create a policy for developers that allow them to access all repositories that have a name starting with the developer environment the same way we restricted access to various CloudFormation resource stacks based on a prefix. If you have a large company with different teams, departments, or lines of business you could make the prefix a department or line of business to simplify your policies.

Design for the expectation of organizational changes

In my experience, companies tend to move projects and teams around which can complicate your pristine policies. Suddenly you have a team that typically works on back-office financial applications working on a sales project. (This happened to me when I was a team lead.) So I would be wary of prefixing projects with team names for this reason. Even department names are tricky.

My preference, as a team lead, was also to generally switch projects to different teams rather than to switch people to different teams once you got a good team working smoothly. But often people ignored that request in the particular organizational where I worked.

Sometimes, in a financial organization, it’s good to switch people around to avoid collusion in system designs, processes, and support. Consider all these potential changes as you map out the structure of your code repositories, permissions and policies.

Branches and Merging

As mentioned I find branches and merging to be a bit complex. You can set permissions such that only certain people are allowed to create or merge a branch to avoid the related pitfalls.

Leveraging Approval Rules

You can also set permissions to allow certain people to associate approval rules with repositories.

I wrote about code reviews here. They are beneficial but need to also allow developers to get things done.

The nice thing about creating separate repositories for Dev, QA, and Production would be the ability to easily assign different reviewers and templates in each environment. Though perhaps you could create a single template that works for each individual environment as well.

IAM Roles

You could assign your code commit permissions directly to users. The credentials we created for AWS CodeCommit are associated directly with a user. However, that is generally not a best practice.

We could also use assign the permissions to a group and allow the developers in a particular group to access certain repositories.

But remember how I said I wanted to enforce MFA to access a repository when checking in code? I don’t see a good way to do that with GitHub. Once I create a developer access token you can login with that without MFA. Perhaps when you use OIDC you can enforce MFA to get a token. I’m not sure.

What I do know is that if you grant access to GitHub through an AWS IAM role, then you can enforce requiring MFA to assume a role. That’s something we will try out when we grant access to our new repository to the web admin user role.

The other thing you can do is grant access to repositories using federated access and third-party Identity Providers.

I was setting up Okta so we can try that out later when I get back to completing the Okta setup. You can also use SCIM and Okta with Github.

I wrote about SCIM here and had some concerns about using it with AWS SSO. I’ll have to review GitHub and see if the same concerns exist.

You can also use STS to get temporary permissions and set up cross-account access, as I have been demonstrating recently with our web deployment.

Access to Clone our GitHub Repo to AWS Code Commit

OK, what I need now is to populate GitHub, check in a change and trigger a deployment. The web admin user has permission to check code changes into GitHub. This user can also trigger a deployment but how?

I don’t want to have a separate deployment process for every website so we’ll probably set up a job that has permission to pull the code from GitHub into some kind of compute resource and then push it to AWS Code Commit.

Thinking this through it’s not clear that the web admin even needs access to AWS Code Commit at all, but the role running the deployment process does. However, if we want to enforce MFA then we need to have a person with an MFA device involved. So I’m back to where I started with batch jobs and MFA for automated processes. Now that I know what my options are in terms of permissions and roles, I’ll ponder that and continue on in future posts with implementation of this idea.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

The best way to support this blog is to sign up for the email list and clap for stories you like. If you are interested in IANS Decision Support services so you can schedule security consulting calls with myself and other IANS faculty, please reach out on LinkedIn via the link below. Thank you!

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
Author: Cybersecurity for Executives in the Age of Cloud
Presentations: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Security Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Software Engineering, Master of Infosec
Company: Cloud Penetration Tests, Assessments, Training ~ 2nd Sight Lab

Like this story? Use the options below to help me write more!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Clap
❤️ Referrals
❤️ Medium: Teri Radichel
❤️ Email List: Teri Radichel
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
❤️ Buy a Book: Teri Radichel on Amazon
❤️ Request a penetration test, assessment, or training
 via LinkedIn: Teri Radichel 
❤️ Schedule a consulting call with me through IANS Research

My Cybersecurity Book: Cybersecurity for Executives in the Age of Cloud