Discovery: Allow admins to define Compliance rules within GitLab
Problem to solve
One of the biggest challenges of solving compliance problems for organizations is the variance between each organization for what constitutes a "compliant" status. Every organization has different policies and even the same policy, e.g. "Password Policy", can vary significantly in its requirements and enforcement characteristics.
Within GitLab, customers cannot adequately and quickly translate their internal organizational policies to the GitLab groups and projects they operate. There is a litany of possible workflows, actions, and behaviors users can take that can require constant monitoring and enforcement. There's no way to quantify what makes a "good" action or activity and what makes a "bad" one.
Intended users
- Sidney (Systems Administrator)
- The management stakeholders who adhere to any auditing process. To be defined in a new Compliance Persona
Further details
Use Case
I'm an admin
that wants to define rules for my GitLab instance to enforce organizational policies and processes so I can remove risk vectors and reduce the overhead of managing this manually across a complex GitLab environment.
Benefits
- Reduces administrative overhead of managing compliance across multiple groups and projects
- Provides flexibility for an organization to customize their GitLab compliance program
Given the potential for friction in this type of implementation, we can leverage #33260 (closed) to allow for "exceptions or overrides" for any particular rule.
We can also provide an API-driven experience for larger, complex organizations with complicated processes that would offer flexibility for their GitLab implementation. The current MVC can move us in that direction.
Proposal
This is a broad discovery proposal and will be broken out into smaller, iterative steps later.
Overhaul the Push Rules
experience within the Admin Area
and rename to Policies
.
Add five sections to the new Policies
page:
- Commits
- Merge Requests
- Pipelines
- Security
- Memberships
Move and rename the current Push Rules
section to a new Commits
expandable section.
Move the current MR Approval rules
into the Merge Requests
expandable section.
Create a Pipelines
expandable section for CI/CD-related settings and policies (e.g. required pipelines, pipeline configuration templates).
Create a Security
expandable section for scanning policies (e.g. frequency, type of scan, conditions to scan)
Create a Memberships
expandable section for users and permissions (e.g. disable private repos, add whitelisted domain(s), service accounts)
Consider an experience that enables customers to define rules in a structured, efficient way, e.g.:
Action | Detail | User Scope | Project Scope | Group Scope |
---|---|---|---|---|
Deny | JavaScript | for All Users
|
in All Projects
|
in All Groups
|
Deny | Vulnerability Exceptions | for All Users
|
in Project A , Project D , Project G-M
|
in Group A , Group B
|
In the MVC for this feature, these rules should be used to flag an MR when a rule isn't followed in a compliance check section of the modal.
Permissions and Security
This would be available only to Admins
initially.
Documentation
Availability & Testing
What does success look like, and how can we measure that?
- Number of rules defined by our customers
- % coverage of the rules, e.g. how close to 100% are we to covering all rule configurations customers need?