Own certificate sources, rotation, and hot reload without restarting pods.
The cert manager keeps TLS lifecycle close to the workload contract. It decides whether certificates are operator-managed, externally supplied, or handled by ACME, and it turns certificate changes into safe reload signals instead of pod restarts.
At a glance
Control path
- workload reconciler
- internal/controller/openbaocluster
- internal/service/certs
Owns
- TLS mode handling for OperatorManaged, External, and ACME
- CA and server certificate Secret lifecycle when the operator is the source
- certificate hash generation and hot-reload signaling when leaf certs change
Writes
- cluster TLS CA and server Secrets in OperatorManaged mode
- trust-bundle ConfigMap surfaces for workload consumers
- pod annotations used to trigger in-pod TLS reload
Depends on
- spec.tls.mode and rotation window settings
- external Secret availability when TLS is not operator-managed
- ready workload pods to accept reload signaling
Architectural Placement
TLS lifecycle stays on the workload reconcile path:
internal/controller/openbaoclusterdetermines that TLS state must reconcile.- The controller calls
internal/service/certs. - The cert manager creates, validates, or watches certificate material and signals reload when the active server certificate changes.
That keeps TLS behavior close to workload rendering while avoiding a second, disconnected certificate controller path.
Decision matrix
TLS mode responsibilities
| Mode | Certificate source | Manager behavior |
|---|---|---|
| OperatorManaged | Operator-generated root CA and server certificate Secrets. | Generate, rotate, export trust, and trigger reload when the leaf certificate hash changes. |
| External | User or external controller provided Secrets. | Wait for required Secrets, validate usability, and still trigger reload when the external provider rotates content. |
| ACME | OpenBao internal ACME flow and certificate cache. | Render the ACME listener configuration and step out of Secret management and hot-reload ownership. |
Rotation And Reload Path
Diagram
TLS rotation loop
In operator-managed mode, the manager decides when the current server certificate is within the rotation window, writes fresh material, computes a new hash, and signals reload only when the hash changed.
Diagram
Hot-reload boundary
The manager does not restart pods to pick up new certificates. Instead, it updates pod-level hash annotations that a lightweight in-pod watcher turns into a reload signal.
When spec.tls.mode=ACME, the cert manager still participates in rendering the listener contract, but OpenBao owns the live ACME issuance and cache lifecycle. Kubernetes TLS Secrets stop being the source of truth for the workload certificate.
Reference table
Safety boundaries
| Concern | Manager behavior |
|---|---|
| No forced pod restart | Certificate changes become hot-reload signals instead of StatefulSet rollouts or manual restart requirements. |
| External TLS still observed | External mode is passive about issuance, but active about detecting usable Secret changes and propagating reload signals. |
| Reload only on change | The manager computes a certificate hash and skips signaling when the new material is identical to what ready pods already observe. |
| Source-of-truth clarity | OperatorManaged owns Secrets, External owns watching those Secrets, and ACME owns only the rendered listener contract rather than Secret reconciliation. |
Related deep dives
You are reading the unreleased main docs. Use the version menu for the newest published release, or check the release notes for what is already out.
Was this page helpful?
Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.