Create project-level policies framework for deny (Policies MVC)

Problem to solve

After exploring Policies, we should implement the MVC for this feature.

Proposal

Introduce the ability to create and apply a Policy to a project.

Creating a Policy

• A Policy should be definable in a structured way. This should be definable in the UI, not in a version controlled file that's harder for a non-technical user to manage.
• A Policy should include several elements:
  • Effect: the effect that the Policy has on the given project. It should be able to Allow (present in the UI and allow a user to take an action if they meet the condition) or Deny (do not present, do not allow a user to take the action if they meet the condition).
    • For this iteration: Deny only.
  • Action: the action we want to allow or deny access to.
    • For this iteration: hide/prevent access to any/all of the project Repository, Merge Requests, CI/CD, Operations, Security & Compliance, and Packages.
  • Resource: the projects and groups this Policy applies to.
    • For this iteration: we can omit this and map a Policy 1:1 to projects, instead of a 1 to many.
  • Condition: a condition that, if met, results in the allowance or denial of the action for the user. We should be able to write conditions like Member:operations-leads to check if a member is a group to allow/disallow something.
    • For this iteration: do a simple check of a user's group membership. I should be able to write a project Policy that checks if a user is a member of a particular group.

The use case we are trying to solve for is separation of concerns: some organizations want to separate Dev and Ops in their organization into dedicated roles. The proposal would allow this to happen by:

• Creating a separate group for the Operations team,
• Creating a Policy to deny access to the project's Repository if a project member belongs to the Operations group,
• Applying the Policy to any relevant projects.

Policy UX (TBD)

• There's a possible gap between what the documentation says I should be able to do vs. what a Policy is allowing me to do on a project.
• Whenever this gap exists, explain this to the user:
  • Create a perceptible affordance via an icon or banner on relevant pages.

An example, may be the project settings page:

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.