Binary Authorization: Attestation, Policy Enforcement, and Breakglass

You've locked down your CI/CD pipeline, scanned every image for CVEs, and signed your artifacts with cosign. Then someone pushes a container with a critical vulnerability directly to production via a kubectl run — bypassing every control you built. Binary Authorization exists to close that gap. It's not about preventing bad code from being written; it's about preventing untrusted code from running in production. Google Cloud's Binary Authorization (now also available on-prem with open-source tools) enforces that every container image must have a valid attestation from an approved authority before it can be deployed. No attestation? No deployment. But what happens when production is on fire and you need to push a fix immediately? That's where breakglass comes in — a controlled override that logs and alerts, but doesn't block the emergency. This article walks through the full lifecycle: signing images, configuring attestors, writing admission webhook policies, and implementing breakglass with audit trails. By the end, you'll have a production-hardened Binary Authorization setup that balances security with operational reality.

Why Binary Authorization Exists

Container supply chain attacks are not theoretical. In 2024, a compromised base image in a popular registry led to thousands of downstream deployments running cryptominers. Traditional image scanning catches known vulnerabilities but cannot verify provenance — who built the image, where it came from, and whether it was tampered with after build. Binary Authorization (BinAuthz) solves this by requiring a cryptographic signature (attestation) from a trusted authority before an image can run. The policy engine checks: Is the image signed by an approved key? Is the signature valid? Is the image in an allowed registry? If any check fails, the deployment is rejected. This shifts security left to deploy-time, not runtime. For organizations subject to SOC 2, PCI-DSS, or FedRAMP, BinAuthz provides auditable evidence that every container in production has been vetted. It also prevents lateral movement: even if an attacker gains access to a cluster, they cannot run arbitrary images without a valid attestation.

#!/bin/bash
# Verify an image has a valid attestation before deploying
IMAGE="gcr.io/my-project/my-app@sha256:abc123"
ATTESTOR_PROJECT="my-project"
ATTESTOR_ID="my-attestor"

# Fetch attestation from Binary Authorization API
attestation=$(gcloud container binauthz attestations list \
    --attestor="projects/${ATTESTOR_PROJECT}/attestors/${ATTESTOR_ID}" \
    --artifact-url="${IMAGE}" --format="value(attestation.name)")

if [ -z "$attestation" ]; then
    echo "FAIL: No valid attestation found for ${IMAGE}"
    exit 1
fi
echo "PASS: Attestation exists for ${IMAGE}"

Signing Images with Cosign

The foundation of Binary Authorization is image signing. We use cosign (part of the Sigstore project) to sign container images with a private key. The signature is stored as an OCI artifact in the same registry, linked to the image digest. Signing should happen at the end of your CI pipeline, after all tests and scans pass. Use a dedicated signing key per environment (dev, staging, prod) and store the private key in a secure key management system (KMS or Hardware Security Module). Never store signing keys in CI secrets — use workload identity federation to access KMS. The public key is registered with Binary Authorization as the attestor's public key. Signing the image digest (not the tag) ensures immutability: even if the tag is overwritten, the signature remains valid only for the original digest. Always sign with the SHA256 digest to prevent tag mutability attacks.

#!/bin/bash
# Sign a container image using cosign with a KMS key
IMAGE="gcr.io/my-project/my-app:latest"
DIGEST=$(crane digest ${IMAGE})
IMAGE_DIGEST="gcr.io/my-project/my-app@${DIGEST}"

# Sign using Google Cloud KMS key
cosign sign --key gcpkms://projects/my-project/locations/global/keyRings/my-keyring/cryptoKeys/signer/versions/1 \
    ${IMAGE_DIGEST}

echo "Signed ${IMAGE_DIGEST}"

Creating Attestors and Policies

An attestor is a logical entity that represents the authority to attest images. In Google Cloud Binary Authorization, you create an attestor and associate it with a public key. The policy defines which attestors are required for which images. For example, you might require two attestors: one from the security team and one from the build system. The policy can also specify constraints like allowed registries or image paths. Policies are evaluated at deploy time by the Binary Authorization admission controller. If the policy requires an attestor but the image lacks a valid signature from that attestor's key, the deployment is denied. You can also set up project-level policies that apply to all clusters in the project, or per-cluster policies for granular control. Use the gcloud CLI or Terraform to manage attestors and policies as code.

resource "google_binary_authorization_attestor" "build_attestor" {
  name = "build-attestor"
  description = "Attestor for CI/CD pipeline"
  attestation_authority_note {
    note_reference = google_container_analysis_note.build_note.id
    public_keys {
      ascii_armored_pgp_public_key = file("${path.module}/keys/build-pub.pgp")
      comment = "Build system key"
    }
  }
}

resource "google_binary_authorization_policy" "policy" {
  admission_whitelist_patterns {
    name_pattern = "gcr.io/my-project/allowed/*"
  }
  default_admission_rule {
    evaluation_mode = "REQUIRE_ATTESTATION"
    enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
    require_attestations_by = [google_binary_authorization_attestor.build_attestor.id]
  }
}

Deploying the Admission Controller

Binary Authorization enforces policies via an admission webhook in your Kubernetes cluster. On Google Kubernetes Engine (GKE), you enable Binary Authorization at cluster creation time. The admission controller intercepts all Pod create requests and checks the image against the policy. If the policy requires attestation and the image is not attested, the Pod is rejected with a clear error message. You can also run the open-source Binary Authorization admission controller on any Kubernetes cluster (including on-prem) by deploying the webhook and configuring it to call the Binary Authorization API. The webhook must have network access to the API and appropriate IAM permissions. For production, run the admission controller in a dedicated namespace with high priority and resource limits to avoid being evicted. Monitor the webhook's latency — it should add less than 100ms to deploy time.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: binary-authorization-admission-controller
  namespace: kube-system
spec:
  replicas: 2
  selector:
    matchLabels:
      app: binauthz
  template:
    metadata:
      labels:
        app: binauthz
    spec:
      serviceAccountName: binauthz-sa
      containers:
      - name: webhook
        image: gcr.io/cloud-marketplace/google/binauthz-admission-controller:latest
        args:
        - --project=my-project
        - --cluster-name=my-cluster
        - --cluster-location=us-central1
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

Policy Evaluation Flow

When a Pod is created, the admission controller evaluates the image against the policy. The flow: 1) Extract the image reference (registry, repository, digest). 2) Check if the image matches any admission whitelist patterns (e.g., system images). 3) If not whitelisted, determine the admission rule for the image's scope (project, cluster, or namespace). 4) If the rule requires attestation, query Binary Authorization API for attestations matching the image digest and required attestors. 5) Verify each attestation's signature against the attestor's public key. 6) If all required attestors have valid attestations, allow the Pod; otherwise, deny with a message listing missing attestors. This flow is synchronous and must complete within the admission webhook timeout (default 30 seconds). For large images with many attestations, consider caching attestation results to reduce latency.

package main

import (
	"context"
	"fmt"
	"time"

	binauthz "cloud.google.com/go/binaryauthorization/apiv1"
	binauthzpb "cloud.google.com/go/binaryauthorization/apiv1/binaryauthorizationpb"
)

func evaluateImage(ctx context.Context, image string) error {
	client, _ := binauthz.NewBinauthzManagementClient(ctx)
	defer client.Close()

	req := &binauthzpb.GetAttestationRequest{
		Name: fmt.Sprintf("projects/my-project/attestors/build-attestor/attestations/%s", image),
	}
	// Simulate API call with timeout
	ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
	defer cancel()

	attestation, err := client.GetAttestation(ctx, req)
	if err != nil {
		return fmt.Errorf("attestation check failed: %w", err)
	}
	if attestation == nil {
		return fmt.Errorf("no attestation found for %s", image)
	}
	return nil
}

Breakglass: Emergency Override

No security system should prevent incident response. Breakglass allows authorized users to bypass Binary Authorization in emergencies. In GKE, you can annotate a namespace with 'binaryauthorization.kubernetes.io/breakglass: true' to temporarily disable enforcement for that namespace. Alternatively, you can use a separate breakglass attestor that is only used during emergencies. The key is that breakglass must be auditable: every override is logged with the user, reason, and duration. Implement breakglass with a time-bound approval process. For example, a developer requests breakglass via a ticketing system, which automatically creates a temporary attestor that expires after 4 hours. The breakglass attestor's public key is stored in a secure location and only activated when needed. After the incident, revoke the breakglass attestor and review the logs.

#!/bin/bash
# Enable breakglass on a namespace for 4 hours
NAMESPACE="production-critical"
EXPIRY=$(date -u -d '+4 hours' +%s)

# Annotate namespace
kubectl annotate namespace ${NAMESPACE} \
    binaryauthorization.kubernetes.io/breakglass=true \
    binaryauthorization.kubernetes.io/breakglass-expiry=${EXPIRY} \
    --overwrite

echo "Breakglass enabled on ${NAMESPACE} until $(date -d @${EXPIRY})"

Audit Logging and Monitoring

Every Binary Authorization decision — allow, deny, or breakglass — must be logged. In GCP, use Cloud Audit Logs to capture all Binary Authorization API calls. Additionally, the admission controller logs each evaluation result. Set up alerts for denied deployments (potential attack) and breakglass activations (emergency). Use a SIEM or logging system to correlate BinAuthz events with other security signals. For example, a denied deployment from an unknown user followed by a breakglass activation from the same user might indicate a compromised account. Also monitor the health of the admission controller itself: if it stops responding, all deployments will fail. Set up a metric for webhook latency and error rate, and page the on-call if it exceeds thresholds.

resource "google_monitoring_alert_policy" "binauthz_denied" {
  display_name = "Binary Authorization - Denied Deployment"
  combiner     = "OR"
  conditions {
    display_name = "Denied deployments count"
    condition_threshold {
      filter     = "metric.type=\"logging.googleapis.com/user/binauthz/denied\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 0
    }
  }
  notification_channels = [google_monitoring_notification_channel.email.name]
}

Handling Image Updates and Rollbacks

When you update an image, you must sign the new digest. Your CI/CD pipeline should automatically sign every image that passes tests. For rollbacks, you need the previous image's digest and its attestation. Since attestations are stored per digest, rolling back to a previously signed image works seamlessly — the attestation already exists. However, if you need to roll back to an image that was never signed (e.g., before BinAuthz was enforced), you have two options: sign it retroactively (if you trust it) or use breakglass. Best practice: maintain a record of all signed digests in a deployment history database. When rolling back, verify that the target digest has a valid attestation. If not, treat it as a new deployment and require a fresh attestation.

#!/bin/bash
# Rollback to a previous signed image
PREVIOUS_DIGEST="sha256:def456"
IMAGE="gcr.io/my-project/my-app@${PREVIOUS_DIGEST}"

# Check attestation exists
if gcloud container binauthz attestations list \
    --attestor="projects/my-project/attestors/build-attestor" \
    --artifact-url="${IMAGE}" --format="value(attestation.name)" | grep -q .; then
    kubectl set image deployment/my-app my-app=${IMAGE}
    echo "Rolled back to ${IMAGE}"
else
    echo "No attestation for ${IMAGE}. Use breakglass or sign first."
    exit 1
fi

Multi-Cluster and Hybrid Environments

Binary Authorization can extend across multiple GKE clusters and even on-prem clusters using the open-source admission controller. For multi-cluster, use a centralized policy management: define policies in a central project and reference them from each cluster. This ensures consistency. For hybrid environments, run the admission controller on-prem and configure it to call the Binary Authorization API (which requires network connectivity to GCP). Alternatively, use a local policy engine that mirrors the GCP policies. The challenge is key distribution: on-prem clusters need access to the public keys of attestors. Store public keys in a secure location (e.g., a ConfigMap signed by a trusted key) and rotate them regularly. For air-gapped environments, consider a fully offline attestation system using Sigstore's offline mode.

apiVersion: v1
kind: ConfigMap
metadata:
  name: binauthz-config
  namespace: kube-system
data:
  policy.yaml: |
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/my-project/attestors/build-attestor
    admissionWhitelistPatterns:
      - namePattern: gcr.io/cloud-marketplace/*
  attestors.yaml: |
    attestors:
      - name: build-attestor
        publicKeys:
          - asciiArmoredPgpPublicKey: |
              -----BEGIN PGP PUBLIC KEY BLOCK-----
              ...
              -----END PGP PUBLIC KEY BLOCK-----

Testing Binary Authorization Policies

Before enforcing policies in production, test them in a non-production cluster. Use the same admission controller but with a dry-run mode: set enforcement mode to 'DRY_RUN_AUDIT_LOG_ONLY' to log violations without blocking. This allows you to see which deployments would be denied without impacting operations. Also, write integration tests that attempt to deploy unsigned images and verify they are rejected. Use a test attestor with a test key to simulate the full flow. Automate these tests in your CI pipeline to catch policy misconfigurations early. Additionally, test breakglass: verify that breakglass annotations work and that audit logs capture the override.

#!/bin/bash
# Test that unsigned image is rejected
kubectl run test-unsigned --image=gcr.io/my-project/unsigned:latest --dry-run=server 2>&1 | grep -q "denied"
if [ $? -eq 0 ]; then
    echo "PASS: Unsigned image denied"
else
    echo "FAIL: Unsigned image was allowed"
    exit 1
fi

# Test that signed image is allowed
kubectl run test-signed --image=gcr.io/my-project/signed@sha256:abc123 --dry-run=server 2>&1 | grep -q "created"
if [ $? -eq 0 ]; then
    echo "PASS: Signed image allowed"
else
    echo "FAIL: Signed image was denied"
    exit 1
fi

Key Rotation and Attestor Management

Signing keys must be rotated regularly — at least every 90 days. When rotating, add the new public key to the attestor while keeping the old key for a grace period (e.g., 30 days). This allows images signed with the old key to still be deployed until they are re-signed. After the grace period, remove the old key. Use a key management system that supports key rotation without downtime. For cosign, you can have multiple keys associated with an attestor. When signing, specify which key to use. The policy evaluation checks all keys associated with the attestor. Automate key rotation in your CI/CD pipeline: generate a new key pair, upload the public key to the attestor, and start signing with the new key. Revoke compromised keys immediately by removing them from the attestor.

#!/bin/bash
# Rotate signing key for build attestor
NEW_KEY="gcpkms://projects/my-project/locations/global/keyRings/my-keyring/cryptoKeys/signer-v2/versions/1"
OLD_KEY_ID="old-key-id"

# Generate new public key
cosign public-key --key ${NEW_KEY} > new-pub.pem

# Add new key to attestor (keep old key)
gcloud container binauthz attestors add-public-key build-attestor \
    --public-key-file=new-pub.pem \
    --comment="Key v2 - rotated 2026-07-12"

# After grace period, remove old key
gcloud container binauthz attestors remove-public-key build-attestor \
    --public-key-id=${OLD_KEY_ID}

echo "Key rotated. Old key will be removed after grace period."

Cost and Performance Considerations

Binary Authorization adds minimal cost: the admission controller is free (open-source), but the Binary Authorization API calls may incur charges based on usage. In GCP, the first 10,000 attestation verifications per month are free; after that, it's $0.10 per 1,000 verifications. For a busy cluster with thousands of deployments per day, this cost is negligible. Performance-wise, the admission webhook adds 50-200ms per Pod creation. For most workloads, this is acceptable. However, for high-frequency Pod scaling (e.g., HPA), consider batching attestation checks or using a sidecar that pre-fetches attestations. Also, the webhook itself consumes resources: allocate at least 256MB memory and 250m CPU per replica. Monitor resource usage and scale as needed.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: binauthz-webhook-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: binary-authorization-admission-controller
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Continuous Validation: Runtime Policy Checks Beyond Deploy Time

Binary Authorization Continuous Validation (CV) extends policy enforcement from deploy-time to runtime. While the project-singleton policy checks images at deployment, CV monitors already-running Pods and logs violations when images no longer meet policy requirements (e.g., an image's attestation was revoked, or a new vulnerability was discovered). CV uses check-based platform policies that support multiple check types: SimpleSigningAttestationCheck (standard attestation), SigstoreSignatureCheck (Sigstore/cosign signatures), VulnerabilityCheck (CVE thresholds), TrustedDirectoryCheck (allowed registries), SlsaCheck (SLSA provenance level), and ImageFreshnessCheck (max image age). This is critical for compliance: you can detect when a running container is using an image that was signed but later compromised. Enable CV by updating your GKE cluster with --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE for deploy-time enforcement plus CV monitoring. CV logs violations to Cloud Logging—set up alerts to respond within minutes. In production, use CV to enforce that all running images are less than 30 days old (ImageFreshnessCheck) and have a valid Sigstore signature.

gkePolicy:
  checkSets:
  - checks:
    - displayName: sigstore-signature-check
      sigstoreSignatureCheck:
        sigstoreAuthorities:
        - displayName: build-authority
          publicKeySet:
            publicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                -----END PUBLIC KEY-----
    - displayName: image-freshness-check
      imageFreshnessCheck:
        maxImageAgeSeconds: 2592000  # 30 days
    - displayName: vulnerability-check
      vulnerabilityCheck:
        maximumSeverity: HIGH
        maximumFixSeverity: HIGH
        allowedVulnerabilityIds: []

Sigstore Signature Check: Open-Source Signing with Cosign

Binary Authorization's SigstoreSignatureCheck verifies cosign-generated signatures stored as OCI artifacts alongside images in Artifact Registry. Unlike the standard attestation path that uses Artifact Analysis notes, Sigstore signatures are stored directly in the registry as OCI artifacts (tagged sha256-<digest>.sig). This simplifies the signing workflow: no separate note or occurrence management. Sign with cosign sign --key gcpkms://... and verify with cosign verify. The CV platform policy references the public key directly in PEM format. The Sigstore ecosystem also supports keyless signing via Fulcio (short-lived certificates tied to OIDC identity) and transparency logging via Rekor. For production, we recommend KMS-backed keys for deterministic signing (critical for reproducible builds) and Cloud KMS for key management. Keyless signing is suitable for CI/CD pipelines where the build identity (e.g., Google Cloud Build service account) serves as the attestation authority. Enable Rekor transparency logging for auditability but be aware of the external dependency.

#!/bin/bash
# Sign with KMS key and push signature to Artifact Registry
IMAGE="us-central1-docker.pkg.dev/my-project/my-repo/my-app:latest"

echo "Resolving image digest..."
DIGEST=$(gcloud artifacts docker images describe ${IMAGE} \
  --format='get(image_summary.digest)')
IMAGE_DIGEST="${IMAGE}@${DIGEST}"

# Sign with Cloud KMS (recommended for production)
cosign sign --key gcpkms://projects/my-project/locations/global/keyRings/my-keyring/cryptoKeys/cosign-signer/versions/1 \
  ${IMAGE_DIGEST}

# Keyless signing (alternative - uses OIDC)
# cosign sign ${IMAGE_DIGEST}

echo "Signature stored in Artifact Registry for ${IMAGE_DIGEST}"

Binary Authorization for Cloud Run and Cloud Service Mesh

Binary Authorization extends beyond GKE to Cloud Run and Cloud Service Mesh. For Cloud Run, enable BinAuthz on the service to enforce attestation for revisions. The same attestors and policies apply—if a new revision uses an unsigned image, deployment is blocked. Cloud Run enforces the policy at revision creation time. For Cloud Service Mesh, BinAuthz integrates with the sidecar injection admission webhook to verify images injected as sidecars. However, there are differences: Cloud Run does not support breakglass annotations (use IAM conditions instead), and Cloud Service Mesh requires additional IAM for the sidecar injector. In production, start with GKE enforcement, then extend to Cloud Run for serverless workloads. The policy model is the same, so attestors and key management are shared. Monitor enforcement across all platforms from the Binary Authorization dashboard in GCP Console.

# Deploy a Cloud Run service with Binary Authorization
REGION="us-central1"
SERVICE_NAME="my-secure-service"
IMAGE="us-central1-docker.pkg.dev/my-project/my-repo/my-app@sha256:abc123"

gcloud run deploy $SERVICE_NAME \
  --image=$IMAGE \
  --region=$REGION \
  --binary-authorization=DEFAULT

# Verify enforcement
gcloud run services describe $SERVICE_NAME \
  --region=$REGION \
  --format='value(binaryAuthorization)'