Google Binary Authorization API

Name: Binary Authorization API
Brand: Binary Authorization API
Availability: InStock

✓ 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.

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.

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 | sh

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 instance

Jentic 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

Validate that an attestation occurrence was signed by a trusted attestor

GET STARTED

Start building with Binary Authorization API

Explore with Jentic

View OpenAPI Document

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.

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

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.

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.

Google Binary Authorization API

Connect the Binary Authorization API to your agent

Capabilities

Start building with Binary Authorization API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs