Binary Authorization on GCP has been generally available for over five years, and the adoption pattern in 2026 is bifurcated: teams that turn it on early in their cluster lifecycle run it without incident, and teams that try to bolt it onto existing production discover the operational tax is non-trivial. This runbook is for the second group.
What does Binary Authorization actually enforce?
Binary Authorization is an admission controller for GKE, Cloud Run, and Anthos clusters that verifies signed attestations against container images before allowing them to deploy. The default policy template requires images to come from approved registries, optionally with valid attestations from named attestors. The attestors are identity holders, typically your CI pipeline or your security scanning tools, that have signed an assertion about the image. A typical mature policy requires three attestations: the build provenance attestation from the CI pipeline, a vulnerability scan attestation from the registry or scanner, and a manual or automated approval attestation from a security review process. The policy decision happens at pod admission, which means any deployment that pulls a non-conforming image fails to start and produces a clear error in the audit log. The enforcement model is straightforward; the operational complexity comes from the attestation pipeline that produces the signatures the policy requires.
How do you structure the attestation pipeline?
The standard attestation pipeline runs as part of your Cloud Build or Cloud Deploy workflow. After the image build completes and the image is pushed to Artifact Registry, the pipeline invokes the gcloud container binauthz attestations sign command with a customer-managed signing key in Cloud KMS, producing a signed attestation that is uploaded to the Container Analysis service. The signing key should be a separate KMS key per attestor with IAM controls scoped to the specific pipeline identity. Vulnerability scan attestations come from either the built-in Artifact Analysis scanner or a third-party scanner that produces Cosign-format signatures. The integration plumbing exists for Snyk, Prisma, and several others, and the attestation format converged on the SLSA in-toto standard during 2024 and 2025. The current best practice is to use Cosign for the actual signing operation, with Cloud KMS as the key backend, and to publish to both Container Analysis and the open Rekor log for transparency.
What does the rollout sequence look like?
The safe rollout sequence is dry-run first, then per-cluster enforcement, then policy tightening. Dry-run mode logs policy violations without blocking admission, and is the right starting point because the first round of logs always surfaces images you did not know your team was deploying. Run dry-run for at least two weeks to catch the weekly cron jobs, the disaster-recovery test runs, and the developer-self-service deployments that escape normal visibility. Once the dry-run logs are clean, enable enforcement on a single non-critical cluster and watch for a week. Expand to staging clusters, then to production clusters in batches, with at least a 48-hour soak between batches. The total rollout typically takes 6 to 10 weeks for a mid-sized organization, longer if your initial dry-run surfaces more drift than expected. Compressing the timeline produces outages, and the outages are always at the worst possible time because they correlate with deployments.
What break-glass procedure should you have ready?
The break-glass procedure exists because every enforcement system needs an escape hatch and the absence of one creates pressure to never enforce in the first place. The GCP-native break-glass for Binary Authorization is to add a temporary policy exception scoped to a specific image tag or digest, applied with an IAM role that requires elevated permissions and produces an audit log entry. The exception should auto-expire after a defined window, typically 4 to 8 hours, which requires a separate automation since the platform does not enforce expiration natively. The audit trail for break-glass invocations should feed into your incident review process, because every break-glass is a signal that some part of the normal pipeline failed. Teams that invoke break-glass more than once a quarter have a real problem with their attestation pipeline reliability, not with the policy.
How does this integrate with multi-cluster and Anthos?
Multi-cluster Binary Authorization, generally available in mid-2025, lets you define policies at the Anthos fleet level and apply them consistently across clusters in any cloud or on-prem. The model is the same per-cluster admission decision, but the policy source of truth is centralized in the fleet config. The tradeoff is that policy changes propagate asynchronously and can take up to 90 seconds to take effect across the fleet, which matters during incident response. For teams running mixed GKE and on-prem Kubernetes, the Anthos approach is significantly better than maintaining parallel per-cluster policies. For teams that are GKE-only across multiple regions, the simpler approach is per-cluster policies managed through Terraform or Config Sync. Both work; the choice is about your control plane preference, not about security capability.
How Safeguard Helps
Safeguard produces the attestations Binary Authorization needs and integrates them into your existing pipeline without you writing the plumbing. Every image scan generates a Cosign-format vulnerability attestation signed with your Cloud KMS key, ready for the Container Analysis service. Policy gates correlate Binary Authorization policy with reachability data and Griffin AI risk scores, so the attestation step encodes real risk decisions rather than rubber-stamping. Zero-CVE base images come pre-signed with valid SLSA Level 3 provenance, which satisfies the most stringent default Binary Authorization policies out of the box. TPRM and zero-day signals can trigger policy updates automatically, so a newly-disclosed critical CVE in a deployed image triggers a deployment block within minutes rather than waiting for the next manual policy review.