### **Problem to solve** Historically, teams build out their own access control for their feature at the project or group level. This leads to disparate user experiences, separate authorization logic, or redundant performance improvements. #### Pain Points * **Fragmented Implementation**: Teams independently build access control for features, resulting in inconsistent user experiences and duplicated authorization logic * **Developer Productivity Impact**: Domain experts spend time on authorization infrastructure instead of core feature development * **Performance Redundancy**: Each team implements their own performance optimizations for authorization checks * **Audit Complexity**: Customers must aggregate data from multiple APIs to understand resource access, creating operational overhead * **Scaling Limitations**: Existing controls (protected branches/environments/tags, group/project settings, IP allowlists) don't scale effectively to Enterprise needs #### Examples of Fragmentation Below are few examples of various access controls that have been built out by different teams. These controls continue to be added on or duplicated at the group or project level to achieve a level of Enterprise scaling, but often falls short. * Protected branches, environments, or tags * Group or project settings that determine what a user can do. * IP Allowlist ### Proposed Solution Implement a unified access control plane using Attribute-Based Access Control (ABAC) that operates consistently across organizations, groups, and projects. Allow teams to plug in their resources into an out-of-the-box authorization plane that is flexible and meets enterprise needs. ### Functional Requirements #### FR-1: Unified Authorization Framework **Priority**: P0 * **FR-1.1**: The system SHALL provide a single authorization service that all GitLab features can integrate with * **FR-1.2**: The authorization service SHALL support ABAC model with policies based on: * Scope (Organization, Group, Project) / OR implicit * Principal (Users, Roles, Service Accounts) * Resource * Conditional Evaluation including * User attributes from identity * Defined by feature (IP allowlist, environment regex, branch regex, etc) * Actions (read, write, delete, approve, etc.) * **FR-1.3**: The system SHALL maintain backward compatibility with existing RBAC (Role-Based Access Control) implementations #### FR-2: Hierarchical Policy Inheritance **Priority**: P0 * **FR-2.1**: The system SHALL support policy definition at organization, group, and project levels * **FR-2.2**: Policies SHALL cascade from organization → group → project without override #### FR-3: Policy Management Interface **Priority**: P0 * **FR-3.1**: The system SHALL provide a UI for creating, editing, and managing access policies * **FR-3.2**: The UI SHALL display effective permissions for a given user-resource combination (policy preview) * **FR-3.3**: The system SHALL support policy templates for common use cases * **FR-3.4**: The system SHALL validate policies for conflicts and logical errors before activation * **FR-3.5**: The system SHALL provide policy versioning and rollback capabilities * **FR-3.5**: The system SHALL provide a REST API to support end-user automation use cases #### FR-4: Unified Audit and Compliance API **Priority**: P0 * **FR-4.1**: The system SHALL provide a single API endpoint to query access policy * **FR-4.2**: The API SHALL return access information including: * Who has access * What level of access * Why access was granted (which policies) * When access was granted/modified * **FR-4.3**: The system SHALL support bulk queries for compliance reporting * **FR-54.4**: The API SHALL provide filtering and export capabilities for audit reports #### FR-5: Integrate with External Identity System **Priority**: P1 * **FR-5.1**: The system SHALL support evaluating attributes from external identity systems ### **Considerations** * Evaluation logic with respect to user permissions vs group/project permissions * Costs to build this including consolidating existing resource protections and settings. * Security Policies vs Authorization Policies