September 13, 2026

How to Set Up Binary Authorization in GKE: A Complete End-to-End Guide

Step-by-step guide to enabling Binary Authorization on GKE — from creating a PKIX KMS key and attestor to signing images with gcloud and…

By Raja Gupta

4 min read

Step-by-step guide to enabling Binary Authorization on GKE — from creating a PKIX KMS key and attestor to signing images with gcloud and deploying via YAML.

Why I wrote this

If you've tried setting up Binary Authorization on GKE, you've probably noticed the same thing I did: the official Google Cloud documentation covers each piece — enabling the feature, creating a KMS key, creating an attestor, signing an image — but it's spread across multiple separate docs, none of which walk you through the full pipeline in one place.

I recently set this up end-to-end in my own environment, and this post is the single walkthrough I wish I'd had — from enabling Binary Authorization at the cluster level, all the way to a signed image successfully deploying through a policy that requires attestation.

If you're securing your GKE supply chain and want to make sure only verified, signed container images can be deployed to your cluster, this guide covers the full path.

What is Binary Authorization?

Binary Authorization is a deploy-time security control for GKE (and Cloud Run) that lets you enforce a policy requiring container images to be signed by trusted authorities — called attestors — before they can be deployed to your cluster. If an image doesn't have the required attestation, Kubernetes simply refuses to schedule it.

This is especially useful for enforcing that only images which passed your CI/CD pipeline, vulnerability scanning, or a manual security review can reach production.

Prerequisites

Before starting, make sure you have:

  • A GKE cluster (Standard mode) with appropriate IAM permissions
  • gcloud CLI installed and authenticated
  • A Cloud KMS keyring and key location decided in advance
  • An image already pushed to Artifact Registry

Step 1: Enable Binary Authorization at the Cluster Level

Binary Authorization is not on by default — it has to be explicitly enabled per GKE cluster.

In the Google Cloud Console:

  1. Go to Kubernetes Engine → Clusters
  2. Select your cluster and click Edit
  3. Under Security, find Binary Authorization and toggle it On
  4. Save the changes

You can also do this via gcloud if you prefer CLI-first workflows, but the console path is the quickest way to confirm it's applied correctly the first time.

Step 2: Create a PKIX KMS Key Pair

Next, you need a PKIX key pair stored in Cloud KMS — this is the cryptographic key your attestor will use to verify signatures.

Google's official steps for this are here: Create a PKIX key pair

At a high level:

  1. Create (or select) a Cloud KMS keyring in a chosen region
  2. Create a new key within that keyring, selecting asymmetric sign as the purpose and an appropriate elliptic curve or RSA algorithm
  3. Once created, Cloud KMS generates a key version — this version is what you'll reference later during both attestor creation and image signing

Keep note of the project, location, keyring name, key name, and key version — you'll need all five values again in Step 5.

Step 3: Create an Attestor and Attach the KMS Key

An attestor is the entity whose signature Binary Authorization checks for at deploy time. You create the attestor, then attach the PKIX public key from Step 2 as its verification key.

Follow Google's guide here: Create the attestor

In short:

  1. Go to Security → Binary Authorization → Attestors in the console
  2. Click Create Attestor, give it a name, and link it to a Container Analysis note (created automatically if it doesn't exist)
  3. Add a public key to the attestor — select PKIX public key, and provide the KMS key resource ID you created in Step 2

This step is where the two pieces — your KMS key and your policy enforcement — actually get connected.

Step 4: Set the Binary Authorization Policy to Require Attestations

With the attestor in place, you now need to tell your cluster's policy to actually enforce it.

  1. Go to Security → Binary Authorization → Policy
  2. Under the Default rule, select Require attestations
  3. Add the attestor name you created in Step 3 to the list of required attestors
  4. Save the policy

From this point forward, any image that doesn't carry a valid attestation from this attestor will be blocked from deployment on this cluster.

Step 5: Sign the Image and Create the Attestation

This is the step that actually produces a valid, verifiable signature for a specific image digest, using the gcloud CLI.

Reference doc: gcloud beta container binauthz attestations sign-and-create

gcloud beta container binauthz attestations sign-and-create \
    --project="${ATTESTATION_PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${ATTESTOR_PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

A few things worth calling out from real-world testing:

  • --artifact-url must reference the image by digest (SHA), not by a mutable tag like :latest. Binary Authorization attests to a specific immutable image, not a tag.
  • ATTESTATION_PROJECT_ID and ATTESTOR_PROJECT_ID will often be the same project, but Binary Authorization supports cross-project setups if your attestor lives elsewhere.

Step 6: Deploy the Signed Image via YAML

With the image signed and the policy enforced, deployment works exactly like a normal Kubernetes deployment — as long as the image reference uses the same digest that was signed in Step 5.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: link-bio-app-deployment
  labels:
    app: link-bio-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: link-bio-app
  template:
    metadata:
      labels:
        app: link-bio-app
    spec:
      containers:
      - name: link-bio-app
        image: <image with SHA ID stored in artifact registry>
        ports:
        - containerPort: 8080 # Adjust this to match your application's listening port

Apply it as usual:

kubectl apply -f deployment.yaml

If everything in Steps 1–5 was configured correctly, the deployment is admitted and the pods roll out normally. If the image digest doesn't match a valid attestation, Kubernetes will reject the pod creation with a Binary Authorization denial message instead — which is exactly the enforcement you're testing for.

Result

In my test environment, this exact flow produced a successful deployment named scc-test5 — confirming that the signed image passed policy validation and was admitted to the cluster.

Wrapping Up

Binary Authorization is one of those GKE security features that's genuinely simple in concept — only deploy images that are signed and verified — but the setup is scattered across enough separate docs that it's easy to get stuck halfway through. Hopefully having all six steps in one place saves you the same trial-and-error I went through.

If you run into issues specific to cross-project attestor setups or CI/CD integration (e.g., signing automatically in a Cloud Build pipeline), that's a natural next post — let me know if that's useful.