## GitOps still needs a trust boundary
GitOps has become the default operating model for serious Kubernetes platforms because it gives teams a declarative source of truth, reviewable change history, and a clean rollback path. But a Git repository by itself is not a security boundary. If the repository accepts a dangerous manifest, or if the deployment controller pulls an image that was never built by the trusted pipeline, GitOps will faithfully deliver the problem into the cluster. The next maturity step is to make the cluster verify every deployment decision before it becomes runtime state.
Practical tip: start with report-only policies for digest pinning and privileged containers, then move one rule at a time into enforce mode. Connect the outcome to your [LLM CI/CD security controls](/blog/llms-cicd-security/) so generated manifests face the same gates as human-written changes.
The core pattern is simple: CI builds and signs artifacts, Git stores the desired deployment state, and admission control enforces the rules that connect the two. Container images should be produced by a controlled pipeline, scanned for known vulnerabilities, signed with keyless Sigstore or an equivalent signing workflow, and referenced by immutable digests rather than mutable tags. Kubernetes admission policies then reject workloads that point at unsigned images, use latest tags, request privileged mode, mount host paths, or bypass resource governance.
This moves security from best-effort documentation into an automated control plane. A pull request can still be reviewed by humans, but the cluster no longer depends on every reviewer remembering every platform rule. Tools such as Kyverno, Gatekeeper, and the newer ValidatingAdmissionPolicy API give platform teams a way to codify requirements as reusable policy. For many environments, Kyverno is especially approachable because policies are expressed as Kubernetes resources and can mutate, validate, or generate configuration without forcing application teams to learn Rego on day one.
## Admission controls that enforce provenance
Image provenance is where the workflow becomes particularly powerful. A signed image tells the cluster that the artifact came from a known build identity. An attestation can go further and describe how it was built: which repository produced it, which workflow ran, which commit was used, and whether tests or vulnerability scans passed. With Cosign and SLSA-style provenance, admission control can verify that the image was not only signed, but signed by the expected CI workflow for the expected source repository. That distinction matters when attackers try to push a validly signed artifact from an unrelated pipeline or compromised project.
The policy set should start narrow and grow deliberately. A sensible baseline for production namespaces is to require digest-pinned images, deny privileged containers, deny hostNetwork unless explicitly approved, require CPU and memory requests, block hostPath volumes, and require signed images from approved registries. Once that is stable, add checks for minimum Kubernetes security context fields such as runAsNonRoot, readOnlyRootFilesystem where possible, and seccompProfile. The goal is not to break every application immediately; it is to turn platform expectations into visible, testable contracts.
GitOps controllers need the same scrutiny as application workloads. Argo CD or Flux should run with least-privilege access to the namespaces they manage, not broad cluster-admin rights by default. Application projects should restrict destination namespaces and source repositories so one team cannot accidentally or maliciously deploy into another team's environment. If promotion between environments is automated, production sync should depend on artifact identity and policy status, not just on a branch name or image tag convention.
## Practical baseline for production namespaces
Policy testing belongs in CI before the admission webhook ever sees the manifest. Conftest, kyverno test, kubeconform, and Helm template validation can fail a pull request before a broken deployment reaches the GitOps controller. This reduces friction because developers receive feedback in the place where they are already working. The admission layer remains the final authority, but CI becomes the fast feedback loop that keeps the platform from feeling mysterious or arbitrary.
Exception handling is an important design detail. Every platform has workloads that need unusual privileges: CNI components, storage drivers, observability agents, and security tooling itself. Those exceptions should be explicit, namespace-scoped, time-bound where possible, and reviewed like code. A label that disables all policy checks across a namespace is convenient in an incident, but it becomes technical debt the moment the incident ends. Better patterns include narrow policy exclusions tied to service accounts, image identities, or specific workload names managed by the platform team.
Observability closes the loop. Admission denials should be visible in cluster events, GitOps sync status, and central logging. Platform teams should track which policies deny most frequently, which teams need enablement, and which controls create operational noise. That data helps distinguish between a valuable guardrail and a poorly designed rule. Over time, policy metrics become a practical measure of platform maturity: fewer emergency exceptions, more digest-pinned workloads, and a smaller gap between documented standards and deployed reality.
For infrastructure teams maintaining Kubernetes across clouds or customer environments, this approach provides a repeatable security foundation. Git remains the collaboration layer, CI remains the build and verification engine, and Kubernetes admission becomes the enforcement point closest to production. The result is not security theatre; it is a delivery pipeline where every artifact, manifest, and privilege request has to prove it belongs before it runs.
## Sources
A practical rollout can start with report-only mode for one namespace, then move to enforcement once teams understand the failure messages. Track rejected deployments, unsigned images, missing SBOMs, and emergency bypasses as platform reliability signals, not just security metrics. That gives engineering leaders a clear view of whether provenance controls are helping delivery or creating avoidable friction.
Sources for implementation details: [Sigstore Cosign documentation](https://docs.sigstore.dev/cosign/overview/) and [Kubernetes ValidatingAdmissionPolicy documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).