Kubernetes
Supply-Chain Security

CKA Image Management Meets CKS Signature Verification and Admission Control

§IFrame

The Certified Kubernetes Administrator exam asks whether you can run the images. The Certified Kubernetes Security Specialist exam asks whether you can prove the images are trustworthy before they run. Supply-chain security is where those two questions meet, and it is one of the six CKS domains — roughly a fifth of the exam by weight.

CKA scope is image management as cluster operation: how images are referenced, pulled, and pinned; how the kubelet authenticates to a private registry; how imagePullPolicy governs when bytes are re-fetched. CKS scope layers verification on top: scan images for vulnerabilities, verify signatures at admission, and reduce the trust granted to any single image before it becomes a running Pod.

The two lenses together answer the full supply-chain question: reference the exact image (CKA), then verify it was built and signed by someone you trust before admitting it (CKS). This lesson is the exam-prep face of today's Ops lesson; the objects and commands are the same ones you would deploy in production.

§IIDomain Foundations

Every workload begins with an image reference, and the CKS exam rewards knowing a reference has two forms. A tag — nginx:1.27 — is mutable; the registry can repoint it tomorrow. A digest — nginx@sha256:abc123… — is immutable, because the digest is a SHA-256 hash of the image content. Poulton (Docker Deep Dive, pp. 242–243) describes the content-addressable storage model that makes this true: change one byte and the digest changes. Pinning by digest is the first supply-chain control and it costs nothing.

The API server enforces trust through the admission chain. Kubernetes: Up and Running (pp. 262–263) describes the admission flow: after authentication and authorization, the request passes through admission controllers, and a validating admission webhook can accept or reject it before the object persists. Every supply-chain verification the CKS exam tests lives in this seat. If it is not enforced at admission, it is not enforced at all.

Poulton's Kubernetes Book (pp. 226–236) frames the CI/CD pipeline as the other end of the supply chain: the pipeline builds, scans, and signs; the cluster verifies. Sign at build, verify at admit. Neither end trusts the registry sitting between them.

§IIICKA Flavor Image Management and Registry Operations

Pull Policy and Digest Pinning

The pull policy decides when the cluster re-fetches:

spec:
  containers:
    - name: app
      image: registry.internal/app@sha256:9f86d0...
      imagePullPolicy: IfNotPresent

Always re-pulls on every Pod start — the safe default for mutable tags. IfNotPresent pulls only when the image is absent. Never requires preloading. When the image is pinned by digest, IfNotPresent is safe, because a digest cannot change out from under you: the node has those exact bytes or it does not.

Private Registry Authentication

kubectl create secret docker-registry regcred \
  --docker-server=registry.internal \
  --docker-username=fleet-ci \
  --docker-password=$TOKEN \
  --namespace=agents

spec:
  imagePullSecrets:
    - name: regcred
  containers:
    - name: app
      image: registry.internal/app@sha256:9f86d0...

A ServiceAccount can carry imagePullSecrets so every Pod using that account inherits registry access. The CKA exam also expects crictl fluency: crictl images lists node images, crictl inspecti shows a digest. When a Pod is stuck in ImagePullBackOff, these diagnose whether the problem is the reference, the credentials, or the registry.

§IVCKS Flavor Signature Verification, Scanning, and Admission

Image Scanning

trivy image --severity HIGH,CRITICAL --exit-code 1 \
  registry.internal/app@sha256:9f86d0...

The --exit-code 1 flag turns a finding into a build failure. Poulton (Kubernetes Book, pp. 226–236) places scanning in the pipeline, before the image reaches any cluster, because catching a vulnerable dependency at build is cheap and catching it in production is not.

Signature Verification at Admission

The control that most directly mirrors today's Ops lesson. The pipeline signs with cosign; the cluster verifies with a policy engine:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["agents"]
      verifyImages:
        - imageReferences:
            - "registry.internal/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZI...
                      -----END PUBLIC KEY-----

Restricting the Registry

A cheaper control: refuse any image not from a trusted registry. A Kyverno or OPA/Gatekeeper policy rejects a Pod whose image reference does not begin with registry.internal/. This closes the case where an attacker points a manifest at a public image.

§VWorked Practice Scenario

A namespace payments runs Pods pulling from mixed sources — some from the trusted internal registry, some from Docker Hub during debugging. Your task list under exam conditions:

1. Pin the production Deployment's image by digest rather than the :latest tag; verify with kubectl get deploy payments-api -o jsonpath='{.spec.template.spec.containers[0].image}'.
2. Create an imagePullSecret named internal-reg in payments and attach it to payments-sa so all Pods inherit registry authentication.
3. Scan the pinned image with trivy image --severity HIGH,CRITICAL --exit-code 1 and confirm it passes.
4. Apply a Kyverno ClusterPolicy in Enforce mode requiring every image in payments to reference registry.internal/ and carry a valid cosign signature.
5. Verify the gate: attempt to create a Pod referencing docker.io/library/nginx and confirm admission is denied.

This covers the full CKA+CKS supply-chain arc: pin the reference, authenticate the pull, scan the artifact, verify the signature at admission, prove the wall rejects an untrusted image. Roughly ten minutes under exam pressure.

§VIConnection to Today's Ops + Dev Lessons

The Ops lesson builds this exact architecture for a production fleet: sign at build, verify at admit, pin by digest between. This cert lesson is the same knowledge under exam conditions — identical cosign signing, identical admission-webhook verification, identical digest-pinning. The Dev lesson takes the supply chain one layer down, into the npm dependency graph inside the container this lesson admits. The trivy image scan here and the npm audit gate there are the same control at two depths: one scans the assembled image, the other scans the JavaScript dependency tree. Both fail the build on a high-severity finding.

§VIIPractice Questions

§VIIIClosing

Poulton (Kubernetes Book, p. 236) observes that the strongest cluster controls fail when the image itself is compromised at the source, which is why supply-chain security reaches back into the pipeline rather than living only at the cluster. The CKS exam exists to verify a practitioner can enforce trust at both ends: scan and sign at build, verify and restrict at admit.

CKA runs the image. CKS proves the image before it runs. Digest-pinning is the seam between them, because a pinned reference is the thing a signature signs and an admission policy verifies. Run the §V scenario until pin, authenticate, scan, sign-verify, prove-denied completes in under ten minutes. Speed on crictl, trivy, cosign, and the Kyverno verifyImages block is what the exam measures.