Security profile contracts

What Development and Hardened optimize for, what Hardened requires in production, and how the profiles change the operating contract.

Decision matrix

Profile intent

Profile intent.

Profile	Optimized for	What it trades off
Hardened	Production deployments with explicit external trust roots and stricter lifecycle guarantees.	More up-front requirements, less tolerance for weak bootstrap and trust shortcuts.
Development	Local testing, CI, and quick evaluation when long-term trust posture is not the goal.	Allows bootstrap and unseal material to exist in cluster Secrets and relaxes some runtime guarantees.

Reference table

Profile comparison

Profile comparison.

Feature	Hardened	Development
Root token handling	Auto-revoked; not stored in a Secret as part of the supported production path.	Can be stored in a Secret when self-init is disabled.
Unseal root of trust	Requires a non-static external trust source such as transit, cloud KMS, or HSM-backed modes.	Defaults can rely on a static key in a Kubernetes Secret.
TLS posture	Requires External or ACME style trust; OperatorManaged TLS is not the production path.	Allows operator-managed TLS for local or test usage.
Bootstrap model	Self-init is the supported production path.	Manual bootstrap or self-init are both possible.
Supply-chain guardrails	Image verification protections remain on and cannot degrade to warning-only behavior.	Verification can be relaxed for testing.

Hardened production contract

Reference table

Hardened production requirements

Hardened production requirements.

Requirement	Why it exists	Operational effect
At least three replicas	Raft needs quorum and safe disruption handling in production.	Single-node clusters are not treated as production-safe.
External trust root for unseal	The cluster should not keep its root of trust only in Kubernetes etcd.	Cloud KMS, transit, KMIP, or PKCS#11-style paths become part of the deployment contract.
Trusted TLS path	The workload identity boundary should be anchored in a production-grade certificate model.	OperatorManaged TLS is rejected for Hardened clusters.
Self-init enabled	The supported bootstrap path should avoid persisting the initial root token.	Human bootstrap becomes declarative instead of secret-based.
Verification guardrails stay enforced	Production image trust should not be optional.	Managed workloads keep digest and verification enforcement even when omitted from config.

Hardened profile assumptions

Hardened means the operator can rely on an external trust root, explicit runtime identity, and a production-ready lifecycle posture. It defines the operating model for the cluster, not just one field in the CR.

Development profile relaxations

Development intentionally relaxes the production contract:

• bootstrap material can persist in cluster Secrets
• static unseal remains available
• operator-managed TLS can be used
• runtime and supply-chain controls can be less strict
• the cluster reports a security-risk signal rather than pretending this posture is production-ready

Trust-root migrations

Teams often start in Development for exploration. When moving to staging or production, create a new Hardened cluster rather than assuming a Development trust path can be promoted safely. Teams often start in Development for exploration. For staging or production, create a new Hardened cluster instead of promoting a Development trust path in place.

Configuration scope

Configuration steps for spec.profile, unseal mode, and the production requirements are in Configure Security Profiles.

Continue the security model

Configure security profilesCluster fields and configuration steps behind these profile requirements.Secrets and trust materialReview how root tokens, unseal keys, and job identities differ between these profiles.Threat modelRationale behind these profile boundaries.