Cloud Run’s Binary Authorization feature is surprisingly more about trust than about code signing.
Let’s see it in action. Imagine you have a deployment pipeline. The critical step isn’t just running gcloud run deploy, it’s ensuring that the container image pushed to Artifact Registry has been vetted by a specific policy before Cloud Run will even consider running it.
Here’s a simplified gcloud command that attempts a deployment:
gcloud run deploy my-app \
--image gcr.io/my-project/my-image:v1.0 \
--region us-central1 \
--platform managed \
--project my-project
If Binary Authorization is enforced and the image gcr.io/my-project/my-image:v1.0 hasn’t passed the policy, this command will fail. The error message will look something like:
ERROR: (gcloud.run.deploy) PERMISSION_DENIED: The image [...] is not authorized for deployment.
This isn’t because your service account lacks permissions to deploy. It’s because the image itself is deemed untrustworthy by the Binary Authorization policy.
The core problem Binary Authorization solves is the "supply chain attack" vector where an attacker compromises your build system or a public container registry and injects malicious code into an image that your CI/CD pipeline then deploys. Without Binary Authorization, Cloud Run would happily deploy that compromised image.
How it works internally is through "attestations." When your container image is built and pushed to Artifact Registry, your CI/CD system (or a manual process) generates an attestation. This attestation is a signed statement confirming that the image meets certain criteria – for example, "this image was built by our trusted CI system," or "this image passed static analysis and vulnerability scanning." This attestation is then stored alongside the image in Artifact Registry.
Binary Authorization then enforces a policy that specifies which attestations are required before an image can be deployed. This policy is configured at the project or folder level. You define "attestation authorities" – essentially, the entities (like your CI/CD system’s service account) that are allowed to generate valid attestations – and then specify which attestations from which authorities must be present for a given deployment.
The exact levers you control are:
- Attestation Authorities: Defining the identity (service account, user, etc.) that can sign attestations.
- Attestation Occurrences: The actual signed statements linking an image to a policy requirement.
- Binary Authorization Policies: The rules that dictate which attestations are required for deployment to specific resources (e.g., Cloud Run services, GKE clusters). You can specify required attestations based on the image’s registry path and even the deployment environment.
- Enforcement Mode: Whether the policy strictly blocks deployments (
ENFORCED) or just logs violations (REPORT_ONLY).
The most surprising aspect is how flexible this is. You don’t have to use a traditional code signing certificate. You can use Google Cloud service accounts to sign attestations, and the Binary Authorization system verifies these signatures using standard PKI. This means your CI/CD system can become a trusted authority for deploying your own software, without needing to manage complex certificate hierarchies for every build agent.
The next concept to grapple with is how to integrate this smoothly into your existing CI/CD tooling, ensuring attestations are generated reliably for every build and deployment.