Supply chain security is the practice of making sure every piece of software and configuration that enters your Kubernetes cluster is safe and follows your organisation's rules. Policy enforcement and admission controllers are the automated bouncers that check each request before it is allowed in, preventing dangerous or non-compliant code from ever running. For the CKS exam, you must understand how to set up and use these tools to protect the cluster from the moment a developer submits a change until it is running in production.
Jump to a section
A simple way to picture Supply Chain Security: Policy Enforcement and Admission Controllers
Before anyone can enter a high-end nightclub, a bouncer checks every person against a strict list of rules. First, the club owner publishes policies: no one under 21, no glass bottles, no gang colours, and everyone must show valid ID. This policy set is the equivalent of a Kubernetes admission control policy. The bouncer stands at the door, and as each guest arrives, they must stop and submit to inspection. The bouncer does not check the guest's entire life story — only the things on the list. If a guest tries to sneak in a flask of whiskey, the bouncer spots it and turns them away before they ever set foot on the dance floor. This is exactly how an admission controller works: it intercepts every request to create or modify a resource in a Kubernetes cluster, checks it against the rules you have defined, and either allows it or rejects it on the spot. The bouncer never lets a banned person inside to cause trouble later. In the same way, policy engines like OPA/Gatekeeper or Kyverno act as that security guard, ensuring only compliant containers, images, and configurations ever enter the cluster. The party inside stays safe because the door is locked tight against anything that breaks the rules.
Kubernetes is a platform that runs containerised applications. A container is a lightweight, standalone package that includes everything needed to run a piece of software: the code, runtime, system tools, libraries, and settings. When a developer or a CI/CD pipeline sends a request to create a Pod (the smallest deployable unit in Kubernetes), that request goes to the Kubernetes API server. The API server is the front door of the cluster — every operation goes through it.
An admission controller is a piece of code that intercepts requests to the API server after authentication and authorisation have happened, but before the object is persisted (saved to the cluster's database, called etcd). This is the perfect place to enforce security policies because you can inspect and modify the request before it becomes permanent. There are two types of admission controllers: mutating and validating. A mutating admission controller can change the request — for example, adding a default security context that prevents the container from running as root. A validating admission controller can only accept or reject the request — it cannot modify it. Both types can be chained together, so a request goes through mutating controllers first, then validating controllers.
Policy engines are tools that let you define rules in a high-level language and then plug them into the admission controller framework. The two most important ones for the CKS exam are Open Policy Agent (OPA) with Gatekeeper, and Kyverno. OPA is a general-purpose policy engine that uses a language called Rego to write rules. Gatekeeper is a Kubernetes-specific implementation of OPA that works as an admission controller. You write policies in Rego, and Gatekeeper enforces them on every API request. Kyverno is a Kubernetes-native policy engine that uses YAML (the same format as Kubernetes resources) to define policies, making it easier for Kubernetes administrators to learn and write.
Why does this matter for supply chain security? Because a modern software supply chain is complex. A developer might pull a container image from a public registry like Docker Hub, use it in their application, and then deploy it to the cluster. That image could contain vulnerabilities, be configured to run as root, or include a backdoor. Supply chain attacks exploit the chain of dependencies — libraries, base images, configuration files — that make up a deployed application. By using admission controllers with policy engines, you can enforce rules such as:
Only allow container images from approved registries (e.g., your internal registry, not random public ones)
Require that images have been signed (using tools like cosign) and the signature is verified
Prevent containers from running with root privileges or from mounting sensitive host paths
Ensure that every Pod has resource limits (CPU and memory) to prevent runaway resource consumption
Mandate that all images have a specific label or annotation for auditing
Before admission controllers, these checks had to be done manually by reviewers or enforced at the CI/CD pipeline level. The problem was that if a developer bypassed the pipeline (for example, by running kubectl apply directly), the cluster would accept the dangerous configuration. Admission controllers close that gap because they run inside the cluster and cannot be bypassed — every request goes through them.
In practice, you install a policy engine like Gatekeeper or Kyverno into your cluster as a set of Pods and Custom Resource Definitions (CRDs). CRDs are extensions to the Kubernetes API that let you define your own resource types. You then write policy definitions as CRDs. When a request arrives, the policy engine checks the request against all active policies. If any policy is violated, the request is rejected with a clear error message telling the developer what rule they broke. This is immediate feedback, so developers can fix their manifests before those manifests ever become live objects in the cluster.
The CKS exam will test your ability to understand these concepts, interpret policy definitions, and identify the correct steps to enforce supply chain security policies. You do not need to become an expert in writing Rego policies, but you must know what the tools do, how they fit together, and what best practices look like.
Identify Policy Requirements
Review the security requirements for the cluster. For supply chain security, typical requirements include: only images from approved registries, images must be signed, containers must not run as root, and every Pod must have resource limits. Document these rules before writing any code.
Install the Policy Engine
Deploy the chosen policy engine (Kyverno or OPA/Gatekeeper) into the cluster. This is typically done using Helm charts or kubectl apply on the release manifest. Verify the installation by checking that the policy engine's Pods are running in the designated namespace (often gatekeeper-system or kyverno).
Write or Obtain Policy Definitions
Create the policy resource. For Kyverno, this is a ClusterPolicy YAML file. For Gatekeeper, you create a ConstraintTemplate and then a Constraint. The policy specifies what to match (e.g., all Pods) and what to validate (e.g., the container image must start with 'registry.internal.company.com/'). Use a text editor or the kubectl command line.
Test the Policy in Dry-Run Mode
Apply the policy with dry-run enabled so it logs violations without blocking requests. This lets you see if the policy is too restrictive or has mistakes. Submit a compliant request and a non-compliant request, then check the policy engine's logs to confirm the correct behaviour.
Enable Enforcement Mode
Once testing confirms the policy works as intended, switch it from dry-run to enforcement mode (often just removing the dry-run annotation or setting a field to true). Now the policy will actively block non-compliant requests.
Audit Existing Resources
Run a manual or automated audit of all existing Pods and other relevant resources to identify any that violate the new policy. Use kubectl get pods --all-namespaces and check each one against the policy rules. Schedule replacements for non-compliant resources.
Monitor and Update Policies
Continuously monitor policy violations via logs and metrics. Update policies as new vulnerabilities are discovered or as business requirements change. Keep policies in a version-controlled repository and use a CI/CD pipeline to deploy them.
Let us walk through a typical day for an IT professional who manages Kubernetes security at a medium-sized company. This person, call them Sam, is responsible for ensuring that every container running in the company's cluster is safe and follows internal policies.
Sam starts the morning by checking the latest security advisories. They learn about a critical vulnerability in a popular Node.js base image that attackers are actively exploiting. The vulnerability allows remote code execution if the container runs as root. Sam knows that some development teams have been using this base image for their microservices. They need to act fast to prevent any new deployments from using the vulnerable image.
The company already has Kyverno installed as a policy engine. Sam logs into the cluster using kubectl, the command-line tool for interacting with Kubernetes. They navigate to the policy definitions stored in a Git repository, which acts as the single source of truth. Sam updates an existing policy that restricts which registries images can be pulled from. They add a specific rule: any image from the vulnerable registry (or a specific tag) must be rejected unless it has been signed by the security team and the signature is verified. The policy also mutates any new Pod that tries to run as root by adding a security context that forces it to run as a non-root user.
Sam applies the updated policy by running kubectl apply -f policy.yaml. The Kyverno controller picks up the change and now enforces the new rule on every subsequent request. A few minutes later, a developer in the payments team submits a new deployment manifest that uses the vulnerable base image and does not specify a security context. The developer runs kubectl apply and immediately sees an error message: "Policy 'block-vulnerable-images' rejected the request. Image 'docker.io/library/node:latest' is from a restricted registry and runs as root. Use approved image from registry.internal.company.com/node:latest-signed." The developer is confused because the pipeline did not catch this earlier, but Sam has trained the teams to understand that admission controllers are the final safety net.
The developer updates their Dockerfile to use the approved image, builds a new container, signs it with cosign (a tool for signing container images), and submits again. This time the request passes Kyverno's checks, and the Pod is created successfully. Sam then reviews the audit logs to confirm that the blocked requests were legitimate attempts and not an attacker probing the cluster. They also set up alerts for any policy violation so they can respond quickly if a pattern of blocked requests indicates malicious activity.
Later that week, Sam needs to audit all running Pods to ensure none have slipped through before the policy was updated. They use a tool like kubectl audit or kube-bench to check the cluster's existing state, because admission controllers only intercept new requests — they do not retroactively apply to running objects. Sam finds two old Pods that are still using the vulnerable image and schedules them for replacement. They also add a cron job that periodically scans the cluster for policy violations and reports them to the security dashboard.
This scenario shows that the IT professional's job is not just to install a policy engine. It involves:
Writing and maintaining policies that balance security and developer productivity
Testing policies in a non-production cluster before rolling them out to production
Educating developers about why a request was blocked and how to fix it
Auditing existing resources to ensure compliance
Monitoring policy violations for signs of attack
All of these tasks are core to the role of a Kubernetes security specialist, and the CKS exam will test your understanding of them.
The CKS exam is a hands-on, performance-based test. You will not be asked multiple-choice questions about admission controllers — you will have to actually configure them in a live cluster. The exam presents you with a scenario, a cluster, and a set of tasks. Your job is to complete those tasks correctly and efficiently. The exam environment uses real terminal windows, and you type real commands.
For the objective 'Implement admission controllers and policy engines (e.g., OPA/Gatekeeper, Kyverno)', the exam expects you to know the following specific things:
The difference between mutating and validating admission controllers, and in what order they execute (mutating first, then validating). This is a common trap: a mutating policy might fix a problem, and then the validating policy passes. If you apply them in the wrong order, the validating policy might reject a request that could have been fixed.
How to write a basic Kyverno policy in YAML. You need to understand the structure: apiVersion, kind (ClusterPolicy or Policy), metadata, spec with rules, match, validate or mutate patterns. A common exam task is to create a ClusterPolicy that rejects any Pod running as root.
How to use OPA Gatekeeper with Constraint Templates and Constraints. A Constraint Template defines the logic (in Rego) for a type of policy, and a Constraint applies that logic to specific resources. You need to know how to install Gatekeeper, create a ConstraintTemplate, and then create a Constraint that enforces a rule like 'all images must come from a specific registry'.
The concept of 'dry run' policies. Before enforcing a policy, you can run it in dry-run mode to see what it would affect without actually blocking anything. The exam might ask you to test a policy in dry-run mode first, then switch it to enforcement mode.
How to verify that a policy is working. This means submitting a compliant request and a non-compliant request, and checking that the non-compliant one is rejected. You might be asked to capture the error message in a file as evidence.
Common traps the exam sets:
They give you a policy with a syntax error. You must identify the error and fix it. For example, a missing field in the match block or a Rego rule that references a non-existent variable.
They ask you to enforce a policy but the policy engine is not installed. You need to install it first (often via a Helm chart or a kubectl apply command on the release manifest).
They use obscure policy parameters. For example, requiring that a Pod has a specific label or annotation, or that the container image includes a digest (the hash) rather than just a tag. The exam expects you to know how to check for these in the policy definition.
They present a scenario where you need to use a dynamic admission controller (like Kyverno) to mutate a request. For example, adding a default seccomp profile to every Pod that does not already specify one.
Key definitions to memorise:
Admission controller: intercepts API requests after auth, before persistence.
Mutating admission controller: modifies the request.
Validating admission controller: rejects or allows the request without modification.
OPA: Open Policy Agent, a general-purpose policy engine using Rego.
Gatekeeper: Kubernetes-specific implementation of OPA as an admission controller.
Kyverno: Kubernetes-native policy engine using YAML.
ConstraintTemplate: OPA Gatekeeper resource defining the policy logic and schema.
Constraint: OPA Gatekeeper resource applying the template to specific resources.
ClusterPolicy: Kyverno resource that applies to the entire cluster.
Policy (namespaced): Kyverno resource scoped to a single namespace.
You should also be comfortable with kubectl commands: kubectl apply, kubectl get constrainttemplates, kubectl get constraints, kubectl describe clusterpolicy, and kubectl logs to check the policy engine's Pod logs for errors.
Admission controllers intercept all API requests to the Kubernetes API server after authentication and authorisation, and before the object is persisted to etcd.
Mutating admission controllers can modify a request (e.g., add default security settings), while validating admission controllers can only accept or reject a request.
Kyverno uses YAML policy definitions that look like Kubernetes resources, making it more accessible than OPA/Gatekeeper which requires Rego language.
OPA Gatekeeper uses ConstraintTemplates (defining the policy logic) and Constraints (applying the logic to specific resources).
Existing resources created before a policy is enabled are not automatically re-evaluated; you must audit them separately.
For supply chain security, admission controllers can enforce rules like 'only allow signed images from approved registries' and 'prevent containers from running as root'.
The CKS exam tests practical skills: you install the policy engine, write or modify a policy, test it with dry-run mode, and enforce it on the cluster.
A common exam trap is a policy with syntax errors; you must be able to read logs and correct the YAML or Rego code.
Policy engines themselves run as Pods inside the Kubernetes cluster and can be deployed using Helm charts or kubectl commands.
Admission controllers do not replace CI/CD pipeline security; they are a complementary final layer that prevents bypasses.
These come up on the exam all the time. Here's how to tell them apart.
Kyverno
Policies written in YAML, same format as Kubernetes resources
Kubernetes-native, developed by Nirmata
Supports both mutating and validating policies natively
OPA Gatekeeper
Policies written in Rego, a custom declarative language
General-purpose policy engine that works beyond Kubernetes
Requires separate ConstraintTemplate and Constraint resources
Mutating Admission Controller
Can modify the request before persistence
Runs before validating controllers
Example: adding a default security context to a Pod
Validating Admission Controller
Can only accept or reject the request
Runs after mutating controllers
Example: checking that an image comes from an approved registry
Policy Engine (Kyverno/Gatekeeper)
Operates at the Kubernetes API level
Controls what resources can be created or modified
Used for supply chain security and configuration compliance
Network Policy
Operates at the network layer (L3/L4)
Controls traffic flow between Pods
Used for micro-segmentation and network security
Admission Controller
Runs inside the cluster, intercepts every API request
Cannot be bypassed if a developer runs kubectl direct
Catches issues at deployment time
CI/CD Pipeline Security Scan
Runs outside the cluster, in the build/CI pipeline
Can be bypassed if a developer runs commands outside the pipeline
Catches issues at build time
Mistake
Admission controllers are the same as network policies or firewall rules.
Correct
Admission controllers inspect API requests before resources are created or updated, while network policies control traffic between Pods. They operate at completely different layers of the stack.
The word 'policy' appears in both, so beginners assume they do the same thing. One works at the API level, the other at the network level.
Mistake
Once you set an admission controller policy, it automatically applies to all existing resources in the cluster.
Correct
Admission controllers only intercept new or modified requests. Existing resources that were created before the policy was enabled are not affected and must be audited separately.
People expect policies to be retroactive because that is how many other security tools (like antivirus) work. Kubernetes does not re-evaluate existing objects when a new policy is added.
Mistake
You need to write Rego code for all policy engines, including Kyverno.
Correct
Rego is specific to OPA/Gatekeeper. Kyverno uses YAML that mirrors Kubernetes resource definitions, making it easier to learn and maintain.
Because OPA is more famous and has been around longer, beginners assume all policy engines use the same language. Kyverno's YAML approach is a major selling point but is less known.
Mistake
A mutating admission controller is dangerous because it can change any part of the request, so it should be avoided.
Correct
Mutating controllers are extremely useful for adding default security settings (like non-root user, resource limits, labels) and are safe when properly configured. They are a best practice for ensuring baseline security without relying on developers.
The word 'mutate' sounds like something harmful or out of control, but in Kubernetes it is simply a controlled modification. Beginners fear it without understanding its value.
Mistake
The CKS exam expects you to memorise all Rego syntax and write complex policies from scratch.
Correct
The exam tests your ability to understand and modify existing policies, not write complex ones from scratch. You need to know the structure and common keywords, but you will not be asked to write a full Rego library.
Many official CKS study guides go deep into Rego, which makes beginners panic. The actual exam is more about practical application of pre-written templates.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Kyverno uses YAML policies that look like Kubernetes resources, which is easier for beginners. OPA Gatekeeper uses Rego, a more powerful but steeper language. Both do the same job: enforce policies as admission controllers.
No, admission controllers only intercept new or updated API requests. Existing resources that were created before the policy was enabled are not affected and must be audited and updated separately.
Yes, you can run multiple admission controllers in the same cluster. They are independent webhooks, so they will each evaluate every request. This is useful for layered security but adds complexity.
Use the command kubectl get mutatingwebhookconfigurations and kubectl get validatingwebhookconfigurations. This lists all the admission controllers registered with the API server.
A mutating admission controller ensures that security settings are applied automatically and consistently, even if a developer forgets or makes a mistake. It prevents human error and enforces organisational policies without requiring developer compliance.
Supply chain security means ensuring that every component that goes into your deployed application — container images, libraries, configuration files — is trusted, verified, and free from vulnerabilities. Admission controllers enforce this by blocking untrusted or non-compliant resources.
You've finished Supply Chain Security: Policy Enforcement and Admission Controllers. Continue through the CKS study guide to build a complete picture of the exam.
Done with this chapter?