Stay organized with collections Save and categorize content based on your preferences.
This page explains how to deploy a container image to a GKE cluster (on Google Cloud or Google Distributed Cloud) where Binary Authorization is enabled. The kubectl
commands you use to deploy the image are the same as the ones you use to deploy images to clusters that don't use Binary Authorization.
Make sure you have the Binary Authorization API enabled in your project and a GKE cluster with Binary Authorization enabled. See setting up on Google Kubernetes Engine or setting up on Distributed Cloud.
Install kubectl
for interacting with GKE.
kubectl
You must update the local kubeconfig
file for your kubectl
installation. This provides the credentials and endpoint information required to access the cluster in GKE or Distributed Cloud.
To configure kubectl
, run the following gcloud
command:
gcloud container clusters get-credentials \ --zone ZONE \ CLUSTER_NAME
Replace the following:
us-central1-a
gcloud container fleet memberships get-credentials \ --location LOCATION \ MEMBERSHIP_NAME
Replace the following:
global
Deploy your container image as follows:
Configure environment variables:
POD_NAME=POD_NAME
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=IMAGE_DIGEST
Replace the following:
IMAGE_DIGEST: the digest of the image manifest. Example is as follows:
us-docker.pkg.dev/google-samples/containers/gke/hello-app
sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
To learn how to get the digest of an image in Artifact Registry, see Managing images.
Deploy your image using the kubectl run
command.
You must deploy the image using the digest rather than a tag like 1.0
or latest
, as Binary Authorization uses the digest to look up attestations.
To deploy the image, run the following kubectl
command:
kubectl run ${POD_NAME} \ --image ${IMAGE_PATH}@${IMAGE_DIGEST}
Now, verify that the deployment was blocked by Binary Authorization:
kubectl get pods
You see your Pod listed.
If GKE is unable to reach the Binary Authorization server for any reason, or if the server returns an error, GKE cannot determine whether Binary Authorization would allow or deny the image. In this case, GKE fails open: it defaults to allowing the image to be deployed, but creates a log entry in Cloud Audit Logs to record why the image was allowed.
GKE enforcement fails open because of a tradeoff between reliability and security. GKE sends a request to the Binary Authorization whenever a Pod is created or updated. This includes scenarios where Pods are automatically created or updated by higher level Kubernetes workload controllers, like ReplicaSets and StatefulSets. If GKE failed closed instead of open, any Binary Authorization outage would stop these Pods from running. Moreover, when Pods are denied, failover can lead to cascading failures as redirected traffic overloads Pods that are still running. Any Binary Authorization outage could trigger a complete outage for your cluster, even without deploying any new images.
Note: Operations that send enough requests to Binary Authorization to exceed the per-project, per-user, per-minute quota will trigger fail open. For example, testing whether Binary Authorization denies an image by trying to rapidly deploy that image repeatedly will cause the image to be allowed when the quota is exceeded. It is possible to request additional quota, if needed. Deploy images that violate the policyBinary Authorization supports a feature known as breakglass that allows an image to be deployed, even if it violates the policy.
For more information, see Using breakglass
Clean upTo clean up, delete the Pod by executing the following command:
kubectl delete pod ${POD_NAME}What's next
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["This guide explains how to deploy container images to a GKE cluster with Binary Authorization enabled, using the same `kubectl` commands as clusters without this feature."],["Before deploying, you must have the Binary Authorization API enabled and a GKE cluster with Binary Authorization enabled, as well as have updated the local `kubeconfig` to interact with the cluster."],["Deploying the image requires specifying the image path and digest, not a tag, to enable Binary Authorization's attestation verification process."],["In the event that the GKE cannot reach the Binary Authorization server or encounters an error, it defaults to allowing the image deployment but logs the occurrence in Cloud Audit Logs, this is known as fail open."],["Binary Authorization has a breakglass feature that allows deployment of images that are in violation of the set policy."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4