Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se explica cómo implementar una imagen de contenedor en un clúster de GKE (enGoogle Cloud o Google Distributed Cloud) en el que está habilitada la Autorización Binaria.
Los comandos de kubectl que usas para implementar la imagen son los mismos que usas para implementar imágenes en clústeres que no usan Autorización Binaria.
Debes actualizar el archivo local kubeconfig de tu instalación de kubectl.
Esto proporciona las credenciales y la información del extremo necesarias para acceder al clúster en GKE o Distributed Cloud.
Para configurar kubectl, ejecuta el siguiente comando de gcloud:
GKE
gcloud container clusters get-credentials \
--zone ZONE \
CLUSTER_NAME
Reemplaza lo siguiente:
ZONE: el nombre de la zona de GKE en la que se ejecuta el clúster, por ejemplo, us-central1-a
Si deseas aprender a obtener el resumen de una imagen en Artifact Registry, consulta Administra imágenes.
Implementa la imagen con el comando kubectl run.
Debes implementar la imagen con el resumen en lugar de una etiqueta como 1.0 o latest, ya que la autorización binaria usa el resumen para buscar las certificaciones.
Para implementar la imagen, ejecuta el siguiente comando de kubectl:
kubectl run ${POD_NAME} \
--image ${IMAGE_PATH}@${IMAGE_DIGEST}
Ahora, verifica que la autorización binaria haya bloqueado la implementación:
kubectl get pods
Verás el Pod en la lista.
Fail open
Si GKE no puede alcanzar al servidor de Autorización Binaria por algún motivo o si el servidor devuelve un error, GKE no puede determinar si la autorización binaria permitiría o rechazaría la imagen. En este caso, GKE falla abierta: permite la implementación predeterminada de la imagen, pero crea una entrada de registro en los registros de auditoría de Cloud para dejar asentado por qué se permitió la imagen.
La aplicación de GKE falla cuando se abre debido a una compensación entre la confiabilidad y la seguridad. GKE envía una solicitud a la autorización binaria cada vez que se crea o se actualiza un Pod. Esto incluye situaciones en las que los controladores de cargas de trabajo de Kubernetes de nivel superior crean o actualizan los pods automáticamente, como ReplicaSets y StatefulSets. Si GKE falló en lugar de abrirse, cualquier interrupción de la autorización binaria evitaría la ejecución de estos Pods. Además, cuando se rechazan los Pods, la conmutación por error puede generar fallas en cascada, ya que el tráfico redireccionado sobrecarga a los Pods que aún se están ejecutando. Cualquier interrupción de la autorización binaria podría activar una interrupción completa para el clúster, incluso sin implementar imágenes nuevas.
Implementa imágenes que infrinjan la política
Autorización Binaria admite una función conocida como anulación de emergencia que permite que se implemente una imagen, incluso si infringe la política.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eThis guide explains how to deploy container images to a GKE cluster with Binary Authorization enabled, using the same \u003ccode\u003ekubectl\u003c/code\u003e commands as clusters without this feature.\u003c/p\u003e\n"],["\u003cp\u003eBefore deploying, you must have the Binary Authorization API enabled and a GKE cluster with Binary Authorization enabled, as well as have updated the local \u003ccode\u003ekubeconfig\u003c/code\u003e to interact with the cluster.\u003c/p\u003e\n"],["\u003cp\u003eDeploying the image requires specifying the image path and digest, not a tag, to enable Binary Authorization's attestation verification process.\u003c/p\u003e\n"],["\u003cp\u003eIn 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.\u003c/p\u003e\n"],["\u003cp\u003eBinary Authorization has a breakglass feature that allows deployment of images that are in violation of the set policy.\u003c/p\u003e\n"]]],[],null,["# Deploy containers (GKE, Distributed Cloud)\n\nThis page explains how to deploy a container image to a GKE cluster (on\nGoogle Cloud or Google Distributed Cloud) where Binary Authorization is enabled.\nThe `kubectl` commands you use to deploy the image are the same as the ones you\nuse to deploy images to clusters that don't use Binary Authorization.\n\nBefore you begin\n----------------\n\nMake sure you have the Binary Authorization API enabled in your project and a\nGKE cluster with Binary Authorization enabled. See\n[setting up on Google Kubernetes Engine](/binary-authorization/docs/setting-up) or\n[setting up on Distributed Cloud](/binary-authorization/docs/setting-up-on-prem).\n\nInstall [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl) for interacting with GKE.\n\nConfigure `kubectl`\n-------------------\n\nYou must update the local `kubeconfig` file for your `kubectl` installation.\nThis provides the credentials and endpoint information required to access the\ncluster in GKE or Distributed Cloud.\n\nTo configure `kubectl`, run the following `gcloud` command: \n\n### GKE\n\n```\ngcloud container clusters get-credentials \\\n --zone ZONE \\\n CLUSTER_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eZONE\u003c/var\u003e: the name of the GKE zone where the cluster is running, for example, `us-central1-a`\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster\n\n### Distributed Cloud\n\n```\ngcloud container fleet memberships get-credentials \\\n --location LOCATION \\\n MEMBERSHIP_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the location of the fleet membership of the GKE cluster, for example, `global`\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of the fleet membership of the GKE cluster\n\nDeploy the container image\n--------------------------\n\nDeploy your container image as follows:\n\n1. Configure environment variables:\n\n POD_NAME=\u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e\n IMAGE_PATH=\u003cvar translate=\"no\"\u003eIMAGE_PATH\u003c/var\u003e\n IMAGE_DIGEST=\u003cvar translate=\"no\"\u003eIMAGE_DIGEST\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e: the name you want to use for the GKE workload\n - \u003cvar translate=\"no\"\u003eIMAGE_PATH\u003c/var\u003e: path of the image in [Artifact Registry](/artifact-registry/docs), or another registry.\n - \u003cvar translate=\"no\"\u003eIMAGE_DIGEST\u003c/var\u003e: the digest of the image manifest.\n Example is as follows:\n\n - Artifact Registry:\n - Path: `us-docker.pkg.dev/google-samples/containers/gke/hello-app`\n - Digest: `sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567`\n\n To learn how to get the digest of an image in Artifact Registry, see\n [Managing images](/artifact-registry/docs/docker/manage-images#gcloud).\n2. Deploy your image using the `kubectl run` command.\n\n You must deploy the image using the digest rather than a tag like `1.0` or\n `latest`, as Binary Authorization uses the digest to look up\n [attestations](/binary-authorization/docs/key-concepts#attestations).\n\n To deploy the image, run the following `kubectl` command: \n\n ```\n kubectl run ${POD_NAME} \\\n --image ${IMAGE_PATH}@${IMAGE_DIGEST}\n ```\n\n Now, verify that the deployment was blocked by Binary Authorization: \n\n ```\n kubectl get pods\n ```\n\n You see your Pod listed.\n\nFail open\n---------\n\n\u003cbr /\u003e\n\nIf GKE is unable to reach the Binary Authorization\nserver for any reason, or if the server returns an error,\nGKE cannot determine whether Binary Authorization\nwould 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\nCloud Audit Logs to record why the image was allowed.\n\nGKE enforcement fails open because of a tradeoff between\nreliability and security. GKE sends a request to the\nBinary Authorization whenever a Pod is created or updated. This includes\nscenarios where Pods are automatically created or updated by higher level\nKubernetes workload controllers, like ReplicaSets and StatefulSets. If\nGKE failed closed instead of open, any\nBinary Authorization outage would stop these Pods from running. Moreover,\nwhen Pods are denied, failover can lead to cascading failures as redirected\ntraffic overloads Pods that are still running. Any Binary Authorization\noutage could trigger a complete outage for your cluster, even without\ndeploying any new images.\n| **Note:** Operations that send enough requests to Binary Authorization to exceed the per-project, per-user, per-minute [quota](/binary-authorization/quotas) 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\n| quota](/binary-authorization/quotas#quota_increases), if needed.\n\nDeploy images that violate the policy\n-------------------------------------\n\nBinary Authorization supports a feature known as *breakglass* that allows an image\nto be deployed, even if it violates the policy.\n\nFor more information, see [Using breakglass](/binary-authorization/docs/using-breakglass)\n\nClean up\n--------\n\nTo clean up, delete the Pod by executing the following command:\n\n\u003cbr /\u003e\n\n```\n kubectl delete pod ${POD_NAME}\n \n```\n\n\u003cbr /\u003e\n\nWhat's next\n-----------\n\n- Learn about [dry-run mode](/binary-authorization/docs/enabling-dry-run).\n- Learn how to [use CV](/binary-authorization/docs/overview-cv).\n- Learn how to [use legacy continuous validation](/binary-authorization/docs/using-cv) ([deprecated](/binary-authorization/docs/deprecations/cv-project-singleton-policy)).\n- Learn how to [use image digests in Kubernetes manifests](/architecture/using-container-image-digests-in-kubernetes-manifests)."]]
