Advanced Track Do this after finishing Chapters 01-15.

Estimated Time

  • Reading: 30 min
  • Lab: 45 min
  • Quiz: 5 min

Prerequisites

  • Core track (Chapters 01-15) completed.
  • GitOps promotion and observability workflows available.

What You Will Produce

On your own kind cluster: the same pod admitted with a report in a namespace that audits, and refused with a reason in one that enforces; the fix that makes it pass; a weakened policy caught by its test before it could merge; an exception for one named pod that goes in through a pull request - while the same exception applied by hand is refused; and the gatekeeper switched off for a minute, to see what fail-closed means.

Chapter 16: Admission Policy Guardrails

Learning Objectives

By the end of this chapter, you will be able to:

  • Explain where an admission policy acts in the path of a request, and the difference between a policy that audits (records) and one that enforces (refuses)
  • Promote a rule from Audit to Enforce for the namespaces where the evidence says it is safe - and keep it in Audit where it is not
  • Grant an exception that is narrow, owned and temporary, through Git - and explain why one applied by hand is refused
  • Say what happens to the cluster when the policy engine is down, and why some namespaces are left out of it

Recall Check

Before continuing, quickly recall:

  • Which checks run on a pull request, and what can still reach the cluster around them? (Chapter 05)
  • What does Pod Security restricted refuse at admission - and what does it not look at? (Chapter 07)
  • Why is an image tag that can change a problem for a rollback? (Chapter 10)

If you can’t answer these, revisit the corresponding chapter before proceeding.

Context

The core track put guards before the cluster: a pull request’s checks, a review, image tags tied to their environment. None of the pull request checks reads a pod’s image tag or registry - check-image-tags.sh (Chapter 10) only ties each app overlay’s tag to its ImagePolicy - and a review sees only what the diff shows. The lab starts there: a pod with an untagged image runs, and only a report notices.

Admission is the last place a rule can act: the API server asks it about every object before storing it, whatever the object’s way in - Flux, a person with kubectl, an AI agent. Pod Security (Chapter 07) is one admission check, built in; this chapter adds a policy engine, Kyverno, with rules Pod Security does not have: no latest or missing image tags, only trusted registries, requests and limits on every container and init container.

A rule at admission can do two things with a violation: record it (Audit) or refuse the request (Enforce). Audit alone protects nothing - it is the evidence for Enforce. Enforce without that evidence breaks what was already running. And a rule that refuses needs a way to let one workload through on purpose - an exception that is as reviewed as the rule itself.

Work through each lesson section; the chapter video, once it is published, gives the concept overview.

Where the Rule Acts

Diagram: request Flux, kubectl, an AI agent; who is it? may it do this? (RBAC); mutating admission LimitRange defaults; validating admission Pod Security, native policies, Kyverno; Enforce: violation; refused, with the reason; Audit: violation; stored + PolicyReport entry; no violation; stored

Detailed Lessons

Hands-On Materials

Labs, quizzes and runbooks of the advanced track - sign in and redeem an access code.

  • Lab: Audit, Enforce, and One Exception Advanced
  • Quiz: Chapter 16 (Admission Policy Guardrails) Advanced
  • Runbook: Admission Refused Advanced