Skip to content

Lock project variables to a specific branch(es)

Summary

Build variables, as I'm sure many of you are aware, are currently insecure in a team environment where multiple developers have write access to the repository, even if there are protected branches. The way things currently work, if you have more than one developer with write access, then using variables to hide sensitive information simply doesn't work. This essentially renders them useless, because that's the only purpose I can see for them. I don't need to store non-sensitive variables in the project settings when I can create variables in the .gitlab-ci.yml script itself and get all the features that version control has to offer for those variables. I have come up with a rather simple solution for this.

Steps to reproduce

Simply edit the .gitlab-ci.yml script to run on any branch, and add a command such as echo $MY_SECRET_VALUE to your script.

Expected behavior

A simple way to prevent an issue like this, which would use the already existing protected branch features, is to lock variables to specific branches. So if someone edits the .gitlab-ci.yml script and runs it on another branch, the variables will not be available on that branch, and will not be shown. In this way, you can prevent users from displaying variables that may store sensitive information, by simply locking them to a protected branch. Nobody without the permissions required to view the variables within the GitLab website would be able to push a change to the .gitlab-ci.yml script on that branch without it being reviewed first by someone who does have write access to that branch. As a result, this would protect project variables from being circumvented by a simple modification to the .gitlab-ci.yml script.

Implementing this feature would add another positive side effect as well. Say I want to have an SSH key for my master (development) branch, and a different SSH key for my production branch. Or if I want to provide different API keys depending on the branch the build script is running in. If this feature was implemented, it would provide the ability to use it for scenarios like this as well. Two features for the cost of one. This would require that the implementation allow the user to set variables with the same name for different branches. No two variables should be able to have the same name for a single branch. However, it should be possible for a variable locked to the master branch to have the name, MY_SECRET_KEY, and a variable locked to the production branch to have the name MY_SECRET_KEY as well.

Ideally, it would be possible to lock the variable to more than one branch. This is because it's possible that a user may want to use a variable with the same value for multiple branches. Scenarios like this could quickly become cumbersome if the user could only lock a variable to a single branch.

If GitLab is to be used by enterprise customers, this is honestly something that must be done. Security is a very important consideration when it comes to any project. And neglecting a glaring flaw like this, I feel, will prevent many people from using GitLab. Competing services such as TFS, TeamCity, etc do not have these problems, and anyone who is even slightly concerned about this is going to avoid GitLab because of it. In a large project that has hundreds of developers, it simply isn't realistic to trust that none of your developers is going to go rogue because the coffee was cold, and use any information they can get to their advantage. I love GitLab, and I would like to see it become a widespread success. I think implementing this is crucial to GitLab's success.

Links