### Overview GitLab's permissions model is designed to meet the needs of most organizations with little to no configuration. The [existing roles](https://docs.gitlab.com/ee/user/permissions.html) are horizontally permissive, in order to allow users to shepherd issues from idea to production. We supplement these roles with feature-level configuration, that allows instances to have some control over who's able to do what. For large enterprises operating under scrutiny, however, this isn't enough. To fully adhere to their own hard-to-change internal rules (sometimes in place due to regulatory requirements) requires adding an unacceptable level of per-feature configuration into GitLab. For these organizations, GitLab's lack of flexibility becomes a very hard pill to swallow. In order to solve this problem, we should consider a layer on top of either our existing permissions model (e.g. custom roles), or an additional permissions layer on top of our features that provides a custom definition of what the 5 roles is and isn't allowed to do. This is the essence of a Policy in GitLab. They're a counterpart to [Automations](https://gitlab.com/groups/gitlab-org/-/epics/218); instead of determining an additional action to take, they determine a custom prerequisite that must be fulfilled before an action can be taken. Why is this better than a custom role? It allows instances to create complex workflows. An example prerequisite might have logic similar to a custom role (creating a new issue requires Maintainer permission or higher), but it can also unlock more complex rules that aren't possible with custom roles (creating a merge request in `Project A` requires membership in `Frontend`). ### This epic We'll introduce the basics here: * Create a new sidebar item at the group settings level called "Policies", * Allow an Owner to create, update, delete a Policy. Policies adhere to a `x requires y` framework. A user must specify two things when creating a Policy: * The action to restrict, `x`. * The prerequisite that must be fulfilled, `y`, that enables `x`. Policies should either be mandatory (action is blocked if prerequisites aren't met) or not (warning/logged for further investigation, if needed). For the first iteration, we should focus on workflows that are typical of compliance-minded organizations. Segregation of duties is a good one - example, the person who authors a merge request can't be the same person who merges to master. ### Beyond this epic Once the foundation for Policies has been laid, we can roadmap and prioritize additions to the (`x requires y`) framework, like: * Adding features (more `x`). * Adding requirements (more `y`). Enforcing adherence to a CONTRIBUTING.md. See [AWS Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html).