| What I'm missing is a different security model than the current `If an endpoint can push to gitlab, it is trusted and can execute code server-side`. There is no (current) way to enforce a 2fa step in order to push to a repository, and while you can technically implement them, that doesn't mean much, due to the nature of `git push`. What I want is a 2fa-enabled review boundary between "commit" and "execute", which currently isn't possible. Protected branches can be unprotected without an auth step. There's nothing on the server-side that signs `gitlab` generated merge-commits in the commit graph, so no way to distinguish them from other merges. There's no security boundary to change the deployment details, or to modify the deployment pipeline to run from a different branch. Basically, I'd want a way to ensure that there's an authenticated hand-off between "commit" and "deploy" steps on the chain. Also, it'd be nifty if one could get gitlab to maintain a version number, increasing with every merge request merged, in order to get smooth tagged builds when MR's are used. |
In GitLab 10.7 we added branch unprotecting restrictions that can be managed through the API to restrict who can modify protected branch rules https://docs.gitlab.com/ee/api/protected_branches.html#prote..., and we'll be adding a UI to manage this soon too. I created https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 to add an auth step for changing protected branches as well.
I'm interested to know more about the version number improvement you suggest too. There are a few similar proposals like automated tagging on merge https://gitlab.com/gitlab-org/gitlab-ce/issues/22363.