Keep your gitlab branches safer with these 2 steps
Do you push a lot of code to gitlab? Do you work on projects together a lot? Then make sure branch authorisations are set properly. Otherwise, others who shouldn't have rights can do damage by pushing dangerous code. Our two steps keep your gitlab branch secure.
Customer projects must always be safe. That is why we always test for gitlab rights and the proper protection of keys for third parties. Brilliant code wrapped in a nice jacket can ensure that your data is exposed and so can steal your data or shut down an application. Making organizations dependent on your application, the victim. An angry customer on the line is the least of your problems.
For whom do you have to protect the rights properly? Users already have certain access to your repository. Is the user already not well shielded? Why is it so important that this is shielded at branch level?
Accidentally pushed to release branch
A developer gets access to your project to contribute a new feature and therefore needs write permissions for the repository to contribute. The branches are not yet protected and the user, for example, pushed his prototype accidentally to a release branch. This branch is released by automatic deployment. The prototype is now on the server and can therefore make your application piece. How do you prevent this?
Roadmap
Follow the two steps and you are completely safe.
Step 1, shielding your branches
Safely shielding branches that are used for deployments or releases. In Gitlab this can be set by means of "protected branches" which you can find as follows:
- Go to the correct repository you want to protect
- Go to the settings -> repository
- Click on protected branches
- Here you will find the settings for protecting your branches
- Select the branches / wildcard for the branches you want to protect.
- Select the people who are allowed to have permissions to merge the request to the branch
- Select the people who are allowed to have permissions to push changes.
- Save the changes, "Protect"
A safe way of working is to screen the branches that are released to your live environment to push. This prevents you from accidentally pushing a change to the wrong branch, because it has to be approved in Gitlab first by means of a merge request.
Your branches are now safe through the previous step, but other branches may still be dangerous. Now you will probably think, 'easy, then I protect it too?' Perhaps you think, 'what is unsafe? he / she has no access to the secured branches?' The problem is here in the possible keys that are used for automatic deployment.
Step 2, shielding your keys
For example, a user can deploy his unsecured branch since the keys needed for deployment are not yet protected. The keys can also be protected from the protected branches. This can be set by adding your deployment keys and putting your key "protected". This protects the key and can only be used in your secured branches.
Automatic deployment without any key is possible. If you want to keep this safe, make sure that the deployment can only strictly deploy the secured branches. It should therefore not be possible to adjust your deployment settings in the project or in a branch.
Voila, your gitlab settings are a lot safer because of these two steps!