Enforce Container Trust with GKE Binary Authorization (2026)

Binary Authorization is GKE’s way of making sure only code you trust gets deployed to your clusters.

Let’s see it in action. Imagine you have a Kubernetes deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: gcr.io/my-project/my-trusted-app:v1.0.0

Normally, kubectl apply would just push this to your cluster. But with Binary Authorization enabled, GKE intercepts this. Before it allows the my-app-container to be scheduled, it checks if the image gcr.io/my-project/my-trusted-app:v1.0.0 has been approved by your defined policies. If it hasn’t, the deployment fails.

Binary Authorization works by enforcing policies at the Kubernetes API server level. These policies specify which container images are allowed to run. The core of this enforcement is a set of "attestations" – cryptographic signatures that vouch for the integrity and origin of an image. When you build your container images, you’ll have a process that generates these attestations. This process can be manual or automated, often integrated into your CI/CD pipeline.

The problem Binary Authorization solves is the "supply chain attack." Without it, a compromised build system, a malicious actor gaining access to your container registry, or even a developer making a mistake could lead to untrusted code running in your production environment. Binary Authorization acts as a gatekeeper, ensuring that only images that have passed through your security checks and have been explicitly approved can be deployed.

Here’s how you set it up:

Enable Binary Authorization API:
```
gcloud services enable binaryauthorization.googleapis.com
```
This makes the service available for your project.
Create a Policy: You define rules about what’s allowed. A common rule is requiring attestations from specific users or service accounts.
```
# policy.yaml
admissionRules:
- enforcementMode: ENFORCED_BLOCK_ON_FAILURE
  requireAttestationsBy:
  - projects/my-project/attestors/build-pipeline
clusterDefaultAdmissionRules:
  enforcementMode: ENFORCED_BLOCK_ON_FAILURE
```
This policy states that all deployments must be attested to by the build-pipeline attestor.
Create an Attestor: An attestor is an identity that can sign attestations. You can create one tied to a Google Cloud service account.
```
gcloud container binauthz attestors create build-pipeline \
  --project=my-project
```
This creates the build-pipeline attestor in your project.

Generate and Upload Attestations: In your CI/CD pipeline, after a successful build and scan of my-app:v1.0.0, you’d use the gcloud command to create an attestation. This involves signing a digest of the image.

# Example: Assuming you have the image digest
IMAGE_DIGEST="gcr.io/my-project/my-app@sha256:abcdef123..."
gcloud container binauthz attestations create \
  --project=my-project \
  --attestor=build-pipeline \
  --source-image="$IMAGE_DIGEST" \
  --artifact-url="$IMAGE_DIGEST" \
  --key-version=projects/my-project/attestors/build-pipeline/keyVersions/1

This command signs the image digest with the private key associated with the build-pipeline attestor and uploads the attestation.

Apply the Policy to your GKE Cluster:
```
gcloud container clusters update my-cluster \
  --zone=us-central1-a \
  --binauthz-policy-file=policy.yaml
```
This tells your GKE cluster to enforce the defined policy for all image deployments.

Once this is set up, if you try to deploy an image that hasn’t been attested to by build-pipeline, the Kubernetes API server will reject the request.

What most people don’t realize is that Binary Authorization doesn’t inherently scan your images for vulnerabilities. It relies on other systems (like Container Analysis, or third-party scanners) to perform those checks before generating the attestation. The attestation is simply a cryptographic guarantee that a trusted party has approved the image after whatever checks they deem necessary. You could, in theory, attest to a vulnerable image if your policy allowed it, but that defeats the purpose.

The next step is to explore how to integrate automated attestations directly into your CI/CD pipelines using service accounts and key management.