Esegui il deployment dei container (GKE, Distributed Cloud)
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina spiega come eseguire il deployment di un'immagine container in un cluster GKE (su
Google Cloud o Google Distributed Cloud) in cui è abilitata l'autorizzazione binaria.
I comandi kubectl che utilizzi per eseguire il deployment dell'immagine sono gli stessi che utilizzi per eseguire il deployment delle immagini nei cluster che non utilizzano l'autorizzazione binaria.
Devi aggiornare il file kubeconfig locale per l'installazione di kubectl.
Fornisce le credenziali e le informazioni sull'endpoint necessarie per accedere al cluster in GKE o Distributed Cloud.
Per configurare kubectl, esegui il seguente comando gcloud:
GKE
gcloud container clusters get-credentials \
--zone ZONE \
CLUSTER_NAME
Sostituisci quanto segue:
ZONE: il nome della zona GKE in cui è in esecuzione il cluster, ad esempio us-central1-a
Per scoprire come ottenere il digest di un'immagine in Artifact Registry, consulta la sezione
Gestione delle immagini.
Esegui il deployment dell'immagine utilizzando il comando kubectl run.
Devi eseguire il deployment dell'immagine utilizzando il digest anziché un tag come 1.0 o
latest, poiché Autorizzazione binaria utilizza il digest per cercare le
attestazioni.
Per eseguire il deployment dell'immagine, esegui questo comando kubectl:
kubectl run ${POD_NAME} \
--image ${IMAGE_PATH}@${IMAGE_DIGEST}
Ora verifica che il deployment sia stato bloccato da Autorizzazione binaria:
kubectl get pods
Vedi il tuo Pod elencato.
Fail open
Se GKE non riesce a raggiungere il server di Autorizzazione binaria per qualsiasi motivo o se il server restituisce un errore, GKE non può determinare se Autorizzazione binaria consentirebbe o negherebbe l'immagine. In questo caso, GKE non riesce ad aprirsi: per impostazione predefinita, consente il deployment dell'immagine, ma crea una voce di log in
Cloud Audit Logs per registrare il motivo per cui l'immagine è stata consentita.
L'applicazione di GKE non riesce a causa di un compromesso tra
affidabilità e sicurezza. GKE invia una richiesta ad Autorizzazione binaria ogni volta che un pod viene creato o aggiornato. Ciò include
scenari in cui i pod vengono creati o aggiornati automaticamente da controller di workload Kubernetes di livello superiore, come ReplicaSet e StatefulSet. Se
GKE non è riuscito a chiudersi anziché aprirsi, qualsiasi
interruzione dell'autorizzazione binaria impedirebbe l'esecuzione di questi pod. Inoltre,
quando i pod vengono rifiutati, il failover può causare errori a cascata poiché il traffico reindirizzato sovraccarica i pod ancora in esecuzione. Qualsiasi interruzione dell'autorizzazione binaria potrebbe causare un'interruzione completa del cluster, anche senza eseguire il deployment di nuove immagini.
Deployment di immagini che violano le norme
Autorizzazione binaria supporta una funzionalità nota come breakglass che consente il deployment di un'immagine anche se viola le norme.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
