Skip to content

GitLab Secrets Manager - group-level management

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

For our MVC, we will be offering secrets management at the project level. This feature enhancement enables secrets management at the group level.

Proposal

Inheritance will work from top-down. Unlike variables, the top level will take precedence over the bottom level. This means a secret defined at the instance level applies to the groups, and subsequently the project-levels. Project-level secrets cannot override a higher lever secret.

At the lower level, the inherited secrets will be displayed without values, similar to Variables.

Summary of GitLab Secrets Manager - Group-level Management ( Duo)

The issue discusses implementing group-level management for GitLab Secrets Manager, which would allow secrets to be defined at the group level and used by projects within that group.

Final Outcome/Approach

Based on the latest update from September 24, 2025, the team has decided on the following approach:

  1. Inheritance Model:

    • Follow the CI variable precedence pattern (items 4, 5, 6) that GitLab customers are already familiar with
    • This means lower-level defined secrets can override higher-level secrets
    • This is considered a "two-way door decision" that can be revisited if customer feedback indicates a need for different behavior

  2. Implementation for Beta:

    • Implement explicit inheritance where projects must specifically reference the source of a group-level secret in their CI configuration:
    build:
  stage: build
  secrets:
    REGISTRY_PASS:
      gitlab_secrets_manager:
        name: REGISTRY_PASS
        source: group-name  # Explicitly specifies the source

  3. UI Considerations:

    • The team will consider using the CI Variables UI pattern but acknowledges existing UX challenges
    • The goal is to understand existing issues and make improvements where applicable to secrets
    • The UI solution is considered a "nice to have" for Beta at this time due to limited capacity

  4. Permissions Model:

    • Initial approach appears to be that all sub-groups and sub-projects inherit all secrets (Option 1 from earlier discussions)
    • More granular permissions could be implemented in future iterations

The team also noted that if a project wants to use only group-level secrets, they wouldn't need to enable the Secrets Manager at the project level - only at the group level.

This approach was chosen based on initial feedback from beta participants indicating that explicit inheritance would meet their needs, while balancing implementation complexity and timeline constraints.

Edited by Ken McDonald