GitLab offers a way to prevent pushing files with secrets that have a specific filename, but this doesn't go far enough because it doesn't scan files for secrets.
AWS's git-secrets (https://github.com/awslabs/git-secrets) provides a way to scan files but it requires users to install it on their local machine. This is great but it is hard to ensure users are compliant with best practices.
A hybrid approach would be to have git-secrets on both client-side and GitLab server-side checking for secrets. GitLab can reject a push if it fails a scan, and users can use the same git-secrets tool to resolve the problem from client-side.
Demonstrate the use of git-secrets, with aws rules, (https://github.com/awslabs/git-secrets) in a GitLab server-side update hook.
Extends gitlab Docker image to include git-secrets, with aws rules, in a custom update hook.
Start gitlab
container in background:
docker-compose up -d gitlab
Tail the logs to make sure it came up properly:
docker-compose logs -f gitlab
Or watch the state for health status of healthy
:
watch docker-compose ps
Open a browser and navigate to http://localhost:8081 and initialize the
root
password.
For this demo we will use the following as the password:
Welcome1
Once logged in, create a project under root group called:
my-repo
A minimal Docker Alpine container with git and git-crypt installed to test git-secrets.
Start git
container:
docker-compose run git /bin/sh
From within git
container; clone my-repo
project using root/Welcome1
credentials:
git clone http://gitlab:8081/root/my-repo.git
Change to my-repo
directory:
cd my-repo
Verify you are able to push a non-secret change:
echo "no secrets here" > README.md
git add README.md
git commit -m "Update readme"
git push -u origin master
Verify you are able to push the default allowed AWS example key:
echo "AKIAIOSFODNN7EXAMPLE wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" > README.md
git add README.md
git commit -m "Allowed example secret"
git push -u origin master
Verify you are NOT able to push an AWS secret key:
echo "AKIAIOSFODSECRETSKEY wJalrXUtnFEMI/K7MDENG/bPxRfiCYSECRETSKEY" > README.md
git add README.md
git commit -m "Oops"
git push -u origin master
Verify you are able to override GitLab blocking a push with
.gitallowed
file:
echo "SECRETSKEY" > .gitallowed
git add .gitallowed
git commit -m "False positive"
git push -u origin master
Verify you are NOT able to push another AWS secret key:
echo "AKIAIOSFODVERYSECRET wJalrXUtnFEMI/K7MDENG/bPxRfiCYVERYSECRET" > README.md
git add README.md
git commit -m "Oops"
git push -u origin master
Backout the commit:
git reset HEAD~1
git checkout README.md
Verify you are able to push git-crypt encrypted files:
git-crypt init
echo "my-repo-crypt.key" > .gitignore
git-crypt export-key my-repo-crypt.key
echo "my.secrets filter=git-crypt diff=git-crypt" > .gitattributes
echo "password=muMj8RUUdJtzGazK" > my.secrets
git add .
git commit -m "git-crypt example"
git push -u origin master
Note that .gitallowed
works by adding secrets allowed to the git repo
config file for the project on the gitlab server. It would require
manual removal of a secret allowed, if that secret allowed was removed
from the .gitallowed
file.