Block Unverified Container Images in GKE with Binary Authorization (2026)

Binary Authorization is the key to ensuring only trusted container images get deployed to your Google Kubernetes Engine (GKE) clusters.

Let’s see it in action. Imagine a developer pushes a new image to Artifact Registry. This image is tagged my-app:v1.2.0. Before it can even think about running in production GKE, it needs to pass through Binary Authorization.

Here’s a simplified view of the workflow:

1. Image Push: Developer pushes my-app:v1.2.0 to Artifact Registry.
2. Build Trigger: A CI/CD pipeline (e.g., Cloud Build) detects the new image.
3. Attestation Generation: The pipeline runs security scans, tests, and then, if successful, generates an "attestation." This attestation is a signed piece of metadata saying, "This image passed checks at this time." The signing is done by a dedicated service account.
4. Binary Authorization Policy Check: When a deployment to GKE is attempted using my-app:v1.2.0, Binary Authorization intercepts this. It checks the policy for the target cluster.
5. Attestation Verification: The policy requires an attestation from a specific authority (your CI/CD service account) for images deployed to production. Binary Authorization verifies the signature of the attestation against the public key of the signing service account.
6. Deployment Decision: If the attestation is valid and meets the policy requirements, Binary Authorization allows the deployment. If not, it blocks it.

The problem Binary Authorization solves is the "supply chain attack" vector where an attacker compromises a developer’s workstation or a CI/CD system to inject malicious code into an image. By requiring signed attestations from trusted sources, you create a verifiable chain of trust from your build system to your running containers.

You control this through a Binary Authorization policy. A policy consists of one or more "admission rules." Each rule specifies a "deployment occurrence" (e.g., a GKE cluster) and a list of "require attestations." These attestations are tied to "attestation authorities," which are essentially the service accounts that sign your attestations.

Here’s a snippet of what a policy might look like in YAML:

name: projects/my-gcp-project/policy
description: "Enforce verified images for production GKE clusters"
admissionRules:
- enforcementMode: ENFORCED_BLOCK_ON_FAILURE
  requireAttestations:
  - policy: projects/my-gcp-project/attestationAuthorities/my-ci-cd-signer
    # Optionally, specify a specific type of attestation, e.g., "image-scan-passed"
    # attestation: "image-scan-passed"
  cluster: "projects/my-gcp-project/locations/us-central1/clusters/prod-cluster"
- enforcementMode: ENFORCED_BLOCK_ON_FAILURE
  requireAttestations:
  - policy: projects/my-gcp-project/attestationAuthorities/my-ci-cd-signer
  cluster: "projects/my-gcp-project/locations/us-central1/clusters/staging-cluster"
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_ON_FAILURE
  requireAttestations:
  - policy: projects/my-gcp-project/attestationAuthorities/default-signer

In this example:

• my-gcp-project is your Google Cloud project ID.
• my-ci-cd-signer is the name of the attestation authority (which maps to a service account’s public key) that signs attestations from your CI/CD pipeline.
• prod-cluster and staging-cluster are the specific GKE clusters you want to protect.
• ENFORCED_BLOCK_ON_FAILURE means deployments will be rejected if the attestation requirements aren’t met.
• The defaultAdmissionRule applies to any cluster not explicitly listed, using a default-signer.

The magic happens because Binary Authorization integrates directly with the GKE API. When GKE receives a request to deploy a pod, it consults the Binary Authorization policy for that cluster. If the image being deployed doesn’t have a valid, signed attestation that satisfies the policy, GKE rejects the pod creation request before it ever gets scheduled or runs.

The most counterintuitive part is that Binary Authorization doesn’t scan your images itself. It doesn’t look inside the container for vulnerabilities. Its sole job is to verify that an external, trusted process (your CI/CD pipeline, a security scanner, etc.) has vouched for the image by signing an attestation. You must integrate your actual security scanning and validation steps before the signing process in your CI/CD pipeline. Binary Authorization is the gatekeeper, not the inspector.

Once you’ve successfully enforced image verification, your next challenge will be managing the lifecycle of these attestations, especially for internal images or for scenarios where you need to update policies without breaking existing deployments.