Phase 1: Add CEL Auth Role for project secrets pipeline JWT

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Context

This is Phase 1 of the migration plan outlined in #583087. As discussed in this comment, each phase should be a separate work item to help with planning, milestone setting, weight assessment, and task assignment.

@fcatteau suggested doing this phase as soon as possible:

The earlier you do this, the fewer projects we need to migrate. Projects provisioned in 18.10 would be CEL ready. We would switch to CEL authorization later.

Goal

New and existing project secrets managers support both authentication methods (legacy bound_claims and CEL-based).

Implementation

  1. Update ProjectSecretsManager provisioning to create a CEL-based pipeline auth role alongside the existing bound_claims role
  2. Add a feature flag (project_secrets_cel_pipeline_auth) to control which auth method GitLab uses at runtime
  3. Both roles read from the same secrets paths - only the authentication mechanism differs

Key implementation details

  • Same role name: pipelines (different role types: jwt vs jwt_cel)
  • Same auth mount, same role name, different validation mechanism
  • Feature flag defaults to false (use legacy jwt role type)
  • When flag is enabled, GitLab authenticates using the CEL role type
  • Group secrets already use CEL for both user and pipeline contexts, so we have a working reference implementation

Acceptance Criteria

  • Project secrets manager provisioning creates a CEL-based pipeline auth role alongside the existing bound_claims role
  • Feature flag project_secrets_cel_pipeline_auth controls which auth method is used at runtime
  • Feature flag defaults to false (legacy behavior preserved)
  • When feature flag is enabled, pipeline authentication uses CEL role
  • No regression in pipeline secret access functionality with feature flag disabled
  • Tests cover both authentication paths

References

Edited by 🤖 GitLab Bot 🤖