Proposed changes to improve required pipeline configuration
Problem to solve
Enterprise organizations are varied in their policies and procedures. This is most apparent when organizations use GitLab within their regulated environments and must implement specific controls or processes to maintain compliance with their policies and, by extension, the regulations which govern their industry.
One of the most cited pain points from customers using GitLab is the lack of control to implement and enforce an organizational-level compliance pipeline configuration. Currently, organizations do not have an effective way to implement a compliance pipeline configuration their users can consume and that does not create a potential for catastrophe for emergency changes that need to be deployed.
Intended users
User experience goal
An administrator should be able to define a necessary compliance pipeline configuration that is consumed, programmatically, by projects. A user should have the flexibility to extend this configuration and request an override or exception in certain emergency or high priority situations (e.g. critical production fix, zero-day security patch).
Proposal
- Implement the proposal in &3156 (closed)
- Remove the deprecation status of required pipeline configuration
- Rename the feature to "Compliance Pipeline Configuration"
- Bring custom compliance framework label creation to the instance-level
- Modify the inheritance of this feature to affect only projects labeled with compliance framework project labels
- Add a button to specific jobs (e.g. jobs with elevated permission requirements) for users to notify the list of job approvers to request an override or exception
- Introduce a feature to empower developers to request an override of a job result or failure only for jobs in the Compliance Pipeline Template and allow the project pipeline to succeed; Potentially leverage two-person approvals for this
- Add a list of job approvers similar to MR approval rules, but specifically for pipeline jobs
- Surface intelligent data within merge requests about these results or actions
Further details
- Enterprise organizations generally prioritize auditor wants and needs first
- It is more expensive and less efficient to fix non-compliant changes retroactively versus catching these changes earlier
There are two types of enterprise customers who need this functionality:
- Enterprise who manage their compliance pipeline templates at the organizational level (instance-level; self-managed)
- Enterprise who manage their compliance pipeline templates at the organizational level and/or the group-level
Regulated organizations cannot rely on passive or informational non-compliance and require an active, enforceable workflow for their pipelines.
After conducting a multitude of customer interviews and exploring a variety of solutions to this problem space, it has become clear the 1 type of enterprise will consider the complete deprecation of required pipeline configuration a "serious regression"; the 2 type of enterprise are largely satisfied with the proposal in &3156 (closed); however, there are at least two enterprise who wish to have this control (defining and enforcing a compliance pipeline template) at both the instance and group-level.
Customer Quotes
Once a build has been published via a non-compliant process we are forced to rely on downstream controls to prevent it propagating elsewhere. However, if our software repositories only contain valid builds then the problem doesn't arise. The sooner we catch serious non-compliance the cheaper it is to fix and the less chance of further non-compliance downstream.
For compliance-related processes we can't always start from a position of wanting to make the developer happy. More likely than not we're trying to make the auditors happy and, if we can, find an implementation where the developer feels they've been treated fairly.
Reference issue link (internal use only)
Not sure I understand why Group Owners should be given the role of creating these templates as we would want these templates applied to multiple groups. Can we create these templates at the system level and have them apply to multiple groups?
Reference issue link (internal use only)
What does success look like, and how can we measure that?
Success for this experience is an enterprise using Compliance Pipeline Templates and usage of the override/exception mechanism.
What is the type of buyer?
Large, regulated enterprise with strict compliance requirements.
Is this a cross-stage feature?
Yes. This involves, at minimum, ~"devops::release" devopsverify