refactor!: standardize secret path layout#416
Merged
Conversation
Contributor
|
If we already work on this. Shouldn't we already take the opportunity to fully clean this up. Meaning introducing a path like:
Otherwise we will have to introduce a second breaking change for the same reason in the future |
Contributor
Author
|
Good point. I updated the layout to |
tuunit
reviewed
Jun 18, 2026
tuunit
reviewed
Jun 18, 2026
tuunit
approved these changes
Jun 18, 2026
Co-authored-by: Jan Larwig <jan@larwig.com>
a2c9bd0 to
dacf0a7
Compare
tuunit
approved these changes
Jun 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 Summary
Scopes the built-in secret-manager path contract by cluster and stage so one secret backend can hold multiple clusters and stages without path collisions.
Namespace-specific secrets now use:
<cluster-name>/<stage>/<namespace>/<secret>Cluster-wide secrets now use:
<cluster-name>/<stage>/cluster_secrets/<secret>The shared Helm consumers and STACKIT Terraform producers now use the same paths, including:
<cluster-name>/<stage>/cluster_secrets/docker_config<cluster-name>/<stage>/cluster_secrets/vault_instance<cluster-name>/<stage>/oauth2-proxy/oauth2_credentials<cluster-name>/<stage>/argocd/argo_oauth2_credentials<cluster-name>/<stage>/kube-prometheus-stack/grafana_credentials<cluster-name>/<stage>/kube-prometheus-stack/grafana_oauth2_credentials<cluster-name>/<stage>/external-dns/dns_zone_admin<cluster-name>/<stage>/velero/velero_s3_credentialsThe local OpenBao setup writes Grafana credentials and optional Docker pull credentials to the same scoped paths. Documentation was updated to describe the new layout.
🧩 Type of change
Existing installations using the previous flat or namespace-only secret paths must move secrets to the new cluster/stage-scoped paths before deploying regenerated Helm values.
Terraform-managed STACKIT secrets are replaced at the new paths when the regenerated Terraform is applied. Copied Terraform files such as OAuth secret definitions must be updated to the new names before applying. Secrets created outside Terraform or OpenTofu must be recreated manually at the corresponding new path.
Apply the Terraform or OpenTofu changes before deploying the new Helm values so External Secrets can resolve the new remote keys.
🧪 Testing
Ran locally:
go test ./internal/render ./internal/cmd/bootstrapUV_PYTHON=3.14.5 make docs-validategit diff --check🔗 Related Issues / Tickets
✅ Checklist
📎 Additional Context (optional)
This PR is intentionally limited to the shared secret-path contract and local OpenBao parity. Namespace-scoped authorization and provider-specific
SecretStorebehavior remain separate concerns.It can proceed in parallel with #391. The expected overlap is limited to the shared ExternalDNS values during the eventual rebase.