Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, explicamos como implantar uma imagem de contêiner em um cluster do GKE (no
Google Cloud ou Google Distributed Cloud) com a autorização binária ativada.
Os comandos kubectl usados para implantar a imagem são os mesmos que você usa para implantar imagens em clusters que não usam a autorização binária.
Você precisa atualizar o arquivo local kubeconfig para sua instalação do kubectl.
Isso fornece as credenciais e as informações de endpoint necessárias para acessar o
cluster nos clusters do GKE ou no Distributed Cloud.
Para configurar kubectl, execute este comando da gcloud:
GKE
gcloud container clusters get-credentials \
--zone ZONE \
CLUSTER_NAME
Substitua:
ZONE: o nome da zona do GKE em que o
cluster está em execução, por exemplo, us-central1-a;
Para saber como conseguir o resumo de uma imagem no Artifact Registry, consulte
Como gerenciar imagens.
Implante a imagem usando o comando kubectl run.
É preciso implantar a imagem usando o resumo em vez de uma tag, como 1.0 ou
latest, já que a autorização binária usa o resumo para procurar
attestations.
Para implantar a imagem, execute o seguinte comando kubectl:
kubectl run ${POD_NAME} \
--image ${IMAGE_PATH}@${IMAGE_DIGEST}
Agora verifique se a implantação foi bloqueada pela autorização binária:
kubectl get pods
Você verá o pod listado.
Fail open
Se o GKE não conseguir acessar o servidor de autorização binária por qualquer motivo ou se o servidor retornar um erro, o GKE não poderá determinar se a autorização binária permitiria ou negaria a imagem. Nesse caso, o GKE falha ao abrir: o padrão é permitir que a imagem seja implantada, mas cria uma entrada de registro nos
Registros de auditoria do Cloud para registrar por que a imagem foi permitida.
A aplicação do GKE falha em abrir devido a uma compensação entre
confiabilidade e segurança. O GKE envia uma solicitação para a autorização binária sempre que um pod é criado ou atualizado. Isso inclui cenários em que os pods são criados ou atualizados automaticamente por controladores de carga de trabalho do Kubernetes de nível superior, como ReplicaSets e StatefulSets. Se
o GKE falhar ao fechar em vez de abrir, qualquer
interrupção da autorização binária interromperia a execução desses pods. Além disso, quando os pods são negados, o failover pode levar a falhas em cascata, porque o tráfego redirecionado sobrecarrega os pods que ainda estão em execução. Qualquer interrupção da autorização binária pode acionar uma interrupção completa no cluster, mesmo sem implantar novas imagens.
Implantar imagens que violam a política
A autorização binária é compatível com um recurso conhecido como implantação forçada que permite que uma imagem
seja implantada mesmo que ela viole a política.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
