Network Security for AWS CodeCommit Git Repositories

ACM.262 Limiting access to your repositories to your private network

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

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

In the last post I showed you how to use standard Git commands with AWS Code Commit.

In this post we’ll consider how you can control network access to your AWS Code Commit repositories.

Network Access to GitHub

When you access GitHub as a service (meaning hosted and run by Microsoft not your own server) your traffic to your GitHub account traverses the Internet. That opens up your account to a myriad of attacks that are not possible in a zero-trust private network you control.

For example, any sort of vulnerability that allows an attacker to perform a man in the middle attack might allow the attacker to access your credentials or data in transit. I explained what packet sniffing is here:

If your repository is hosted on a private network and never traverses the Internet the attacker has to first get into your private network to sniff traffic. They still can if there’s a vulnerability somewhere that lets them into your network but they can’t intercept the traffic as it goes over all the routers on the Internet. I explained routes and routers in this post.

You can take steps to limit access to your GitHub account by using an IP allow list as I wrote about here:

That’s better than free-for-all access to your repository from any IP address, but it still means your traffic is routing over the Internet to get there.

In addition, you have to consider all the IP addresses you have to allow from your local network to use hosted GitHub. You need to add the rules into your own firewall to gain access and that’s not exactly simple. GitHub uses many different IP addresses and domain names. You need to set up the rules and then monitor these addresses in case they change. I wrote about how you can use a customer managed AWS PrefixList to restrict access to GitHub in an AWS Security Group here:

Let’s say people work at your corporate office and they are accessing your GitHub repository. You have to create those rules somehow in your corporate firewall to allow access to GitHub.

And yes, you could simply rely on authentication and TLS. But you should not. I wrote about a few cases where that wasn’t enough already in my posts on GitHub Actions and I can give you many, many more examples.

Any security professional who has experienced breaches and understands how to limit their damage or hopefully stop them will tell you that you need a defense in depth approach with multiple layers of controls. When an attacker bypasses one control that should trip wires and send alerts that help your security team identify the breach. If you only have one control, you can’t do that easily, if at all.

Also, network security is one of the most powerful ways to prevent, limit, and identify breaches. I’ve written about that over and over again in my book and in these blog posts on network security. If you are still not convinced that network security matters, please read these articles for more details.

If you’re with me…let’s take a look at network security options for AWS CodeCommit deployments.

Network Security with AWS Code Commit

With AWS CodeCommit you can lock down access to the service with VPC Endpoints. I’ve written about VPC Endpoints in my above network security blog posts so refer to those if you’re not familiar.

You can create a private repository and restrict access to your own VPC. Now the traffic is no longer traversing all those routers on the Internet. It’s staying within the confines of the AWS network on the AWS backbone.

If your organization has a site to site VPN connection to AWS or a Direct Connect connected to AWS, your traffic can remain on your corporate network as you run commands (such as the one in my last post) to connect to AWS Code Commit. The traffic remains in environments where you and AWS can inspect and monitor it end to end.

If you work outside of your office, you would need to connect over the Internet to get to resources on AWS or at your office. If you want to access CodeCommit in that scenario, you would first need to connect to a device on your corporate network that has access, or a VPN that allows you to authenticate and connect to the corporate network first, and then to AWS. Or, you could log into a bastion host that has access to your VPC and AWS CodeCommit.

The one caveat of only allowing access in a VPC to AWS Code Commit is that we would then possibly be restricted from reaching out to GitHub over the Internet. If we can get to GitHub and to AWS Code Commit on a single host, then that host becomes a kind of proxy that an attacker could use to get from the Internet to AWS Code Commit.

In any case, you will need to think through your architecture and the points at which an attacker may be able to infiltrate a system to obtain access to the network, and thereby obtain access to your repositories.

In the case of the LastPass breach, the point of compromise was a developer’s laptop. The developer had deployed some software to listen to music. That software had a vulnerability in it. I’m not even sure network restrictions were in place. The company was counting on passwords in it’s password manager, and by accessing the developer’s system, the attacker got access to the passwords and thereby got access to customer data.

Different restrictions in different environments

Now, we want dev and QA to mirror production as closely as possible, but in my prior design where we start with GitHub and end up with code in a CodeCommit repository that triggers a build, the code initially comes from GitHub. The development environment somehow needs access to GitHub to clone the repository in my proposed architecture and then somehow access AWS CodeCommit to push the code to the AWS CodeCommit repository.

If we add an AWS VPC endpoint then the resource that has access to public GitHub respositories will need Internet access. In addition, it will need to be within the VPC to access AWS CodeCommit. Perhaps we need to set up a NAT or a proxy or something else in the development environment to allow that to happen. Or perhaps we don’t add the VPC Endpoint in the development environment. It all boils down to risk and what could go wrong.

However, once the code moves to a QA repository, deployments can be fully automated and should no longer require Internet access. The QA environment does not need access to GitHub. The code should never change once it leaves the developer environment and we can use integrity checks to make sure that never happens. So perhaps we can lock it down more tightly to mirror prod, fully automated, and limit access completely with a VPC endpoint. Perhaps in QA we don’t even need access to corporate resources. It depends on what needs to happen in QA and if that can be fully automated.

You might also opt for a Staging environment that is fully locked down and mirrors prod, with prod data, if the QA environment needs special tools or other access that does not mirror prod. It all depends on your specific business needs and the sensitivity of the data. These are the types of questions I help customers of IANS Research with on consulting calls.

Which IP Address is connecting to Git?

Here’s the other problem. Which IP address is connecting to Git from AWS? You might have an EC2 instance with a static IP address connected to it. But what if you switch things up to connect to Git through an AWS NAT Gateway? Luckily we can associate an Elastic IP address with an AWS NAT Gateway.

In subsequent posts I got into a lot of detail about designing your network with an AWS NAT gateway. You may or may not have multiple NAT gateways up and running. But I would suggest that you reserve the IPs you need in advance and configure GitHub with them so you’re not trying to do that in the middle of an emergency.

Starting point — Sandbox

In my case, I’m not going to immediately deploy a VPC endpoint. I’m working with test data in a Sandbox Account and will add this later down the line as I move towards production deployments. First, I want to get my clone function working and then I’ll further test network restrictions.

Network security is one of the big differences between AWS CodeCommit and GitHub and one of the reasons I propose, “why not both?”

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