# 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.