generated from coulomb/repo-seed
45 lines
1.2 KiB
Markdown
45 lines
1.2 KiB
Markdown
# Pattern: External Secrets Operator
|
|
|
|
Status: seed
|
|
Readiness target: RL3 production
|
|
Primary owners: Railiance platform, OpenBao
|
|
Genesis family: Secrets and cryptography
|
|
|
|
## Problem
|
|
|
|
Kubernetes applications need secrets without making Kubernetes itself
|
|
the long-term source of truth for secret material.
|
|
|
|
## Context
|
|
|
|
Use this pattern when workloads consume secrets from OpenBao or another
|
|
external secret manager through Kubernetes-native references.
|
|
|
|
## Forces
|
|
|
|
- Workloads often expect Kubernetes Secrets.
|
|
- Secret source of truth should remain in OpenBao.
|
|
- Sync creates copies that need scope, ownership, and rotation.
|
|
- Tenant and namespace boundaries must be respected.
|
|
|
|
## Solution
|
|
|
|
Use an external secrets controller to reconcile secret references from
|
|
OpenBao into scoped Kubernetes Secrets, with explicit ownership, refresh
|
|
intervals, RBAC, namespace boundaries, and audit.
|
|
|
|
## Verification
|
|
|
|
- Kubernetes Secrets are derived from OpenBao references, not committed
|
|
plaintext.
|
|
- Sync permissions are namespace and tenant scoped.
|
|
- Rotation in OpenBao reaches consumers within the expected interval.
|
|
- Sync failures are visible and fail safe.
|
|
|
|
## Related Patterns
|
|
|
|
- Workload Identity.
|
|
- Dynamic Secrets.
|
|
- Secret Zero Avoidance.
|
|
- Namespace-per-Tenant.
|