Evidence level: historically reviewed source and owner proposals; not freshly tested or certified for production.
Design and implementation invariants
- The secrets service is the sole master-key authority; consumers receive narrow role-specific material, not general decryption authority.
- No Docker daemon privilege, unrestricted application route, or plaintext bootstrap credential persistence is acceptable.
- Legacy provisioning and secret manager modules are security-protected and must not be automatically inspected, imported or ported.
Verification still required
- A security owner must approve sensitive legacy behavior comparison and sanitization before declaring equivalence.
- Verify role-scoped certificate/secret lifecycle and real YSQL/Redis authority in approved isolated integration; offline test doubles do not prove production security.
How to update
When the owner changes implementation or contract behavior, update this page and the relevant service interfaces. For cross-service changes, also update the platform interface map or decision register. State the actual verification performed; do not inherit historical pass claims without fresh evidence.