Policy as code that security and platform teams both keep

Policy-as-code dies in two ways. Security writes a perfect gate that blocks the platform team’s ingress controller, then quietly becomes a rubber stamp. Or platform owns the policies, security reviews them in a slide deck, and a privileged DaemonSet ships on a Friday. The version that lasts is boring: a small set of rules in the same repo as the cluster contract, with exceptions that expire and tests that run on every change.

Policy belongs next to the cluster contract

If the platform already has a “how we run Kubernetes” repository — bootstrap, addons, golden Helm values — put admission policies there. Do not stand up a second GitOps root that only security can merge. Dual control is a CODEOWNERS file and a required review, not a second source of truth that drifts.

apiVersion: kyverno.io/v1
kind: PolicyException
metadata:
  name: ingress-capabilities-until-2026-10-01
spec:
  exceptions:
    - policyName: disallow-capabilities
      ruleNames: ["drop-all"]
  match:
    any:
      - resources:
          namespaces: ["ingress"]
          names: ["controller"]

Test the deny, test the allow

A policy without fixtures is a rumor. Keep a folder of good and bad pod specs and run them in CI against the same engine the cluster uses. When someone asks to weaken a rule, the PR should add a fixture that shows the new allow — and a date. Reviewers can argue about the fixture. They should not argue about vibes.

• Start with five rules: no privileged, no hostPath, no :latest, drop ALL capabilities, require a non-root user.
• Measure false positives for two sprints before you add a sixth.
• Make the exception YAML the only bypass. Chat approvals do not exist at 2 a.m.

If a policy cannot be explained in a paragraph to a new platform engineer, it will be disabled during the next incident. Write less policy. Keep it.