Kubernetes Policy Is Not Just Another GitOps Workload
Kubernetes policy is often managed like any other GitOps workload. This is convenient, but it makes foundational controls depend on the mutable API state they are supposed to govern.
A security boundary is credible only when its availability, ownership, and failure behavior are explicit. Git remains the source of change, but the cluster bootstrap path must establish the minimum controls that cannot safely disappear.
What matters
- Bootstrap guarantees: Baseline admission controls must exist before tenant workloads can be accepted.
- Failure semantics: Teams must decide deliberately whether unavailable policy evaluation blocks or permits changes.
- Protected ownership: Application teams should consume guardrails without controlling the mechanisms that enforce them.
- Layered policy: Cluster-wide invariants belong to the platform. Workload-specific rules can remain delegated and self-service.
- Controlled recovery: Emergency paths need narrow scope, strong auditing, and predefined ownership.
Recommendation
Keep policy definitions versioned, reviewed, and tested through GitOps. Place only the smallest non-negotiable control set in the trusted cluster lifecycle.
This separation preserves delivery flexibility without confusing convenience with a root of trust. Reliable governance begins with an operating model, not with another reconciled object.