canonical: https://jentic.com/apis/googleapis.com/binaryauthorization # Google Binary Authorization API 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. ## For AI 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. ## Scope Does not run image scans, sign images, or provision clusters - use for managing deploy-time admission policies and attestors only. ## Capabilities - 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 ### 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. Example prompt: 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. Example prompt: 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. Example prompt: 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. Example prompt: 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 | 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 | ## Key resources - **Policy** — The single per-project policy resource with default and per-cluster admission rules. - **Attestors** — Register and manage signers used to verify images. - **Attestation Validation** — Validate signatures and evaluate images against the policy. ## Why Jentic - **Setup:** Wiring the Binary Authorization API by hand means learning its Google OAuth 2.0 flow, exchanging refresh tokens for scoped access tokens, and managing deploy-time admission policies and attestors yourself. Through Jentic you install once, import the Binary Authorization API from the API Directory, store the OAuth credentials once, and your agent calls it. - **Permission scoping:** The API puts the project policy and attestor in the URL path (/v1/{+name}, /v1/{+parent}/attestors), so a rule can pin your agent to one project's policy and attestors: it can read the policy and create attestors there and nowhere else. You choose the operations it may call, so deleting an attestor or overwriting the policy is not included unless you add it. - **Credential handling:** Your Google OAuth client credentials and refresh token are stored once, encrypted, by your own Jentic One instance and injected at execution time. The agent receives only short-lived scoped access tokens and never sees the refresh token in its prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'enforce image signing on GKE' or 'create a Binary Authorization attestor', and Jentic returns the matching policy or attestor operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Container Analysis API** — Stores the attestation and vulnerability occurrences that Binary Authorization validates. - **Kubernetes Engine API** — Provisions GKE clusters that Binary Authorization gates deployments on. - **Cloud KMS API** — Manages signing keys that attestors can reference. ## FAQ ### 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. ### Can I limit what my agent is allowed to do with the Binary Authorization API? Yes. Because your Jentic One instance is self-hosted, your own rules decide which operations and credentials the agent may use, and this API puts the project policy and attestor in the URL path (/v1/{+name}, /v1/{+parent}/attestors), so you can pin the agent to a single project's policy and attestors and nothing else. You choose the operations it may call, so you can allow it to read the policy and create attestors while excluding deleting an attestor or overwriting the policy unless you add those. The agent only ever receives short-lived scoped access tokens at execution time, never your OAuth refresh token.