Add a Getting Started section to security policies section of documentation
Problem to solve
Further details
Proposal
A common point of feedback and confusion from customers today is about how best to configure security policies and what the impacts are based on the decisions they make.
I would like to include a few diagrams that we highlight in our DevSecOps Overview slides (internal), which cover how to set up policies based at different levels of the GitLab hierarchy:
- Enforce policies at a group level (enforcing all projects in the group, including the security policy project)
- Enforce policies across multiple subgroups by linking up to a security policy project in a Security subgroup
- Enforce against individual projects granularly by creating a security subgroup and linking to the security policy project at the project level
- Enforce policies at the project level
There are topics as well that can be hangups for customers that we can elaborate on:
- How many links/policies can theoretically be enforced/inherited against a project (based on the total number of groups/subgroups that can be nested)
- How links appear and how policies appear based on the inheritance
- Recommendations and limitations regarding project/group owner access -- we recommend that group/project owners are limited as much as possible
- Where we are heading next, highlighting our roadmap plans, links to epics
Who can address the issue
@rdickenson Working with @g.hickman
.