Keep OpenBao Pods inside the restricted runtime baseline from the first reconcile.

The operator assumes runtime hardening is the default, not an optional add-on. OpenBao Pods, init containers, and transient lifecycle Jobs are expected to run non-root, use explicit writable volumes, and consume only the identities and Linux privileges they actually need.

Decision matrix

Runtime protections at a glance

Runtime protections at a glance.

Control	Default posture	Why it matters
Non-root execution	OpenBao Pods and helper containers run with runAsNonRoot and a stable UID/GID baseline on standard Kubernetes.	This narrows the blast radius of container breakout attempts and keeps the workload aligned with the Restricted Pod Security Standard.
Read-only root filesystem	The root filesystem is immutable and mutable paths are mounted explicitly.	The workload cannot silently write arbitrary state into the container image layer.
Explicit audit file storage	File audit devices write only to the configured audit storage mount when spec.auditFileStorage is used.	Audit records stay on a known writable surface that can be collected and reviewed separately from the container filesystem.
Dropped Linux capabilities and seccomp	Capabilities are dropped and RuntimeDefault seccomp applies by default.	The process keeps only the syscall and privilege surface needed to run the service.
Explicit projected Kubernetes token	The pod does not rely on default token automounting and uses a projected token only where the workload needs Kubernetes API access.	This keeps API identity explicit, short-lived, and absent from containers that do not need it.
Job resource guardrails	Backup and restore Jobs run with explicit resource requests and limits.	A lifecycle job should not starve the steady-state OpenBao Pods or neighboring workloads on the same node.

Diagram

Runtime boundary inside an operator-managed Pod

Mutable state, API identity, and rendered configuration are each introduced through explicit mounts instead of through an implicitly writable container image.

Pod hardening baseline

Reference table

Baseline pod controls

Baseline pod controls.

Surface	Expected setting	Operational note
User and group	Non-root by default on standard Kubernetes; OpenShift may assign UID/GID through SCC.	Hardened clusters may use spec.securityContext for safe non-root or OpenShift-compatible overrides only.
Filesystem	Read-only root filesystem with explicit writable mounts for data, logs, and temporary paths.	If a plugin or sidecar needs extra write paths, treat that as a deliberate exception to review.
Privilege escalation	allowPrivilegeEscalation: false with dropped capabilities.	Setuid or unexpected ambient privileges should not become a recovery crutch.
Seccomp	RuntimeDefault.	If your platform cannot support this baseline, resolve the platform issue rather than weakening the cluster silently.

Hardened security context overrides

The Hardened profile rejects pod-level spec.securityContext overrides that weaken runtime guarantees. Do not set runAsNonRoot: false, root UID/GID values, root supplemental groups, seccompProfile.type: Unconfined, pod sysctls, or Windows pod security options for Hardened OpenBao clusters.

Init container behavior

The config-rendering init container inherits the same pod-level hardening contract and does not receive a Kubernetes API token mount by default. Its job is to render dynamic configuration such as Pod IP and hostname into config.hcl, not to act as a privileged bootstrap helper.

Audit file storage mount

When spec.auditFileStorage is configured, the operator mounts one RWX PVC into each OpenBao Pod and isolates each Pod with a pod-specific subPathExpr. The default path is /openbao/audit; file audit devices must write under the effective mount path.

Reference table

Audit mount security checks

Audit mount security checks.

Check	Expected posture	Why it matters
Writable identity	The storage provider honors fsGroup or the existing claim is pre-owned for the OpenBao runtime identity.	OpenBao cannot enable the file audit device if the mounted directory is not writable by the Pod security context.
Read-only collection	Collectors mount the audit PVC read-only.	The collector path ships records onward instead of becoming another writer that can alter audit history.
Runtime hardening	Keep the OpenBao root filesystem read-only and avoid hostPath exceptions for audit collection.	Audit storage is a deliberate writable path; do not broaden it into general host or node access.

Storage permissions are part of the security boundary

On standard Kubernetes, OpenBao Pods run as UID 100 and GID 1000 with fsGroup: 1000. On OpenShift, SCCs may assign IDs dynamically. Verify the RWX provider and any pre-created PVCs make the audit directory writable for the effective runtime identity before enabling the file audit device.

Identity and token exposure

Reference table

Where runtime identity exists

Where runtime identity exists.

Path	How it works	Why it stays narrow
OpenBao Pod token	A projected ServiceAccount token is mounted only where the OpenBao container needs Kubernetes API access for peer discovery and service registration.	The pod does not inherit a default automounted token, so identity is explicit rather than ambient.
Init container	No default token mount.	Rendering config is not a reason to grant Kubernetes API identity.
Backup, restore, and upgrade Jobs	Each workflow uses its own operator-managed ServiceAccount and projected token path.	Lifecycle Jobs should not reuse the long-running workload identity or borrow permissions accidentally.

Namespace and job guardrails

Reference table

Controls around the workload

Controls around the workload.

Control	What it does	Why it matters
Tenant namespace PSS labels	Provisioned namespaces are labeled for Restricted Pod Security enforcement, audit, and warning by the Provisioner unless namespace label ownership is delegated to platform policy.	Insecure sidecars or helper workloads should fail at the namespace boundary rather than weakening the cluster quietly; external mode keeps that baseline as a platform responsibility.
Job resource defaults	Backup and restore Jobs have explicit CPU and memory requests and limits.	Operational workflows remain bounded and do not become an easy noisy-neighbor path.
Operator-owned writable paths	Mutable state is confined to PVCs, temporary volumes, and generated files the operator expects.	The runtime contract stays reviewable because writes happen on known surfaces.

Avoid runtime exceptions as a convenience

If a deployment needs extra host access, extra capabilities, or a writable root filesystem, treat that as a security design change. In practice it usually means the surrounding platform integration should be fixed instead of weakening the OpenBao workload contract.

Continue workload protections

TLS and identityReview how peer trust, certificate rotation, and edge exposure build on top of this runtime baseline.Supply-chain verificationSee how the operator decides which images it will trust before these Pods ever start.Tenant isolationConnect namespace hardening back to the shared-service isolation model.