Image Signing, Sigstore, and Admission-Time Verification — CKA Cluster Operations Meet CKS Supply Chain Security

CKA reads the cluster; CKS writes the policy. Sigstore sits exactly on the line.

§ IFrame

CKA and CKS are written as if they were two halves of one job. CKA owns the cluster's operational layer: deployments, services, networking, storage, troubleshooting. CKS owns the security overlay: admission policy, runtime hardening, supply chain, secrets at rest. The two exams share the same kubectl, the same manifests, the same cluster topology; what differs is the question each exam asks of the same surface.

Image signing sits exactly on the line. CKA asks: can the operator deploy a signing-policy controller, manage its configuration, and debug when admission fails. CKS asks: can the operator write the signing policy in the first place, choose the right trust roots, and integrate Sigstore into the org's SDLC. The same artifact is the exam fixture for both questions.

§ IIDomain Foundations

The Sigstore project

Sigstore is a CNCF-graduated project that exists to make signing artifacts as automatic as compiling them. Three components compose the project. Cosign is the command-line and library that signs and verifies artifacts (container images, blobs, SBOMs, attestations). Fulcio is the certificate authority that mints short-lived X.509 signing certificates bound to OIDC identities. Rekor is the public append-only transparency log that records every Fulcio-issued certificate and every signing event.

Together the three enable keyless signing: a builder authenticates to Fulcio with an OIDC token, receives a certificate good for ten minutes, signs the artifact, uploads the certificate and signature to Rekor and the registry, and the certificate expires before the next coffee. The cluster verifies an artifact by checking that the certificate was issued by Fulcio, that the OIDC subject matches an allowed identity, and that the Rekor entry was created within the certificate's validity window.

The OCI 1.1 artifact model

OCI 1.1 codified storing artifacts other than container images in a registry. Before 1.1, signatures lived at a tag adjacent to the image (cosign's sha256-xxx.sig convention). With 1.1, signatures, SBOMs, and attestations reference an image's digest via the subject field in the manifest. Most major registries — GHCR, Docker Hub, Harbor, ECR, GAR — support 1.1 as of 2025.

The admission-controller chain (review)

The 2026-05-27 lesson covered admission controllers in depth. Summary: the API server runs every incoming object through a chain of mutating webhooks, then a chain of validating webhooks, then schema validation, then storage. A validating webhook receives an AdmissionReview and returns Allowed: true or Allowed: false with a reason. Sigstore's policy-controller is a validating webhook scoped to pod-create requests.

§ IIICKA Flavor — Operating a Sigstore Policy-Controller

The CKA exam asks operational questions in 100-minute live-cluster format. Image-signing surfaces in three CKA domains: workloads & scheduling, services & networking, and troubleshooting.

Installation and configuration. Sigstore's policy-controller installs via Helm. The candidate runs helm install policy-controller sigstore/policy-controller --namespace cosign-system --create-namespace. The chart creates the namespace, the deployment, the service, and the ValidatingWebhookConfiguration that registers with the API server.

Policy resources. The policy-controller defines the ClusterImagePolicy CRD (cluster-scoped, governs which images are allowed) with policy modes (enforce, warn). A policy names image patterns (glob-style) and authorities (Fulcio-keyless with named OIDC issuers, or static public keys).

Webhook failure modes. Validating webhooks can fail closed or fail open via the failurePolicy field. For supply-chain enforcement, the production posture is fail-closed. The policy-controller's own pod must be excluded from its own enforcement (the namespaceSelector excludes cosign-system and kube-system); enforcing on those creates a bootstrap deadlock.

Cluster-bootstrap order. The cluster must come up before its own enforcement runs. The CKA candidate should identify the namespaces excluded from admission (kube-system, kube-public, cosign-system, ingress-nginx-system) and explain why each exclusion exists.

§ IVCKS Flavor — Writing the Policy and Integrating Sigstore

The CKS exam asks security-policy questions in 120-minute live-cluster format. Image-signing is a named domain (Supply Chain Security, 20% weight).

Writing a ClusterImagePolicy. The CKS candidate writes the YAML, not just deploys someone else's. A minimal policy requiring images from ghcr.io/fleet-org/* be signed by a specific GitHub Actions workflow looks like:

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: fleet-org-must-be-signed
spec:
  images:
    - glob: "ghcr.io/fleet-org/*"
  authorities:
    - name: fleet-org-actions
      keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subject: https://github.com/fleet-org/agent-router/.github/workflows/release.yml@refs/heads/main
      ctlog:
        url: https://rekor.sigstore.dev

Five fields carry the policy. images.glob names the scope. authorities lists the acceptable signing identities. keyless.url names the Fulcio instance whose CA the cluster trusts. identities.issuer and identities.subject constrain who may have signed. ctlog.url names the Rekor instance whose transparency log entry the cluster will verify the signature appears in.

Multi-tier trust. The CKS-flavor question asks the candidate to design a trust architecture. Production namespaces require the production-release workflow; staging accepts either production or staging workflows; dev accepts any company-managed OIDC identity. The candidate writes the ClusterImagePolicy resources, names the trust boundaries explicitly, and verifies the policy with deliberate tests.

Integration with the SDLC. Where the policy-controller verifies, the build signs. Cosign in a CI workflow looks like cosign sign --identity-token=$OIDC_TOKEN $IMAGE_DIGEST. The CKS scenario might ask: the build is signing successfully, the registry has the signatures, but the cluster rejects the pod — why. The answer often is OIDC subject string mismatch (refs/heads/main versus refs/tags/v1.2.0).

Layered controls. Image signing catches an upstream supply-chain compromise. Admission policy catches manifest-injection. Runtime detection catches successful exploitation that bypassed prior layers. Pod security standards catch privilege escalation at the kernel surface. Each layer is necessary; none is sufficient.

§ VWorked Practice Scenario

The cluster has policy-controller installed and one ClusterImagePolicy requiring ghcr.io/fleet-org/* images to be signed by fleet-org/agent-router/.github/workflows/release.yml@refs/heads/main. The candidate's task: deploy a new image ghcr.io/fleet-org/audit-collector:v0.3.1 that the audit-collector team has just pushed and signed.

The candidate attempts kubectl apply -f audit-collector-deployment.yaml. The Deployment is created, but the Pod fails to schedule with the message admission webhook "policy.sigstore.dev" denied the request: no matching signatures.

The candidate investigates. kubectl logs -n cosign-system deployment/policy-controller --tail=50 shows the verification failure: the signature references workflow identity fleet-org/audit-collector/..., but the policy expects fleet-org/agent-router/....

The candidate recognizes the policy is too narrow and writes a second policy scoped to ghcr.io/fleet-org/audit-collector* with the audit-collector workflow as authority. kubectl apply; the next pod-create succeeds; the audit-collector workload runs. The CKS-flavor lesson is that policy granularity follows team boundaries; the CKA-flavor lesson is that the policy-controller's logs are the troubleshooting surface.

§ VIConnection to Today's Ops + Dev Lessons

The Ops lesson described the four-link chain (build → registry → keys → admission) at architecture level. The Dev lesson built one specific admission webhook in Go from scratch. This cert lesson reads the production-grade equivalent — Sigstore's policy-controller — through both CKA's operational lens and CKS's policy lens. The three lessons are a single triangle. The architect names the chain; the engineer builds one node; the operator deploys and policies the production node. A fleet that wants all three roles in one head reads all three lessons.

§ VIIPractice Questions

§ VIIIClosing

CKA reads the cluster; CKS writes the policy. Image signing closes the seam between build and deploy; the policy-controller is the artifact both exams ask the candidate to operate, write, and debug. The exam questions are scenarios drawn from production; the practice is the production discipline.

Wednesday next will return to β-Trust through a different lens — the data lens, the encryption-at-rest lens, the lineage lens — and the CKA+CKS pairing will return with it, layered onto whichever piece of the cluster fits. The chain continues; each Wed lesson lays one more link. Examine well.