Add secrets management as a category to Release

There are two important parts to our vision for secrets management at GitLab, which are broken down in gitlab-org&1263 (closed). In summary:

  • Part A (gitlab-org&861 (closed)) is migrating GitLab's internal secrets to Vault and providing Vault as a general purpose secrets store, included within GitLab.
  • Part B (gitlab-org&816) is allowing for CI/CD to point to a Vault for secrets used during the pipeline. This could be either an existing customer's Vault, or our embedded one from part A (some customers will want to use their own Vaults even if we provide one, so this flexibility is important for this portion of the feature.)

At the moment, these are being conflated and we are building part A as a by-product of implementing part B, without tracking a clear strategy for part A. This is not working well, because part A is quite complex with its own separate users, use cases, and value, and is too complex to be delivered as a side effect of implementing B.

This issue proposes a new category within Release that is specifically about Part A, giving a better long-term home for the strategy vs. gitlab-org&861 (closed) and also driving discoverability of this powerful new capability in general. This also adds the initial category epic content for that epic, which will be further refined in additional MRs.

If this is approved, before merging:

  • @jlenny creates category epic
  • @jlenny creates category label and ensures is it is applied to the appropriate issues

Going forward:

  • @jlenny/@brendan groom Vault related issues to ensure split is clear and consistent across issues/epics, and that the overall strategy is set and being followed
  • @brendan will continue to drive feature development out of Verify for part B, but with a coherent plan for part A to refer to.
Edited by Jason Yavorsky

Merge request reports

Loading