infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-external-secrets-operator.md

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.