Esegui il deployment dei container (GKE, Distributed Cloud)

Questa pagina spiega come eseguire il deployment di un'immagine container in un cluster GKE (suGoogle 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 Autorizzazione binaria.

Prima di iniziare

Assicurati di aver abilitato l'API Binary Authorization nel tuo progetto e di avere un cluster GKE con Autorizzazione binaria abilitata. Consulta la sezione relativa alla configurazione su Google Kubernetes Engine o alla configurazione su Distributed Cloud.

Installa kubectl per interagire con GKE.

Configura kubectl

Devi aggiornare il file kubeconfig locale per l'installazione di kubectl. In questo modo vengono fornite le credenziali e le informazioni sull'endpoint necessarie per accedere al cluster in GKE o Distributed Cloud.

Per configurare kubectl, esegui questo 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
  • CLUSTER_NAME: il nome del cluster

Distributed Cloud 

gcloud container fleet memberships get-credentials \
    --location LOCATION \
    MEMBERSHIP_NAME

Sostituisci quanto segue:

  • LOCATION: la località dell'appartenenza al parco risorse del cluster GKE, ad esempio global
  • MEMBERSHIP_NAME: il nome dell'appartenenza al parco risorse del cluster GKE

Esegui il deployment dell'immagine container

Esegui il deployment dell'immagine container nel seguente modo:

  1. Configura le variabili di ambiente:

    POD_NAME=POD_NAME
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=IMAGE_DIGEST

    Sostituisci quanto segue:

    • POD_NAME: il nome che vuoi utilizzare per il workload GKE
    • IMAGE_PATH: il percorso dell'immagine in Artifact Registry o in un altro registry.

    • IMAGE_DIGEST: il digest del manifest dell'immagine. Ecco un esempio:

      • Artifact Registry:
        • Percorso: us-docker.pkg.dev/google-samples/containers/gke/hello-app
        • Digest: sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567

      Per scoprire come ottenere il digest di un'immagine in Artifact Registry, consulta Gestione delle immagini.

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

    Vedrai il tuo pod nell'elenco.

Limitazioni

Al momento del deployment, Autorizzazione binaria analizza solo le immagini nei campi containers e ephemeralContainers di PodSpec. Non vengono analizzati altri campi. I container init e i volumi di immagini non vengono scansionati al momento del deployment.

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 esegue un fail-open: 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 ad aprirsi 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. Sono inclusi gli scenari in cui i pod vengono creati o aggiornati automaticamente da controller dei workload Kubernetes di livello superiore, come ReplicaSet e StatefulSet. Se GKE avesse applicato il criterio fail-closed anziché fail-open, qualsiasi interruzione di Autorizzazione binaria avrebbe impedito l'esecuzione di questi pod. Inoltre, quando i pod vengono rifiutati, il failover può portare a errori a cascata, poiché il traffico reindirizzato sovraccarica i pod ancora in esecuzione. Qualsiasi interruzione di Autorizzazione binaria potrebbe attivare un'interruzione completa del cluster, anche senza il deployment di nuove immagini.

Esegui il deployment di immagini che violano la policy

Autorizzazione binaria supporta una funzionalità nota come deployment di emergenza che consente di eseguire il deployment di un'immagine anche se viola la policy.

Per saperne di più, consulta Utilizzo della modalità di emergenza

Esegui la pulizia

Per eseguire la pulizia, elimina il pod eseguendo questo comando:

  kubectl delete pod ${POD_NAME}

Passaggi successivi