T11: dedicated KV v2 mount for app secrets (mount separation) #26

New issue

Open

opened 2026-08-11 20:58:46 +00:00 by ginjiruu · 0 comments

ginjiruu commented

2026-08-11 20:58:46 +00:00

Owner

Part of #2

Goal

Give app secrets their own KV v2 mount instead of sharing the legacy secret/ mount with everything else. This is an architecture/isolation improvement — it is not required to unblock the vault-config apply (that was fixed by dropping the vault_kv_secret_v2.class_path pre-create, which panicked the provider).

Why a separate mount

Per-mount ACLs: app-scoped policies can be rooted at the app mount instead of prefix-filtering a shared one.
Lifecycle & audit: mount-level enable/disable, per-mount tuning (TTLs, versioning) without touching infra secrets.
Matches the ADR-0004 / ADR-0007 class design (generated/<app>, manual/<app>) — the classes become top-level paths on the app mount.

Current coupling to `secret/` (must all move in lockstep)

vault/kv-schema.tf: vault_mount.secret (kv v2 at secret/).
vault/modules/app_secrets/policies/app-class.hcl.tftpl: hardcodes secret/data/..., secret/metadata/..., secret/delete/..., secret/destroy/... prefixes.
ClusterSecretStore vault-backend (flux-clusters, flux-system ns): spec.provider.vault.path: secret — 21 ExternalSecrets across 15 namespaces read through it (argo, media, frigate, paperless-ngx, monitoring, etc.).
Any ClusterSecretStore consumers in flux-clusters pointing at secret/data/... remotes.

Open questions

Mount path: app-secret/ vs apps/ vs keeping the class split (generated/, manual/ as mounts)?
One ClusterSecretStore for the new mount, or migrate per-app stores?
Migration order: create mount + new policies + new store first, then flip ExternalSecrets, then decommission the shared secret/ app classes — or keep both mounts during a transition window?
Does the superadmin/runner policy (vault-runner, wildcard) need tightening once mounts are isolated?

Out of scope

The provider panic fix (done): removing vault_kv_secret_v2.class_path from vault/modules/app_secrets/main.tf — KV paths are created lazily on first write.

Part of #2 ## Goal Give app secrets their own KV v2 mount instead of sharing the legacy `secret/` mount with everything else. This is an architecture/isolation improvement — it is **not** required to unblock the `vault-config` apply (that was fixed by dropping the `vault_kv_secret_v2.class_path` pre-create, which panicked the provider). ## Why a separate mount - Per-mount ACLs: app-scoped policies can be rooted at the app mount instead of prefix-filtering a shared one. - Lifecycle & audit: mount-level enable/disable, per-mount tuning (TTLs, versioning) without touching infra secrets. - Matches the ADR-0004 / ADR-0007 class design (`generated/<app>`, `manual/<app>`) — the classes become top-level paths on the app mount. ## Current coupling to `secret/` (must all move in lockstep) - `vault/kv-schema.tf`: `vault_mount.secret` (kv v2 at `secret/`). - `vault/modules/app_secrets/policies/app-class.hcl.tftpl`: hardcodes `secret/data/...`, `secret/metadata/...`, `secret/delete/...`, `secret/destroy/...` prefixes. - ClusterSecretStore `vault-backend` (flux-clusters, flux-system ns): `spec.provider.vault.path: secret` — **21 ExternalSecrets** across 15 namespaces read through it (argo, media, frigate, paperless-ngx, monitoring, etc.). - Any ClusterSecretStore consumers in flux-clusters pointing at `secret/data/...` remotes. ## Open questions 1. Mount path: `app-secret/` vs `apps/` vs keeping the class split (`generated/`, `manual/` as mounts)? 2. One ClusterSecretStore for the new mount, or migrate per-app stores? 3. Migration order: create mount + new policies + new store first, then flip ExternalSecrets, then decommission the shared `secret/` app classes — or keep both mounts during a transition window? 4. Does the superadmin/runner policy (`vault-runner`, wildcard) need tightening once mounts are isolated? ## Out of scope - The provider panic fix (done): removing `vault_kv_secret_v2.class_path` from `vault/modules/app_secrets/main.tf` — KV paths are created lazily on first write.

ginjiruu added the

needs-triage

label

2026-08-11 20:58:51 +00:00

ginjiruu referenced this issue from a commit

2026-08-11 20:59:31 +00:00

fix(vault): drop kv class path pre-create that panics the provider