Why the container image supply chain deserves its own control plane
Kubernetes platform teams spend significant effort on network policies, RBAC, pod security standards, and runtime detection. These are all necessary, but they defend the cluster from the inside out. They assume the workload running in the pod is the workload the team intended to run. That assumption is unsafe when the container image itself can be the attack vector. A compromised base image, a tampered binary pulled from a public registry, or a build-time dependency injection can bypass every cluster-side control because the malicious code runs inside an authorized pod with valid credentials.
The container image supply chain covers everything from the moment a developer commits code through the build pipeline, image registry, admission control, and finally pod execution. Each stage introduces distinct risks, and each risk requires a different control. Platform engineers who treat image security as a separate concern from cluster security build defense in depth that static policies cannot replace. For teams already running GitOps and admission policies, connecting image-level controls to cluster-level enforcement closes a gap that otherwise persists through the entire deploy cycle.
Understanding the threat model
The supply chain threat model for container images includes compromised base images from public registries, malicious dependencies introduced during build, tampered images in transit or at rest in a registry, outdated images with known vulnerabilities that pass through scanning gaps, and images deployed without integrity verification. None of these threats are theoretical. The software supply chain has been a primary attack vector across the industry, and containers amplify the risk because images encapsulate an entire filesystem that is rebuilt and redeployed on every release cycle. Addressing these threats requires controls at build, registry, and deploy time.
Scanning images at build and registry time
Image scanning is the most accessible supply chain control, but it is also the most frequently misconfigured. Scanning a single image after it is already in production misses the point. Scanning should run in the CI pipeline before the image is pushed to any registry, and again in the registry to catch newly discovered vulnerabilities in previously scanned images. Tools such as Trivy scan for OS package vulnerabilities, language-specific dependencies, and misconfigurations in a single pass and can be integrated into any CI platform as a step that fails the build when critical vulnerabilities are found.
On Google Cloud, Artifact Analysis provides vulnerability scanning for images stored in Artifact Registry and integrates with Container Analysis for metadata-rich results. The scanning results are surfaced in the GCP console and accessible through the API for automated policy decisions. A practical configuration is to block the CI pipeline from pushing images that have any critical or high-severity vulnerability with a known fix version. Lower-severity findings can be tracked and reviewed on a regular cadence without blocking deployments. The goal is not zero vulnerabilities at all times; it is preventing known-exploitable paths from reaching production.
Signing images with Cosign and Sigstore
Scanning tells you what vulnerabilities an image contains. Signing tells you who built the image and whether it has been tampered with since the build. Cosign, part of the Sigstore project, supports signing container images with keyless signing using ephemeral keys tied to an OIDC identity. This is the critical simplification that makes signing practical for platform teams: developers do not need to manage long-lived signing keys. The CI pipeline authenticates as itself through Workload Identity Federation, receives a short-lived signing certificate from the Sigstore transparency log, signs the image digest, and records the signature in an OCI-compatible registry alongside the image.
A practical signing workflow for a GKE environment looks like this in a CI step:
- Authenticate the CI runner to GCP with Workload Identity Federation using a dedicated service account scoped to the build project.
- Authenticate to the Sigstore public-good instance or a self-hosted instance using cosign login with the OIDC token from the GCP authentication.
- Build the container image and push it to Artifact Registry.
- Run cosign sign on the image digest. Cosign generates an ephemeral key pair, sends the public key to the Rekor transparency log, and stores the signature as an OCI artifact attached to the image.
- Record the image digest and signature digest in the deployment manifest or use a mutating admission webhook to inject the digest before deploy.
Verifying signatures in CI and at admission
The command to verify a signed image on any cluster or CI runner uses the same Cosign invocation:
cosign verify <registry>/<image>@<digest> --certificate-identity <expected-identity> --certificate-oidc-issuer https://accounts.google.com
This command checks the signature against the expected identity and the Sigstore transparency log and fails if the signature is missing, the identity does not match, or the image digest has changed since signing. The verification step should run in the CI pipeline that generates Kubernetes manifests and again in the admission controller when the manifest reaches the cluster.
Enforcing signed images with Kyverno admission policies
Scanning and signing mean nothing if the cluster will accept unsigned images anyway. Admission control is where image-level controls connect to cluster-level enforcement. Kyverno, a Kubernetes-native policy engine, supports Cosign image verification natively through a verifyImages rule. This rule intercepts every Pod creation request, extracts the container image reference, performs a cosign verify against the configured trust policy, and rejects the request if verification fails.
A Kyverno policy that enforces signed images for all pods in production namespaces looks like this:
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: verify-image-signature spec: validationFailureAction: Enforce background: false webhookTimeoutSeconds: 30 failurePolicy: Fail rules: - name: verify-cosign-signature match: any: - resources: kinds: - Pod verifyImages: - imageReferences: - "gcr.io/*" - "*.gcr.io/*" - "*.pkg.dev/*" attestors: - count: 1 entries: - keys: publicKeys: |- -----BEGIN PUBLIC KEY----- ...your public key... -----END PUBLIC KEY----- mutateDigest: true verifyDigest: true
In production, hard-coding a public key into the policy creates rotation overhead. A more practical approach is to use keyless signing with OIDC identity verification in the policy. Kyverno supports verifying keyless signatures by checking the certificate identity and OIDC issuer against the expected values from the CI pipeline. This eliminates key management entirely: the policy trusts images signed by a specific CI identity, and any image signed outside that identity or left unsigned is rejected at admission time.
Connecting image controls to the broader security stack
Image signing with admission enforcement is most effective when combined with the controls that surround it. GitOps admission and provenance policies ensure that the manifests defining the deployment are also traceable and verified. Runtime security tools such as Falco add detection for anomalous process activity inside the pod after it starts running. Secrets management ensures that the credentials the image uses at runtime are properly scoped and rotated. Each layer covers what the others miss: image signing prevents tampered images from entering the cluster, admission control enforces the signing policy, and runtime detection catches what happens after a legitimate image is running.
For platform teams running multi-cluster environments on GKE, the supply chain approach also simplifies compliance evidence. A Kyverno policy enforcing signed images produces an audit trail of every admission attempt. The Sigstore transparency log provides a verifiable record of every image signing event. Artifact Analysis scan results can be exported to Security Command Center for organization-wide visibility. When an auditor asks which images are running in production and whether their provenance is verifiable, the answer is no longer a manual inventory; it is the output of the enforcement system itself.
Practical path forward for platform teams
For teams that have not yet implemented container image supply chain controls, the priority order is:
- Add vulnerability scanning to the CI pipeline. Fail builds on critical vulnerabilities with a known fix. Use Trivy or GCP Artifact Analysis for automated scanning.
- Add image signing to the CI pipeline with Cosign keyless signing. Sign every image pushed to the production registry. Store signatures in the registry alongside the image.
- Deploy a Kyverno verifyImages policy in audit mode on a staging cluster first. Review the logs to confirm that expected images are signed correctly and that unsigned images are flagged. Tune the identity matchers before switching to Enforce mode.
- Enable verification in production admission. Start with one namespace and expand. Combine with existing admission rules for pod security standards and network controls.
- Connect the signing identity to the GitOps pipeline so that the same CI identity that produces the deployment manifest also signs the image. This connects provenance from code commit to running pod.
The return on investment for image-level supply chain controls is high because the same signing and scanning infrastructure protects every workload that runs in the cluster. One policy update or one build pipeline change applies to every image. Teams that already manage admission policies and GitOps workflows have most of the operational foundation in place; adding image signing and verification closes the gap between what the cluster enforces and what the builder intended.
If your team is managing Kubernetes deployments without image signing and admission-level verification, the gap between what your cluster enforces and what reaches production is wider than most dashboards show. Secpros can review your current container image pipeline, CI/CD controls, and admission policies to identify where tampered or vulnerable images could reach your clusters. A focused audit of your Kubernetes supply chain takes one to two days and produces a prioritized action plan aligned with your team's release cadence.