These pages explain the design for maintainers and reviewers. For procedures, see Get started and Operate ; for exact contracts, see Reference .
Pages in this section
The provider's components, how Encrypt, Decrypt, and Status flow through them, the key snapshot model, startup ordering, and how multiple control-plane nodes stay consistent.
→ Architecture BackgroundThe Kubernetes KMS v2 and OpenBao Transit behavior the provider's design depends on.
→ Architecture Transit key modelWhy the Transit key is owned outside the provider, why each key setting has its value, and which Transit features the design uses and avoids.
→ Architecture Rotation modelWhy rotation is observed rather than performed, the snapshot state machine, the guards against key_id flip-flop, how minimum versions are treated, and why retirement is an explicit operator step.
→ Architecture Failure modesEach failure the design considers, how it shows up, whether it blocks API server startup, and whether it can lose data.
→ Architecture Related workA revision-pinned comparison with the Vault Transit KMS plugin, including identity, authentication, startup, and recovery tradeoffs.
→