Start from the trust boundaries the operator is designed to defend.

This threat model focuses on the operator control plane, tenant isolation boundaries, and lifecycle workflows such as onboarding, upgrade, backup, and restore. It does not replace OpenBao's own internal threat model; it explains the extra surface introduced by running OpenBao through the operator.

Scope

This page models threats to the OpenBao Operator control plane, tenant isolation boundaries, and lifecycle workflows. It assumes the operator manages clusters it created and reconciles; generic import of arbitrary unmanaged OpenBao clusters is out of scope.

Decision matrix

Threat-model scope

Threat-model scope.

Area	In scope	Why
Operator control plane	Yes	Long-running operator identities, admission dependencies, and controller boundaries define most of the extra risk introduced by the operator.
Tenant isolation	Yes	Namespace introduction, RBAC boundaries, and managed-resource ownership are core to the multi-tenant model.
Lifecycle workflows	Yes	Backup, restore, upgrade, and tenant onboarding introduce destructive or privileged execution paths.
OpenBao internals unrelated to the operator	No	Those belong to OpenBao’s own product threat model rather than the operator-specific surface.

Threat actors

Reference table

Actors that matter

Actors that matter.

Actor	Typical access	Why they matter
Tenant author	Namespace-scoped write access	Can attempt to steer the operator, exploit weak isolation, or target Secrets and workload identities inside an onboarded namespace.
GitOps pipeline or human cluster operator	Namespace or cluster write access	Can intentionally or accidentally mutate control-plane configuration, admission dependencies, or operator-managed resources.
Compromised controller or provisioner Pod	Operator-managed identity	Tests whether the split-controller model and mutation locks actually narrow blast radius.
Compromised OpenBao Pod or lifecycle Job	Namespace workload identity	Exercises the boundary between the steady-state service, generated Jobs, and the control plane.
Compromised or misconfigured external dependency	Object storage, PKI, KMS, ingress, or identity system	The operator relies on those systems for unseal, TLS, backup, restore, and external access contracts.

Trust boundaries

Diagram

Trust zones

Admission policy is the API enforcement boundary between submitted intent and persisted state. Operator identities, tenant workloads, and external systems each carry different trust assumptions.

Protected assets

Reference table

Always-relevant assets

Always-relevant assets.

Asset	Risk	Why it matters
Admission policies and bindings	Critical	They enforce the operator’s API-level safety model before unsafe intent persists.
Provisioner and controller identities	Critical	They define namespace onboarding and lifecycle authority across the cluster.
Tenant RBAC and Secret allowlists	High	They control what an onboarded namespace can read, mutate, or discover.
Raft data and snapshots	High	They contain the OpenBao state the operator is trying to protect and recover safely.
Operator-managed configuration and generated job identities	Medium	They steer runtime behavior and disruptive workflows even when they do not directly store application secrets.

Reference table

Conditional assets

Conditional assets.

Asset	Present when	Why it matters
Root token Secret	Bootstrap mode persists the initial root token	This is a critical administrative credential and is intentionally avoided by Hardened self-init.
Static unseal keys	Static unseal is used	The root of trust sits in a Kubernetes Secret instead of an external trust system.
Operator-managed CA key	OperatorManaged TLS mode is selected	This puts certificate authority material inside the cluster and is one reason that mode is not the Hardened path.
Transit, cloud KMS, or HSM credentials	External unseal or PKI integration is used	These credentials and identity paths sit at a high-value trust boundary outside the workload itself.

STRIDE analysis

Spoofing

Threats

• A client or GitOps render path spoofs operator identity by drifting ServiceAccount names, policy subjects, or RoleBinding subjects.
• A workload or edge path spoofs cluster identity at the TLS boundary.
• Backup, restore, or upgrade Jobs inherit the wrong identity path.

Primary mitigations

• Split provisioner and controller identities.
• Validate rendered install identities for Helm and raw-manifest overlays.
• Validate TLS SANs and trust sources before the cluster becomes ready.
• Use separate job ServiceAccount objects, identity checks, and Job-specific network controls.

Tampering

Threats

• A user, GitOps controller, or compromised namespace actor directly mutates operator-managed resources.
• A compromised provisioner broadens tenant RBAC or tenant guardrails.
• A tenant or operator steers backup or restore jobs toward unintended endpoints or credentials.

Primary mitigations

• Lock operator-managed resources with admission policy.
• Restrict controller writes for RBAC, ServiceAccount, and Secret objects.
• Restrict provisioner namespace mutation and tenant-governance writes.
• Keep backup and restore credentials name-scoped and separately validated.

PVC posture

Operator-managed PVCs are intentionally CR-driven and status-observed rather than fully admission-locked because Kubernetes storage controllers and CSI components also mutate PVCs during normal lifecycle.

Repudiation

Threats

• High-value control-plane actions cannot be attributed later.
• Break-glass changes happen without a clear audit boundary.

Primary mitigations

• Emit structured operator audit logs for startup gating, upgrades, backups, restore, and operation-lock transitions.
• Use Kubernetes API audit logs and admission denials as the primary mutation trail.
• Keep maintenance mode explicit and break-glass groups narrow by default.

Information Disclosure

Threats

• Secrets, credentials, or keys are exposed through logs or broad namespace access.
• TLS handling leaks sensitive material.
• Backup and restore credentials leak across workloads.

Primary mitigations

• Never log secrets.
• Keep Secret access name-scoped without normal Secret enumeration.
• Use separate writer and reader roles for operator-managed Secrets.
• Keep ACME private keys in the OpenBao process instead of Kubernetes Secrets.
• Use separate workload identities for backup and restore Jobs.

Denial of Service

Threats

• Misconfiguration or tampering causes reconcile churn or blocks convergence.
• Day-2 operations collide or force unsafe concurrent mutations.
• Voluntary disruption or PDB tampering breaks quorum.
• Required admission policies disappear after startup.

Primary mitigations

• Use controller rate limiting and bounded concurrency.
• Validate objects at admission before invalid state persists.
• Use explicit readiness conditions for API-server, Gateway, ACME, backup, and restore assumptions.
• Use a shared operation lock for disruptive workflows.
• Manage PodDisruptionBudget objects and lock them against drift.
• Re-check admission dependencies at runtime and pause privileged reconciliation when they disappear.

Elevation of Privilege

Threats

• A compromised controller broadens tenant privileges or writes to unrelated Secrets or ServiceAccount objects.
• A compromised provisioner mints broader tenant access or mutates protected namespaces.
• Unsafe mode or break-glass use weakens the API-level defense-in-depth boundary.

Primary mitigations

• Split long-running identities and restrict controller writes.
• Keep Secret access name-scoped and allowlisted.
• Restrict provisioner RBAC, namespace mutation, and tenant-governance writes.
• Keep unsafe mode explicitly non-production and break-glass scoped.

Accepted residual risks

Accepted posture

• PVCs are intentionally soft-governed rather than fully admission-locked because Kubernetes and CSI controllers also update them.
• UserAccessBootstrap is best-effort signaling. The operator does not prove that arbitrary self-init requests create a usable human authentication path.
• Cloud KMS and external identity integrations are surfaced through conditions and validation, but still depend on systems outside the operator trust boundary.
• unsafe mode intentionally weakens the API-level safety model and is not a supported Hardened production posture.

Continue the security model

Production postureMove from threats into the supported security contract for Development versus Hardened.Secrets and trust materialReview how root tokens, unseal keys, and workload bootstrap identities behave across the lifecycle.Admission policiesSee one of the main enforcement layers that turns this model into actual API guardrails.