This article builds on the last one, where I covered securing the supply chain with Trivy, Cosign, and Falco. I explained that admission control stops harmful workloads from running, not just detecting them after the fact.

In this post, I'll explain how admission control works in Kubernetes, compare Kyverno and Gatekeeper based on real-world use, and share policies to block common risks like root containers, unsigned images, mutable tags, and workloads with unnecessary host access.

How Kubernetes Admission Control Works

Every request to the Kubernetes API goes through authentication, authorisation, and admission before the object is persisted.

• Authentication checks who is making the request. Authorisation, typically handled by RBAC, determines whether a person is permitted to perform the requested action.

• Admission control evaluates the submitted object. Admission plugins and webhooks can allow, modify, or reject the request based on defined policies.

• Many teams overlook this key security step. RBAC might allow someone to create Pods, but it does not verify whether those Pods run as root, use privileged containers, or pull images from untrusted sources. Authorisation answers, “Can you do this?” Admission control answers, “Does this follow our security policies?”

Why Scanning and Signing Alone Aren’t Enough

CI security controls are only effective when deployments follow the expected path. In real production environments, that assumption can break. An engineer may apply a manifest directly with kubectl during an incident, a CI runner could be compromised, or someone might deploy an old manifest that still uses privileged settings.

These situations often cause configuration drift. Admission control helps by adding a checkpoint inside the cluster. It checks workloads as they enter the Kubernetes API, so even if someone skips the usual CI/CD process, admission control can still block risky deployments. CI checks catch problems before deployment, while admission control prevents them from entering the cluster.

Mutating Webhooks vs Validating Webhooks

Kubernetes processes mutating admission first, followed by validating admission.

• Mutating policies can modify a workload by adding labels, setting default values, or injecting a sidecar.

• Validating policies review the workload and then decide to allow or reject it.

For example, Kyverno can automatically add runAsNonRoot: true if it is missing. A validating policy, on the other hand, can block workloads that do not meet this requirement. For important security settings, I prefer validation. It is safer to reject an insecure workload and tell the developer what to fix than to quietly change security-related settings.

Managing Policy as Code with GitOps

Treat security policies as code. Keep them in Git, review changes through pull requests, and use GitOps tools such as Argo CD or Flux to synchronise them with your clusters.

This applies to both namespace-level security settings and Kyverno or Gatekeeper policies. Avoid managing production policies manually with kubectl, because changes can become difficult to review, reproduce, or audit.

Enforcing Pod Security Standards at the Namespace Level

Before adding custom admission policies, Kubernetes already provides Pod Security Admission (PSA) as a built-in baseline. PSA applies Pod Security Standards at the namespace level. For example:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted

This acts as the first layer of enforcement. It sets a basic level of Pod security and doesn't require an extra policy engine. PSA doesn't address every organisation’s unique needs. Tools like Kyverno or Gatekeeper can then add controls for trusted registries, image signatures, resource requirements, and other organisation-specific security requirements.

Extending the Baseline with Kyverno

With the baseline in place, we can add more specific admission policies. For example:

• Blocking Root and Privileged Containers

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-and-privileged
spec:
  rules:
    - name: check-runasnonroot
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Containers must run as non-root and cannot be privileged."
        pattern:
          spec:
            securityContext:
              runAsNonRoot: true
            containers:
              - securityContext:
                  privileged: false

• Requiring CPU and Memory Limits on Every Pod

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  rules:
    - name: validate-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "CPU and memory requests and limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    cpu: "?*"
                    memory: "?*"
                  limits:
                    cpu: "?*"
                    memory: "?*"

• Restricting Deployments to Trusted Registries

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  rules:
    - name: allowed-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Images must come from myregistry.io."
        pattern:
          spec:
            containers:
              - image: "myregistry.io/*"

• Verifying Cosign Image Signatures at Admission

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  background: false
  rules:
    - name: verify-image-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "myregistry.io/*"
          failureAction: Enforce
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      <your-cosign-public-key>
                      -----END PUBLIC KEY-----

• Blocking ‘latest’ and Other Mutable Image Tags

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Images must use an immutable tag or digest, not 'latest'."
        pattern:
          spec:
            containers:
              - image: "!*: latest"

• Restricting hostPath, hostNetwork, and Privilege Escalation

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-host-access
spec:
  rules:
    - name: disallow-host-namespaces
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "hostPath, hostNetwork, and privilege escalation are not allowed."
        pattern:
          spec:
            =(hostNetwork): false
            =(volumes):
              - X(hostPath): null
            containers:
              - securityContext:
                  allowPrivilegeEscalation: false

Allowing these settings lets a compromised pod break out and access the node directly. Most application workloads do not need this access. Block it by default and allow exceptions only for specific system components that truly need it, with clear documentation.

Audit, Warn, Enforce: The Correct Rollout Order

• Start new policies in Audit mode to identify existing violations without blocking workloads. Review the results, test the policies, and fix legitimate violations before moving to Enforce.

• For Pod Security Admission, Kubernetes also provides Warn mode, which shows violations to users without blocking the request. Avoid switching directly to Enforce in a live cluster. Roll out policies gradually, starting with non-critical workloads, to prevent unexpected deployment failures.

The Full Pipeline: From Pull Request to Running Pod

• Developer opens a pull request; Trivy scans dependencies and secrets.

• On merge, CI builds the image, and Trivy scans it for HIGH and CRITICAL findings.

• CI generates an SBOM, and Cosign signs the image with a key stored in a Secrets Manager.

• The image ships to the registry; ArgoCD or Flux syncs the manifest to the cluster.

• Kyverno or Gatekeeper checks the workload against every policy: signature, registry, tag, resource limits, root and privilege settings, host access.

• If it passes, it's scheduled, and Falco starts watching it; if it fails, it's rejected before a single container starts.

There are four stages in one direction: CI/CD, the registry, admission control in front of the API server, and Falco runtime monitoring. Nothing reaches runtime without passing through the first three.

Real-World Attack Scenarios

These are not just theoretical risks. Recent threat intelligence indicates that attackers are targeting CI/CD pipelines, container registries, and Kubernetes control planes as part of software supply chain attacks. Google Threat Intelligence specifically highlights registry poisoning, unauthorised Kubernetes deployments, privileged workloads, and unsigned or modified container images as relevant attack patterns.

• Direct kubectl Deployment: During an incident, an engineer bypasses the CI/CD pipeline and deploys a workload quickly. If the manifest runs as root or uses excessive privileges, admission policies can reject it before the workload starts. This creates an enforcement boundary even when the normal deployment process is bypassed.

• Repointed latest Tag: An attacker with registry access can replace a legitimate image with a malicious version. Google Threat Intelligence specifically identifies container registry poisoning as a risk when compromised developer or CI/CD credentials overwrite legitimate images. Blocking latest and preferring immutable image references reduces this attack surface.

• Compromised CI Runner: If an attacker takes over a CI/CD workflow or runner, they can use its permissions to upload a changed image or steal credentials. Recent GitHub security advice points out that attackers are targeting CI/CD automation, including workflows and credential theft. By requiring a valid Cosign signature at admission, you add another security check. Even if a bad image gets into the registry, the cluster can block it before it runs.

The key takeaway is that CI/CD security, registry controls, and admission control should not be treated as separate defences. If one layer is compromised, the next layer should still have enough trust information to stop the workload from reaching production.

Handling Exceptions Without Losing Control

Security policies may require exceptions for legitimate workloads, especially system components that require elevated permissions. The goal is to make those exceptions controlled and auditable, not eliminate them.

• Define an owner: Every exception should have a clear owner and reason.

• Manage exceptions as code: Keep Kyverno PolicyException or Gatekeeper exemptions in Git and review them through pull requests.

• Keep them narrow: Scope exceptions only to the workloads that actually need them.

• Review them regularly: Add an expiry or review date so temporary exceptions don't quietly become permanent security gaps.

Common Mistakes with Kyverno and Gatekeeper

• Write small, focused policies instead of trying to cover everything in one. Debugging a rejected deployment with a large, complex policy is hard.

• Remember to use background scanning. Both tools can check resources already running in the cluster, not just new ones. This helps catch drift from before you set up the policy.

• Watch out for policy sprawl. Many overlapping policies with no clear owner can be worse than none, because no one knows what is actually being enforced.

• Do not think of admission control as the final step. It is an important layer, but not the whole security strategy.

Where Kubernetes Policy Enforcement Is Headed

Kubernetes' built-in ValidatingAdmissionPolicy brings simpler policy enforcement directly into the API server. For more advanced needs, Kyverno and Gatekeeper are still strong options. At the same time, Sigstore and SLSA are moving supply-chain security toward stronger provenance, automated verification, and less manual key management.

References

• Kubernetes documentation, kubernetes.io/docs

• CNCF, Cloud Native Security Whitepaper, cncf.io

• Kyverno documentation, kyverno.io

• OPA Gatekeeper documentation, open-policy-agent.github.io/gatekeeper

• Sigstore project, sigstoredev

• SLSA framework, slsadev

• Falco documentation, falco.org

Next in this series: Production Kubernetes Security: Securing Kubernetes Runtime, Network & Workload Identity

This article explains a practical approach to Kubernetes security based on zero-trust principles: verify everything, trust nothing by default, and expect a compromise at any point. We’ll cover the full process, from code commit to running containers in production, using tools now standard for experienced platform teams. These include Trivy for scanning, Cosign and SBOMs for supply chain security, and Falco for runtime detection. The aim is to provide you with a reference architecture, example YAML, and clear reasoning for each choice so you can adapt it to your needs.

The Kubernetes Threat Landscape:

Most teams don’t realise how broad a Kubernetes cluster's attack surface is until something goes wrong. In general, the risks fall into four main categories.

1. Supply chain risk. Base images pulled from Docker Hub, dependencies pulled from npm or PyPI, and Helm charts pulled from third-party repositories all represent code you didn't write and often didn't review. The 2021 Codecov breach and the more recent XZ Utils backdoor both showed how a single compromised upstream package can propagate into thousands of downstream deployments.

2. Misconfiguration risk. Overly permissive RBAC, containers running as root, missing resource limits, and workloads with hostPath mounts remain the most common root causes of Kubernetes incidents.

3. Runtime risk. Once a workload is compromised, lateral movement within a cluster is often trivial because pods can communicate with one another and with the Kubernetes API by default. A single vulnerable pod can become a foothold for privilege escalation to node level or cluster admin.

4. Identity and secrets risk. Long-lived service account tokens, secrets stored as plain Kubernetes Secrets, and shared credentials across environments turn a contained breach into a full-blown compromise.

Why Traditional Security Fails in Kubernetes:

Traditional security was designed for systems that don't change often. You usually have a firewall, a few servers, and infrastructure that stays the same for weeks or months. Kubernetes is different. Pods are temporary and can be replaced within minutes, often with different IP addresses. Because of this, security based only on IP addresses is no longer enough. Instead, it should be based on workload identity.

Kubernetes deployments also happen much more frequently. With GitOps and CI/CD, applications can be updated several times a day. Manual security reviews cannot keep up, so security checks must be automated throughout the deployment pipeline and at the cluster level. Trust is another challenge. Unlike traditional environments where internal systems were often trusted, every workload in Kubernetes should be verified before it is trusted. This is why Zero Trust has become a core security principle for Kubernetes.

Layered Defence Architecture: Shift-Left to Runtime.

A mature Kubernetes security setup has five layers, with each one designed to catch what the previous layer might miss.

1. Source and dependency scanning at commit and pull-request time, catching known vulnerabilities and secrets before merging code.

2. Build-time scanning and signing, where container images are scanned for vulnerabilities, an SBOM is generated, and the image is cryptographically signed.

3. Admission control, where Kubernetes itself refuses to schedule workloads that violate policy, including unsigned images, root containers, or missing resource limits.

4. Runtime detection, where tools like Falco monitor process and syscall behaviour for signs of compromise that no static scan could predict.

5. Continuous verification, where scheduled scans and drift detection catch newly disclosed vulnerabilities in images that were clean when they were first deployed.

Supply Chain Security: Trivy, SBOMs, and Cosign

The supply chain layer answers a simple question: can you prove what is actually running in your cluster, and that nobody tampered with it between build and deployment?

• Trivy scans for vulnerabilities and misconfigurations across container images, filesystems, IaC templates, and even Kubernetes manifests. A typical CI step looks like this:

- name: Scan image with Trivy
  run: |
    trivy image \
      --severity HIGH,CRITICAL \
      --exit-code 1 \
      --format table \
      myregistry.io/payments-api:${{ github.sha }} 

Failing the build on HIGH or CRITICAL findings is deliberate. If a scan runs but never blocks anything, it is a report, not a control.

SBOMs (Software Bills of Materials) provide an auditable inventory of every package, library, and dependency in an image. Generating one is now a single command:

trivy image --format cyclonedx --output sbom.json myregistry.io/payments-api:latest 

The real value of an SBOM often appears months later, when a new CVE is found in a library you didn’t even know you used. Instead of re-scanning every image, you can check your stored SBOMs and quickly see which workloads are affected.

Cosign, part of the Sigstore project, solves the tampering problem by signing images cryptographically after they pass scanning.

cosign sign --key cosign.key myregistry.io/payments-api:${GITHUB_SHA}
cosign verify --key cosign.pub myregistry.io/payments-api:${GITHUB_SHA}

Together, these three tools help you answer three questions: Is this image vulnerable? What’s inside it? Can I prove it hasn’t been changed since it was built?

Runtime Threat Detection with Falco:

Admission control prevents bad things from starting, but it can’t help if something goes wrong after a workload is running. That’s where Falco comes in. Falco uses eBPF or a kernel module to watch system calls in real time and checks them against a set of rules. It can catch issues that static scanning misses, because some problems only show up when the process is actually running.

A representative rule for detecting a shell spawned inside a container, a classic sign of a reverse shell or exploited RCE:

- rule: Terminal shell in container
  desc: A shell was spawned inside a container
  condition: >
    spawned_process and container and
    shell_procs and proc.tty != 0
  output: >
    Shell spawned in container (user=%user.name container=%container.name
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: WARNING 

Falco alerts should land somewhere a human can see within minutes, not in a dashboard checked once a week. Wiring Falco to Falcosidekick and routing alerts into Slack, PagerDuty, or a SIEM is the difference between catching an intrusion while it's happening versus finding it in a postmortem three weeks later.

End-to-End Secure Deployment Pipeline:

Here’s how a typical production pipeline from GitHub or Azure DevOps to Kubernetes usually works:

1. Developer opens a pull request. Trivy scans the filesystem and dependencies; secrets scanning runs alongside it.

2. On merge, CI builds the container image.

3. Trivy scans the built image for HIGH and CRITICAL vulnerabilities and fails the build if it finds any.

4. It generates an SBOM and stores it alongside the image in an artefact repository.

5. Cosign signs the image using a key held in a Secrets Manager, never committed to the repository.

6. The image is pushed to the registry.

7. ArgoCD or Flux syncs the new manifest to the cluster in line with GitOps practices.

8. Admission control validates the incoming workload for image signatures, non-root user access, resource limits, and the absence of privileged escalation. I'll walk through exactly how in the next article.

9. If the workload passes admission, we'll schedule it. If not, it is rejected before a single container starts.

10. Falco continuously monitors the running workload for anomalous behaviour throughout the pod's lifetime.

Each step here is automated and must be followed. Nobody should be able to bypass a signature check by asking nicely in a Slack channel.

Best Practices and Common Mistakes:

• Once you’ve tested a policy with real traffic, enforce it in “Enforce” mode, not just “Audit” mode. Teams that leave everything in audit mode are only collecting logs; they're not actively defending their systems.

• Don’t treat SBOMs as just a compliance checkbox. When new CVEs are announced, make sure to actually query them. An unreviewed SBOM is just taking up space.

• Don’t skip the runtime layer just because admission control seems enough. Admission control can’t catch vulnerabilities that are exploited after a signed image is already running.

Future Trends:

Kubernetes security is moving towards more automation and stronger verification.

• Sigstore makes image signing easier by removing the need to manage long-term signing keys.

• SLSA helps teams prove software was built securely and in a trusted way.

• in-toto verifies every step of the software delivery pipeline, from source code to deployment.

• SPIFFE and SPIRE give each workload its own secure identity rather than relying on IP addresses.

These technologies are the next step in Kubernetes security. The specific tools may change, but the goal stays the same: verify everything, trust nothing by default, and secure every part of the software supply chain.

References

• Kubernetes documentation, kubernetes.io/docs

• CNCF, Cloud Native Security Whitepaper, cncf.io

• Sigstore project, sigstoredev

• SLSA framework, slsadev

• in-toto project, in-toto.io

• SPIFFE/SPIRE, spiffe.io

• Trivy documentation, aquasecurity.github.io/trivy

• Kyverno documentation, kyverno.io

• OPA Gatekeeper documentation, open-policy-agent.github.io/gatekeeper

• Falco documentation, falco.org

Next in this series: Enforcing Kubernetes Security with Kyverno and OPA Gatekeeper