Security policy enforcement across multiple top-level groups
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
This is a thorny issue and I would be happy to set up some time to chat about it---and I think there are some solutions architects and other professional services people with experience here as well.
Problem Statement
Security policies are an important feature for Ultimate customers, who are often on self-managed or dedicated instances. Large customers can have hundreds or potentially thousands of top-level groups (TLGs). Currently, the security policies feature seems to be designed mostly for the gitlab.com case of a single TLG, and it's not clear how to practically apply a security policy across a self-managed or dedicated instance.
This is a somewhat complex ask and I can imagine more than one way to approach it. There are some specific issues that could be fixed, but also some vaguer questions about how we intend customers to use the feature. To try to make it tractable I'm going to both list some known specific problems here, and give some use cases to help think about the bigger picture.
Specific Challenges
- A policy project can be linked to a group other than the one that contains it, which allows for enforcing a set of policies across multiple TLGs. However,
- There is no UI for linking policy projects in bulk, and the UI for doing it on a single group is awkward to use.
- Any policy project links can be unlinked by a group owner, which prevents a central DevOps team "enforcing" policies.
- You could potentially work around these issues by writing your own automation, but,
- Linking can only be done programmatically via a GraphQL mutation. There is no REST API.
- There does not appear to be any way to find out if a policy project is linked via API (in GraphQL or REST), so you can't report on policies or find policies that have been unlinked and correct them.
- It's hard to tell how policy scopes should be used in a multi-TLG scenario.
- It's not clear to me from the UI or documentation how the scope defined in a policy relates to TLGs other than the one containing the policy (for example, if you set scope to "all but exceptions," can you list exceptions in other groups?)
- You can use compliance labels to control scope, but this is very clumsy across multiple TLGs, as you have to create a separate compliance label in every group and list them all by ID in the policy scope (the UI editor won't let you do this either since it doesn't know about the compliance labels in other projects)
Use Cases
Here are a couple of user personas that I think cover the requirements I see from Ultimate customers:
- I have a central DevOps team that promulgates best practices and compliance requirements across my organization. I would like to build a security policy that enables basic scanners and make it mandatory across the entire GitLab instance, so that groups and projects (owned by other teams) can only disable it with permission.
- I am in the process of rolling out a security scanning policy across my organization to improve our general AppSec posture. We are enabling the policy department-by-department to help us manage the onboarding workload and get feedback from earlier adopters. I would like to have visibility into what groups and projects have the security policy applied, and reporting on our overall completion of the rollout.
- I have developed a security policy that should be applied to projects with a certain specific requirement. Let's say for the sake of example, software that implements Sarbanes-Oxley controls---our policy is that these projects need multiple eyes on all changes so we want to enforce this with a merge request approval policy. There are projects with this requirement that are owned by different departments that work out of different top-level groups. I need a way to apply the policy to the projects that require it, and I need to be able to audit that the policy is being used as needed both from the bottom up (e.g. check a project to see if the policy is applied) and top down (e.g. see a list of the projects with the policy applied, across the instance).