## Problem Statement Currently, project secrets use two different JWT authentication mechanisms: - **User JWT**: Uses CEL-based authentication (newer approach) - **Pipeline JWT**: Uses native JWT authentication (older approach) Group secrets, implemented more recently, use **CEL-based authentication for both user and pipeline contexts**. This inconsistency creates: 1. **Maintenance burden**: Two different authentication code paths to maintain 2. **Migration complexity**: Future changes to authentication logic need to handle both mechanisms 3. **Inconsistency**: Projects and groups behave differently 4. **Technical debt**: The native JWT approach is the older pattern we're moving away from ## Proposal Migrate project secrets pipeline JWT to use CEL-based authentication, matching the group secrets implementation. ### Benefits 1. **Consistency**: Both project and group secrets use the same authentication mechanism 2. **Simplified maintenance**: Only one authentication pattern to maintain 3. **Easier migration**: Migrating now (before Beta) is less risky than after customer adoption 4. **Future-proof**: Aligns with the direction established by group secrets implementation 5. **Simplified architecture**: As noted by @cipherboy-gitlab, we could potentially consolidate to a single auth mount with two roles instead of separate `pipeline_jwt` and `user_jwt` mounts ### Why Now (Before Beta)? - **Lower risk**: Fewer users/projects to migrate - **Easier reprovisioning**: Can reprovision projects without customer impact - **Clean slate**: Start Beta with consistent architecture - **Avoid future breaking changes**: Migrating after Beta would require customer coordination ## Technical Approach Based on discussion with @cipherboy-gitlab: 1. **Consolidate auth mounts**: Since auth is now within the namespace, we could use a single auth mount with two roles (pipeline and user) instead of separate `pipeline_jwt` and `user_jwt` mounts 2. **Migrate pipeline role to CEL**: Convert the pipeline JWT role to use CEL-based authentication 3. **Update provisioning service**: Modify project secrets manager provisioning to create CEL-based pipeline roles 4. **Migration path**: Reprovision existing project secrets managers to use the new authentication ### Implementation Considerations - This should be done **before Beta** to minimize migration impact - Existing projects would need reprovisioning (acceptable pre-Beta) - Group secrets already use this pattern, so we have a working reference implementation - Long-term, common configuration will be addressed by the next-gen design doc ## Related - Discussion in !214892: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/214892#note_2935505109 - Group secrets implementation (reference): Uses CEL for both user and pipeline auth - Slack discussion: https://gitlab.slack.com/archives/C09GSEDT50U/p1733436254123829 ## Acceptance Criteria - [ ] Project secrets pipeline JWT uses CEL-based authentication - [ ] Consistent with group secrets authentication mechanism - [ ] Single auth mount with two roles (if feasible) - [ ] Existing project secrets managers can be reprovisioned - [ ] Documentation updated to reflect the authentication mechanism - [ ] No regression in pipeline secret access functionality