chore(framework): canonize Vault-as-SSOT + ESO-default secrets policy (#519)
All checks were successful
ci/woodpecker/push/ci Pipeline was successful
ci/woodpecker/push/publish Pipeline was successful

This commit was merged in pull request #519.
This commit is contained in:
2026-06-11 19:07:00 +00:00
parent 89d69eb23b
commit b79e9f32c6
5 changed files with 792 additions and 0 deletions

View File

@@ -453,6 +453,26 @@ Initialize standard labels and the first pre-MVP milestone:
---
## Secrets Bootstrap (Required for Every New App)
Every new application MUST complete the following secrets bootstrap before deploying to any non-local environment. This is a hard gate — deployment without completed secrets bootstrap is forbidden.
### Secrets bootstrap checklist
- [ ] Vault path created: `vault kv put secret/k3s/<app>/ ...` with all required secret fields
- [ ] Required secrets listed in project README under a "Secrets architecture" section, including:
- Vault path(s) used
- All required secret keys and their purpose
- Whether the app uses ESO bridge (default) or Direct-Vault (opt-in, with justification)
- [ ] `external-secret.yaml` manifest committed to repo's `deploy/` or `k8s/` directory
- [ ] Deployment YAML references the synced k8s Secret via `secretKeyRef` (not raw env vars or `.env` files)
- [ ] App startup has schema-based validation for all required env vars (zod / pydantic / envconfig equivalent) that exits non-zero on missing required values
- [ ] Direct-Vault opt-in (if applicable): justification documented in README + AppRole provisioned + bootstrap credentials stored in Vault and synced via a separate `ExternalSecret`
See `~/.config/mosaic/guides/VAULT-SECRETS.md` for full worked examples of the ESO bridge pattern, the Direct-Vault opt-in pattern, and the forbidden antipatterns.
---
## Checklist
After bootstrapping, verify: