A major selling point of AWS CodeCommit is that it allows for encrypted repository data, which can be painful to set up with other repository services. But while this extra security is a great feature, cloning, configuring, and working with a CodeCommit repository can be surprisingly finicky, as I recently discovered while onboarding to a new project.
Here are some of the common “gotchas” we ran into and how you can avoid them on your next project.
MacOS Access Denied (403s) on Initial Clone
There may be a few issues that cause 403s on the initial clone (despite ensuring that your credentials are set correctly). One that can be harder to detect is the configuration of your git credential helper. According to the AWS CodeCommit docs, there are two possible issues:
- The AWS Region configuration in the AWS CLI may differ from the configuration of the repository.
- There may be credentials saved in the keychain access utility that are outdated.
The fix for the first is simple: verify that the region is configured correctly by running aws configure.
Addressing the other is more complicated. On OS systems, the default Git configuration uses the keychain access utility to save credentials. Since the personal access credentials to a CodeCommit repository are frequently changing, the credentials cached in the keychain may be outdated. To check your configuration, access the gitconfig file that’s storing your credential helper configuration. If you’re not sure where that is, run:
git config -l --show-origin | grep credential
This will output lines that follow the pattern: file:/path/ credential.helper=osxkeychain. You may have several of these gitconfig files. Make sure that the one you open and edit ends in gitconfig and not .gitconfig.
Once you have located the file, there are a few ways that you can modify the osxkeychain helper. The method that worked best for our situation was changing my gitconfig to look something like this:
[credential "https://git-codecommit.us-{{YourCodeCommitRegion}}.amazonaws\.com"]
helper = !aws --profile {{YourCodeCommitProfile}} codecommit credential-helper $@
UseHttpPath = true
[credential "https://github.com"]
helper = osxkeychain
Essentially, this tells Git to use a certain configuration when accessing repos from github (my previous repos and how I was using osxkeychain to authenticate remain intact) but to use the credentials stored in my AWS configuration when accessing repos from codecommit.
Check Expired Credentials
In our project, CodeCommit uses an AWS CLI credentials profile, and the longest configurable timeframe for its credentials session is twelve hours. This means that after that session time is up, the credentials for CodeCommit (aws_access_key_id, aws_secret_access_key and aws_session_token) will reset.
As a result, we need to reconfigure our local environment accordingly in order to use the repository every twelve hours. If we fail to do so, trying to run any git command will throw a 403 error along the lines of “fatal: unable to access your-repo: The requested URL returned error: 403”.
If you previously had the repository cloned and working correctly but you haven’t recently updated your credentials, this error likely indicates that your credentials have expired.
Utilize git-remote-code-commit
While technically unnecessary to clone a CodeCommit repository, one of my colleagues found it helpful to utilize AWS’ git-remote-codecommit tool for interacting with the repository. The tool extends Git and does not require additional Git credential set up.
It does involve more work to get it initially set up (especially if you don’t already have a recent version of Python/pip installed), but some of my teammates found that it was easier to set up their credentials.
Have you run into other issues while configuring a CodeCommit repository? I’d love to hear about them and how you addressed them.