Treat trust material as lifecycle state, not just as Kubernetes Secrets.
The operator manages or coordinates several high-value trust surfaces: bootstrap credentials, unseal roots, TLS material, and the identities used by backup, restore, and upgrade workflows. The most important question is not only where they live, but whether the operating model can avoid creating them in the first place.
Reference table
Managed trust material
| Surface | Typical location | Security posture |
|---|---|---|
| Root token | Secret only when bootstrap mode persists it | Critical and intentionally avoided by the supported Hardened self-init path. |
| Static unseal key | <cluster>-unseal-key Secret | Critical because the root of trust sits inside Kubernetes instead of an external trust system. |
| Cluster CA and server TLS material | Secrets when the selected TLS mode requires them | High-value trust material whose lifecycle depends on the chosen TLS mode. |
| Backup, restore, and upgrade job auth | Projected tokens, generated ServiceAccounts, or explicit credentials Secrets | Should remain separate from the main OpenBao workload identity. |
Unseal trust model
- Static unseal
- External trust root
Static unseal generates a 32-byte key and stores it in a Kubernetes Secret. If etcd encryption or namespace access is weak, the effective trust root of your OpenBao data is weak too.
Reference table
Static unseal behavior
| Aspect | Behavior | Why it matters |
|---|---|---|
| Generation | The operator creates a random key. | Bootstrap is convenient, but the cluster is now trusted to protect the root of trust. |
| Storage | The key is stored in <cluster>-unseal-key. | Anyone who can read that Secret can compromise the trust root. |
| Rotation | Manual, not automatic. | Operational handling of the trust root stays a human responsibility. |
Using transit, cloud KMS, or HSM-backed modes shifts the root of trust away from Kubernetes and into an external system that is designed to protect it.
Reference table
External trust behavior
| Aspect | Behavior | Why it matters |
|---|---|---|
| Operator-owned unseal key | Not created | The cluster does not persist its own trust root in a Kubernetes Secret. |
| Authentication path | Uses workload identity or explicit credentials for the selected backend. | The identity contract becomes part of the production posture and must be observable. |
| Readiness model | Surfaced through conditions such as CloudUnsealIdentityReady. | Failures become visible before operators have to infer them from generic pod errors. |
Bootstrap credentials and root token handling
Decision matrix
Bootstrap paths
| Path | What happens to the root token | Security effect |
|---|---|---|
| Hardened self-init | The initial root token is not persisted as the normal operating model. | This avoids leaving a long-lived administrative credential in namespace Secrets. |
| Development bootstrap without self-init | The root token can be stored in <cluster>-root-token. | This is useful for testing but creates a critical secret in the namespace. |
If a root token or equivalent bootstrap credential exists in a Secret, anyone who can read that Secret effectively has full administrative control of the OpenBao cluster.
TLS and job identities
Diagram
Job identity separation
The main OpenBao Pods, backup jobs, restore jobs, and upgrade jobs should not silently share one identity path. Each surface should stay explicit and observable.
The important boundary is this:
- main OpenBao Pods use the trust path selected for the cluster itself
- backup, restore, and upgrade Jobs use separate generated identities
- those Jobs do not automatically inherit the cloud or JWT path of the main workload unless the operator deliberately configured it
This is why backup and restore readiness are surfaced independently in status rather than assumed from the main Pods.
Where the task guidance lives
This page owns the trust model. The operational task pages stay elsewhere:
Continue the security model
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.