Policy as code & rollout

Version, review, audit→enforce the call graph.

Authorization policy is only as good as the discipline around it. A zero-trust cluster can accumulate hundreds of allow rules across dozens of services, so treating policy as reviewed, version-controlled code — and rolling it out safely — is what keeps it correct and prevents self-inflicted outages.

Policy as code

Every AuthorizationPolicy, PeerAuthentication, and RequestAuthentication should live in git alongside the workloads it governs, be reviewed like application code, and deploy through the same pipeline (ideally GitOps, so the cluster state matches the repo). This makes the security posture auditable — you can see who allowed the frontend to call the orders API, and when — and reversible, since a bad change is a revert. Author policies per workload rather than in one sprawling file, so ownership is clear and a change to one service’s rules does not risk another’s. The same principle applies as to admission, network, and IaC policy elsewhere in the curriculum: if it is not in version control and reviewed, it is not a control you can trust.

# Repo layout: authz policy lives with the workload, reviewed in PRs.
#   apps/orders/
#     deployment.yaml
#     authorizationpolicy.yaml    ← who may call orders, as reviewed code
#
# GitOps (Argo CD / Flux) reconciles it, so the cluster matches the repo.
# A bad allow rule is a git revert, not a live-cluster scramble.
# Diff shows exactly what access changed, by whom, when — auditable.

Discover the call graph, then enforce

The dangerous moment is flipping default-deny on: any legitimate service-to-service flow you did not anticipate breaks instantly. Avoid it by discovering the real call graph first — run the mesh in a permissive/audit posture and use its observability (Hubble, Kiali) to see which services actually talk to which, then write allow rules for those flows, and only then enforce default-deny. Roll out namespace by namespace, keep an escape hatch to revert a namespace to permissive, and monitor for denied requests that indicate a missed legitimate flow. This audit-then-enforce, waved rollout is the identical safe pattern used for admission, network, mTLS, and runtime enforcement throughout the course.