Breakglass abused: deploying an unsigned image past Binary Authorization

Binary Authorization is the bouncer that only lets signed, attested images run. But every bouncer has a breakglass override, and that override is exactly what an attacker with deploy rights reaches for.

How the attack works

An attacker with deploy rights creates a workload with the Binary Authorization breakglass annotation set, instructing admission control to bypass the signature and attestation requirement. An unsigned, poisoned image that no required attestor ever vetted runs in production with the workload’s service account, then uses that identity to call GCP APIs and pivot beyond the cluster. Binary Authorization logs the admission as a breakglass violation it allowed, tied to the deploy that set the annotation. In ATT&CK terms this is T1525, Implant Internal Image, paired with T1610, Deploy Container.

Why it works

The breakglass annotation and any policy exemptions were too easy to use. A deploying principal could set breakglass and the controller would happily admit an unattested image, so the admission gate was bypassed by design rather than broken.

How to fix it

Deleting the pod is futile, because the deployment controller redeploys the same unsigned image through the same path. Remove or scale down the workload and its controller, revoke the deploying principal’s ability to set breakglass, restore the enforced policy, and rotate the workload’s service account so the identity the malicious image already used is dead. For the root cause, gate breakglass behind break-glass-with-approval, tighten policy exemptions and allowlists, require attestations from all needed attestors, and alert on every breakglass admission across clusters and Cloud Run. Treat the workload identity as fully compromised and scope what it reached across data services from the audit logs.

Practice it

We built this as a GraphLattice Range scenario so developers and platform teams can rehearse closing the breakglass path, restoring the enforced policy, and rotating the workload identity, instead of deleting a pod the controller simply recreates.