So recently, I have been experimenting with DigitalOcean droplets and GitLab ( https://about.gitlab.com/2016/04/27/getting-started-with-gitlab-and-digitalocean ). It was an incredibly quick and easy way to get a GitLab instance up and running.
To make GitLab instance as secure as possible, we can
- Configure GitLab as https only and use ssl certs (letsencrypt)
- Restrict ssh login to key only (no password)
- Use strong ciphers and strong nginx config ( http://cipherli.st and http://securitychecklist.org )
- Firewall ports other than 22/443 (for ssh and ssl)
- Disable account signup in GitLab (optional)
This is good to block remote attacks. My concern is having sensitive unencrypted data out there on some hardware you don’t have physical access to. The physical hard drive is still accessible and is unencrypted.
Ideally, we could just do a full disk encryption of the droplet. However, with DigitalOcean droplets, modifying the partition table is not supported. So I read up on dm-crypt, which could be used to create an encrypted volume, that could store the sensitive data ( https://www.digitalocean.com/community/tutorials/how-to-use-dm-crypt-to-create-an-encrypted-volume-on-an-ubuntu-vps ).
I have used an omnibus install of GitLab on Debian Jessie. So, what important data should I store in this encrypted volume? I’ve come up with these so far.
- All the repo data stored in git-data (in /var/opt/gitlab/gitlab-data), should be moved and gitlab can be reconfigured to use the new path via git_data_dir in gitlab.rb
- gitlab.rb and gitlab-secrets.json can potentially hold sensitive information, so those can be moved to the encrypted volume and then symlink’d
- When gitlab makes backups, the backups should be placed in the encrypted volume instead of the unencrypted /var/opt/gitlab/backups. GitLab can have backup_path reconfigured in gitlab.rb
Can anyone think of any other parts of gitlab that could contain sensitive data (mainly source code) that should be moved to the encrypted volume?