Verify what will run before the controller ever writes a Pod template.

The operator's supply-chain model is built around signature verification, digest pinning, and separate trust roots for the main OpenBao image versus helper images such as init, backup, restore, and upgrade executors. The goal is to keep mutable tags and unverified images out of production reconciliation.

Diagram

Verification flow before reconcile

The controller resolves a tag, verifies the signature and optional transparency-log evidence, then writes only the verified digest into managed workloads.

Decision matrix

Supply-chain controls at a glance

Supply-chain controls at a glance.

Control	What it blocks	Operational note
Signature verification	Unsigned or improperly signed images.	Trust material can come from a public key or from keyless identity matching.
Transparency-log verification	Opaque signing events with no public evidence trail.	This is on by default and is usually only disabled for disconnected environments.
Digest pinning	Tag-mutation races between verification time and pull time.	The controller writes the immutable digest so the kubelet pulls the exact artifact that was verified.
Admission digest enforcement	Direct API writes that bypass the controller and reintroduce mutable tags.	This is defense in depth, not a replacement for reconciliation-time verification.

Trust surfaces

Reference table

What gets verified

What gets verified.

Image surface	Configuration field	Why it is separate
Main OpenBao server image	spec.imageVerification	The application image can have a different signer and release cadence from the operator helper images.
Init, backup, restore, and upgrade images	spec.operatorImageVerification	Helper images are published by the operator project and often need their own trust policy.
Helm chart and release artifacts	Out-of-cluster verification	These should be verified during installation and upgrade planning even though the controller does not reconcile them in-cluster.

Reference table

Trust-source choices

Trust-source choices.

Path	Use it when	Watch for
Keyless identity matching	You consume official project images and want issuer-plus-subject verification without maintaining your own public key distribution.	Custom registries and forks should set explicit trust material rather than relying on official-image defaults.
Public-key verification	Your organization signs images with its own key or needs an offline verification path.	Rotate the public key deliberately and make sure the key distribution path is auditable.
Warning-only rollout	You are onboarding verification in a non-production environment and need visibility before enforcing block behavior.	This should be a transition state, not the final production posture.

Failure behavior

Decision matrix

Verification failure policy

Verification failure policy.

Policy	Controller behavior	When to use it
Block	Stops reconciliation for the managed workload and records the failure in status.	Use this for production. If you do not trust the artifact, do not roll it out.
Warn	Records and logs the verification failure but continues with the original image reference.	Use this only while you are standing up signing infrastructure or testing policy adoption.

Hardened profile expectations

The Hardened profile is opinionated here. The intent is that image verification stays on, mutable-tag rollouts are not the norm, and official-image defaults are only used when the operator can still tie trust back to the expected signer identity.

Verify published release artifacts

Configure

Enable verification for both workload image surfaces

yaml

spec:
imageVerification:
  enabled: true
  failurePolicy: Block
operatorImageVerification:
  enabled: true
  failurePolicy: Block

Treat the main OpenBao image and operator helper images as separate trust surfaces. They may share policy, but they should not share assumptions blindly.

Verify

Verify a published operator image outside the cluster

bash

IMAGE="ghcr.io/dc-tec/openbao-operator@sha256:<digest>"

cosign verify \
--new-bundle-format=true \
--certificate-identity "https://github.com/dc-tec/openbao-operator/.github/workflows/release.yml@refs/tags/X.Y.Z" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
"${IMAGE}"

Use the matching tag or release metadata for the version you are about to deploy, and verify by digest rather than by mutable tag.

Continue workload protections

TLS and identityConnect artifact trust back to the workload trust path that presents the service to clients.Production postureSee how the Hardened profile treats verification and warning-only modes.Air-gapped and private registriesSwitch to the configuration guide when you need the operational path for disconnected environments.