Use custom compliance project labels to define standard project settings

Please see this epic instead of this issue

Release notes

Problem to solve

Compliance-minded organizations require the ability to implement controls within their GitLab namespace and enforce those controls for regulated projects. One of the biggest challenges is the complexity of implementing a higher-level control point (group or instance level) for settings and managing the inheritance and (optional) enforcement of that inheritance for regulated projects.

Currently, there is no single place to manage all of the settings an organization cares about for compliance and the inheritance models are full of friction and gaps.

Intended users

• Cameron (Compliance Manager)
• Sidney (Systems Administrator)

User experience goal

A group owner can create a custom compliance project label and import a project_settings.yml containing all relevant project settings an organization wishes to apply to a project and set an optional toggle within the yml for enforcement.

Proposal

Accept the import of project_settings.yml in the custom label creation experience. This yml should contain all project setting values (maybe paired down only to the ones deemed relevant to compliance).

1. Create the SOX label
2. Import project_settings.yml
3. Apply SOX to ProjectA
4. ProjectA inherits all settings and values defined within project_settings.yml for the SOX label
5. (optional) If an enforcement toggle is enabled, prevent maintainers from modifying the (select?) project settings

# Example project_settings.yml

topics: 
  - code
  - cat gifs
  - high security
compliance_framework: SOX
repository_size_limit: 15000000000
project_visibility: Internal
merge_request_approvals:
  default_approval_rules:
    security:
      num_required_approvers: 2
      approver_1: mattgonzales
      approver_2: djensen
    compliance:
      num_required_approvers: 2
      approver_1: rob.hunt
      approver_2: mwoolf
  override_approvers_per_mr: false
  remove_approvals_on_new_commits: true
  prevent_approval_by_author: true
  prevent_approval_by_committer: true
enforcement:
  allow_maintainer_edits: false
  allow_group_owner_edits: true

Further details

The two use cases we run into typically are:

1. Let me define things at the group-level (sometimes instance) and have that inherit down into all groups, subgroups, projects. I do want people to be able to modify these settings (standardization and automated inheritance)
2. Let me define things at the group-level (sometimes instance) and have that inherit down into all groups, subgroups, projects. I do not want people to be able to modify these settings in regulated projects (standardization, automated inheritance, and enforcement)"

This is challenging because of the complexity of GitLab groups, projects, and current roles/permissions.

There are also some efforts underway to try and unify or consolidate configuration of important project settings:

• Centralized Security Configuration Management and Auditability
• Settings (Secure & Defend)
• Configuration and Management at a group and instance level

This proposal could help in a variety of ways:

• It provides a single place to configure project settings (alternatively or complimentary: iterating on project templates to include settings carryover)
• Users can selectively apply these labels only to regulated projects or create labels that are generic enough to apply to all projects
• Users have complete control over the settings they want to standardized (pre-define), automate (inherit down into relevant projects), and optionally enforce the pre-defined settings
• It could possibly absolve GitLab of the technical hurdles of implementing backend logic for handling flexible inheritance and enforcement