Google Binary Authorization API
Browse all Google APIs✓ Official Vendor SpecSecurityComplianceoauth212 EndpointsREST
For Agents
Manage Binary Authorization policies and attestors that gate container image deployments on GKE and Cloud Run. Agents can read policies, register attestors, and evaluate images.
Use for: I need to require image signatures before any deploy to GKE, List all Binary Authorization attestors in a project, Create a new attestor with a PKIX public key, Validate an attestation against an attestor
Not supported: Does not run image scans, sign images, or provision clusters — use for managing deploy-time admission policies and attestors only.
Binary Authorization is Google Cloud's deploy-time policy engine for container images on GKE, Anthos Service Mesh, Anthos Clusters, and Cloud Run. The API manages policies that require images to be signed by trusted attestors before they can be deployed, plus the attestor resources themselves and their PKIX or PGP keys. It also exposes evaluate to test a policy against an image and validateAttestationOccurrence to verify a signature. Together these endpoints let platform teams enforce supply-chain controls without wedging custom admission webhooks into every cluster.
Install Jentic One Beta
Connect the Binary Authorization API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Binary Authorization API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Binary Authorization API.
Create and update policies that govern image deployment per cluster or globally
Register attestors with their PKIX or PGP public keys
Validate that an attestation occurrence was signed by a trusted attestor
Evaluate whether a given image would be admitted under the current policy
List policies and attestors across a project for compliance review
Manage IAM policies on attestors to control who can sign or verify
Delete attestors and reset policies to project defaults
Use Cases
Patterns agents use Binary Authorization API for, with concrete tasks.
★ Sign-and-Verify Pipeline
Require every container image to be signed by a build pipeline attestor before it can run in production. Policies are managed at /v1/{parent}/policies and attestors at /v1/{parent}/attestors. CI signs using kritis-signer or cosign and writes an attestation occurrence; the policy admits only images that pass validateAttestationOccurrence.
Update the project policy at projects/myproj/policy to require attestation by attestor projects/myproj/attestors/build-signer for all clusters.
Per-Cluster Exceptions
Use clusterAdmissionRules in the policy to relax requirements on dev clusters while keeping prod strict. The same policy resource at /v1/{parent}/policy supports per-cluster overrides keyed by location/cluster pairs. This avoids splitting projects just to relax one rule.
PATCH the project policy to add a clusterAdmissionRule for us-central1.dev-cluster set to ALWAYS_ALLOW.
Compliance Evidence
Use POST /v1/{name}:evaluate to confirm a candidate image passes the policy before promoting and POST /v1/{attestor}:validateAttestationOccurrence to confirm a signature was applied by the right attestor. Together these support release evidence for SOC 2 and FedRAMP audits without inventing custom checks.
Validate attestation occurrence projects/myproj/occurrences/abc against attestor projects/myproj/attestors/build-signer and report whether it is valid.
Agent-Driven Policy Setup
An AI agent receives a request like 'turn on signature enforcement for prod-cluster' and updates the policy through Jentic. The agent loads the policy resource, modifies the clusterAdmissionRule, patches the policy, and confirms by reading it back. OAuth tokens stay in Jentic's vault.
From the request 'enforce attestation on prod-cluster only', update the policy with a clusterAdmissionRule for us-central1.prod-cluster requiring attestor build-signer.
Key Endpoints
12 endpoints — binary authorization is google cloud's deploy-time policy engine for container images on gke, anthos service mesh, anthos clusters, and cloud run.
METHOD
PATH
DESCRIPTION
GET
/v1/{+name}
Get a policy or attestor by resource name
PUT
/v1/{+name}
Update a policy or attestor
POST
/v1/{+parent}/attestors
Create an attestor
GET
/v1/{+parent}/attestors
List attestors in a project
DELETE
/v1/{+name}
Delete an attestor
POST
/v1/{+attestor}:validateAttestationOccurrence
Validate that an attestation was signed by an attestor
POST
/v1/{+name}:evaluate
Evaluate an image against a policy
GET
/v1/{+name}
Get a policy or attestor by resource name
PUT
/v1/{+name}
Update a policy or attestor
POST
/v1/{+parent}/attestors
Create an attestor
GET
/v1/{+parent}/attestors
List attestors in a project
DELETE
/v1/{+name}
Delete an attestor
POST
/v1/{+attestor}:validateAttestationOccurrence
Validate that an attestation was signed by an attestor
POST
/v1/{+name}:evaluate
Evaluate an image against a policy
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
Google OAuth 2.0 client credentials and refresh tokens are stored encrypted in the Jentic vault (MAXsystem). Agents receive short-lived scoped access tokens at execution time and never hold the refresh token.
Intent-based discovery
Agents search Jentic with intents like 'enforce image signing on GKE' or 'create a Binary Authorization attestor' and Jentic returns the matching policy or attestor operation with its schema.
Time to first call
Direct integration: 1-2 days for OAuth, the policy/attestor model, and integrating with a signer. Through Jentic: under an hour — search, load schema, execute.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Binary Authorization API through Jentic.
What authentication does the Binary Authorization API use?
The API uses Google OAuth 2.0 with the cloud-platform scope. Through Jentic the OAuth refresh token sits in the encrypted vault and the agent only receives short-lived scoped access tokens at execution time.
Can I require image signatures on GKE with this API?
Yes. Update the project policy via PUT /v1/{name} (where name is projects/PROJECT/policy) and set defaultAdmissionRule.evaluationMode to REQUIRE_ATTESTATION with a list of trusted attestors. GKE admission rejects images that lack a valid attestation.
What are the rate limits for the Binary Authorization API?
Quotas are project-level: typically a small write QPS on the policy and individual attestors and bursty read QPS for list and get. Evaluate and validateAttestationOccurrence are intended for deploy-time use, not bulk workloads. Specific values appear in the Google Cloud quotas console.
How do I validate an attestation through Jentic?
Search Jentic for 'validate a Binary Authorization attestation', load the schema for POST /v1/{attestor}:validateAttestationOccurrence, and execute with the attestation, occurrenceNote, and occurrenceResourceUri. Jentic forwards the OAuth token; the response indicates whether the signature is valid.
Does this API stop deployments on its own?
Enforcement happens at the deploy plane (GKE, Cloud Run, Anthos), not in this API. This API stores the policy and attestor records. Make sure Binary Authorization is enabled on your clusters or services for the policy to actually gate deployments.
Can I have different rules per cluster?
Yes. The policy resource includes clusterAdmissionRules keyed by location.cluster_name; each entry can set its own evaluationMode and required attestors. Use this to run strict rules in prod and looser rules in dev.
GET STARTED