I’d appreciate any info on what options exist for allowing Gitlab users to control changes to all feature branches within a given repo? I am aware of and already use Merge Request approval for merging to Production / Master.
In particular, we store configuration management code in Gitlab and I work in an Ops team. I would like to control changes to a named file in a standard path containing sudo rules that might be made in feature branches by Dev teams and applied to hosts in the estate I manage.
I am somewhat aware of push rules and webhooks but neither seem to give me an out-the-box means to control (approve/reject) file contents centrally. We are at the design stage at present and need to monitor all access granted in our estate.
I’m not quite sure if this is what you are after, but once you have restricted who can merge into your protected branches, you might want to set CODEOWNERS for these specific directories / files.
The concept of specific file change “owners” (codeowners) is applicable in our case - that would be our Ops team.
However, it seems that these only apply to Merge Requests whereas I would like functionality that allows us to control changes to named files during pushes to the repo.
In other words, is there a means by which Ops can control changes to a “sudo-rules” file in all branches in a given repo such that Devs cannot change sudo-rules without approval from Ops.
The repo is populated via git push and is part of a CI:CD pipeline.
It’s a little unusual to have developers write code that is not in a merge request. If you do want to keep that workflow, I’m not sure whether GitLab has anything built in that would help.
If push rules cannot encode the rules you want, personally I’d be inclined to write a custom lint that would cause the pipeline to fail if a commit contains a patch in the relevant file by a user that is not in an allow list. The allow list could be a CI variable (these can be files) which would allow you to change the members of the Ops team without pushing another commit to the repo.
Ultimately the branches are merged but Ops need to consider the security of our estate as a whole - including the machines that are configured (using our config management system) via Developers’ code in feature / dev branches before they are merged to Production / Master
Your custom lint idea is so close to what I’d ideally have that I will propose it as an option. In particular, I could use it to write a communication to Ops who need to monitor (ideally control) such changes but don’t want to necessarily be the people who push the changes.
So, your idea would allow us to know about such changes after they are made which is retrospective but much better than being unaware.
I think the problem with controlling such changes is that I am trying to use source control software to enforce business logic (operational process). Merge requests make sense as operational processes in their own right whereas enabling Ops to ensure the contents of particular files on sandbox/test systems are as Ops would like them to be is not really source control.
One last thought: you could make the files that need to be secured CI variables themselves. You would need to write a bit of extra code to cat those variables into actual files (or whatever) but that would mean they cannot easily be changed. On the other hand, you would not longer be versioning those files…
It doesn’t make sense to maintain files that are ‘owned’ by different teams in a single repository. I would definitely split it and move your ‘sudo’ files to a separate repository where Developers won’t have push access.
Afterwards they can curl, git submodule or whatever you can think of to fetch the files from your repository as they need.
Even with the custom lint in the pipeline, nothing stops Developer to remove that Job from pipeline in a branch, basically avoiding your check.
In our case, Ops would like to devolve the keying of sudo rules such that Devs can build their own applications in pre-prod then Ops review the applications (and sudo config) before Prod build-out. Ops would also like to approve or at least monitor the sudo rules that the Devs program in their branches to ensure they are aware of the security being applied on our estate. The main reasons for the requirement are velocity (time to market) for our business and convenience (avoid ticketing system) for Dev and Ops.
This requirement is an edge case for us - the config management code that Dev and Ops own is indeed typically kept in separate repositories as you expect. Essentially, I am trying to make the most of the set-up we have in place which is not ideal for this particular purpose.
I take your point regarding the lint in the pipeline. On the upside on that front, we can detect who changed what file via Git and so periodic checks would implicitly highlight any amendments to pipelines in feature/dev branches (which are subject to merge request before becoming Production / Master).
Fundamentally, I accept that we would be bending Gitlab out of normal shape & practise for the reasons highlighted and I could include that stipulation when I propose the custom lint option. Your approach of Ops managing the sudo rules (with all branched protected) in their repo is the natural solution but introduces delay and procedural complexity. Giving Devs access to adjust only the sudo files in the Ops repo is another option.
Overall, this conversation gives me enough food for thought, so thanks to you and snim2 for helping.