I’m currently setting up a development workflow with a protected production branch in GitLab with the hopes of using GitLab CI to handle the build & deploy steps.
How can I protect my production SSL credentials from other developers on the project? I realize GitLab CI has secret variables, but there doesn’t seem to be a way to prevent a developer from dumping these using a test build on another branch of the project.
Am I missing something, or is there different way to lock down access to the production server?
I’m actually working on this right now, and I’ll write up a full description on my blog later.
The crux of how I’ve handled it is (I used docker to build, not just general shell):
Dump all of my production access keys in a root-only folder (e.g. /etc/deploy/keys). Probably best to make sure they’re associated with unprivileged app users.
Fire up ssh-agent as root, give it a specific bind point (e.g. /etc/deploy/agent). Make it root user, docker group (with full read/write/execute for both user and group).
Add the keys from /etc/deploy/keys to the ssh-agent (as root)
Set up the config.toml file to add /etc/deploy/agent as a volume, add SSH_AUTH_SOCK=/etc/deploy/agent to the environment for that runner
The end result should be:
Private keys only readable by root
Private keys usable within docker due to the use of the agent
Therefore, developers do have the ability to connect to the remote machines and feed actions in (unavoidable), but they should have no way to actually steal the keys themselves. Anything more than that and you can’t actually deploy at all AFAIK.
Hi, did you get around to write it on your blog? I’ve read up on your answer above and still can’t get a good understanding as to what to do. I’m even starting to consider using fork and assign a specific runner to the main project for deployments.