1.9 KiB
1.9 KiB
Workspace SOPS Secret Management
This guide defines workspace-level secret handling. It is guidance only; each project still owns its runtime config and secret loading code.
Principles
- Track encrypted secret material only when needed, using SOPS.
- Never track decrypted secret files or raw secret values.
- Keep local decryption identities and runtime
.envfiles ignored. - Document secret names, injection points, and validation paths, not values.
- Prefer project-local secret docs when they exist; use this guide for common workspace expectations.
Recommended Layout
| Item | Location |
|---|---|
| SOPS policy | project root .sops.yaml |
| Encrypted project secrets | project-owned path such as secrets/*.sops.yaml or an existing project convention |
| Local age/GPG identity | ignored local profile, never tracked |
| Runtime env file | ignored project-local .env* or documented remote runner injection |
| Workspace guidance | .workspace-ops/docs/secrets-sops.md |
Required Documentation For A Project
When a project uses SOPS, its tracked guidance should state:
- encrypted file path pattern
- recipient/key ownership at a high level
- runtime injection path
- validation command or smoke path
- which values must never be committed
Validation Examples
Use examples like these without printing decrypted values:
sops -d secrets/example.sops.yaml >/dev/null
APP_ENV=local bin/test
Remote runner validation should mention the runner and command class, not the secret value.
Safety Checklist
- No raw token, password, private key, signing material, webhook secret, or private account value is tracked.
- Decrypted output paths are ignored.
- SOPS recipients are documented at the ownership level.
- Project runtime config loads secrets from the documented injection path.
- Build/Jenkins/OTO docs refer to this guide instead of duplicating secret values.