## Release notes To better support the scale of enforcement required for our security and compliance users, we are increasing the limits of our security policies to support X merge request approval policies and Y scan execution policies. The increased limits better align with the ability to granularly scope policies to be enforced across instances and namespaces from a single, centralized security policy project. ## Problem Currently we have limits for each policy type, but customers are constrained, especially when it comes to centralized policy management at scale. * MR approval policies - limited to 5 per SPP * Scan execution policies - limited to 5 per SPP, limits on number of actions * Pipeline execution policies - limited to 5 per SPP + limited to 5 policies applied to the same project at a time ## Proposal 1. Configure a default limit of 5 policies per SPP for each policy type. 2. Allow for instance admins to increase the limit to up to 20 policies per SPP. 3. Continue to implement limits specific to each policy type (e.g. only 5 PEPs applied to a project at a given time). ## Sub-epics - [ ] https://gitlab.com/groups/gitlab-org/-/epics/16929+ - [ ] https://gitlab.com/groups/gitlab-org/-/epics/17453+ - [ ] https://gitlab.com/groups/gitlab-org/-/epics/17454+ - [x] [Add basic error handling/validation to prevent users from exceeding the limit](https://gitlab.com/groups/gitlab-org/-/epics/10622) - [ ] Complete https://gitlab.com/groups/gitlab-org/-/epics/9971+ to increase our performance and allow for higher limits - [ ] Performance evaluation to identify new limits - [ ] Implementation of new limits - [ ] Users can create a "Disabled" Policy when reach limits - [ ] User CANNOT "enable" disabled policy when reach limits <details> <summary>Previous proposal</summary> 1. Clarify whether the limitation is a limited number **per development project** or **per security policy project** 2. Re-evaluate these limits and consider raising them. We have several features that are likely to increase the number of total policies that users want to implement per project: 1. Group-level Security Policies 2. [Auto-resolve when no longer detected](https://gitlab.com/gitlab-org/gitlab/-/issues/233846/) policies 3. [Auto-dismiss when irrelevant](https://gitlab.com/gitlab-org/gitlab/-/issues/299552) policies 3. Re-evaluate the UX to ensure that good messaging is presented to the user when they reach this max policy limitation. Some scenarios to consider include the following: 1. A user links up a new security policy project to a development project. The security policy project has 8 policies in it. The upstream group has 7 policies in it. Together this puts the project over the limit with a total of 15 policies. </details> ## Design * Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/442415/ * Figma: https://www.figma.com/file/PxITlQcMbvWTMbhM1ghcwv/policy-Small-design?type=design&node-id=1520%3A8206&mode=design&t=PnUA5Oe62msD9rl6-1 | On the choosing policy type page | On edit policy page | |----------------------------------|---------------------| |  |  | <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> _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._ <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION-->