Risolvere i problemi relativi ai workload Autopilot con privilegi e alle liste consentite

I workload privilegiati nei cluster Google Kubernetes Engine (GKE) Autopilot devono essere configurati correttamente per evitare problemi. Configurazioni errate possono causare errori di sincronizzazione con le liste consentite o il rifiuto del workload. Questi problemi possono impedire l'esecuzione di agenti o servizi essenziali con le autorizzazioni necessarie.

Utilizza questo documento per risolvere i problemi relativi al deployment dei workload con privilegi su Autopilot. Trova indicazioni per risolvere gli errori di sincronizzazione della lista consentita e diagnosticare il motivo per cui un workload privilegiato potrebbe essere rifiutato.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma e per i team di sicurezza che eseguono il deployment di workload con privilegi elevati nei cluster Autopilot. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Google Cloud

Problemi di sincronizzazione della lista consentita

Quando esegui il deployment di un AllowlistSynchronizer, GKE tenta di installare e sincronizzare i file della lista consentita che specifichi. Se questa sincronizzazione non va a buon fine, il campo status di AllowlistSynchronizer segnala l'errore.

Ottieni lo stato dell'oggetto AllowlistSynchronizer:

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

Sostituisci ALLOWLIST_SYNCHRONIZER_NAME con il nome di AllowlistSynchronizer.

L'output è simile al seguente:

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

Il campo conditions.message e il campo managedAllowlistStatus.lastError forniscono informazioni dettagliate sull'errore. Utilizza queste informazioni per risolvere il problema.

Più sincronizzatori di liste consentite

Nei cluster GKE con versioni precedenti alla 1.33.4-gke.1035000, l'installazione di WorkloadAllowlists potrebbe non riuscire se è presente più di un AllowlistSynchronizer.

Per risolvere il problema, utilizza un solo AllowlistSynchronizer che contenga più allowlistPaths.

In alternativa, puoi eseguire l'upgrade del cluster a una versione più recente.

Ordinamento dei container di workload

Nei cluster GKE con versioni precedenti alla 1.34.0-gke.0000000, se una o più immagini container del workload corrispondono a un'immagine container specificata in una WorkloadAllowlist nel cluster, i container del workload potrebbero essere creati e ordinati in ordine alfabetico inverso.

Per risolvere il problema, prova le seguenti opzioni:

  • Esegui l'upgrade del cluster alla versione 1.34.0-gke.0000000 o successive.
  • Rinomina i container del carico di lavoro in modo che vengano ordinati nell'ordine corretto.

Problemi di deployment dei workload privilegiati

Dopo aver installato correttamente una lista consentita, esegui il deployment del carico di lavoro con privilegi corrispondente nel cluster. In alcuni casi, GKE potrebbe rifiutare il workload.

Prova le seguenti opzioni di risoluzione:

  • Assicurati che la versione GKE del cluster soddisfi il requisito di versione del workload.
  • Assicurati che il workload di cui stai eseguendo il deployment sia quello a cui si applica il file della lista consentita.

Per scoprire perché un workload privilegiato è stato rifiutato, richiedi informazioni dettagliate a GKE sulle violazioni della lista consentita:

  1. Visualizza un elenco delle liste consentite installate nel cluster:

    kubectl get workloadallowlist

    Trova il nome della lista consentita da applicare al workload privilegiato.

  2. Apri il manifest YAML del workload con privilegi in un editor di testo. Se non riesci ad accedere ai manifest YAML, ad esempio se il processo di deployment del workload utilizza altri strumenti, contatta il fornitore del workload per aprire un problema. Ignora i passaggi rimanenti.

  3. Aggiungi la seguente etichetta alla sezione spec.metadata.labels della specifica del pod del carico di lavoro con privilegi:

    labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME

    Sostituisci ALLOWLIST_NAME con il nome della lista consentita che hai ottenuto nel passaggio precedente. Utilizza il nome dell'output del comando kubectl get workloadallowlist, non il percorso del file della lista consentita.

  4. Salva il manifest e applica il carico di lavoro al cluster:

    kubectl apply -f WORKLOAD_MANIFEST_FILE

    Sostituisci WORKLOAD_MANIFEST_FILE con il percorso del file manifest.

    L'output fornisce informazioni dettagliate sui campi del workload che non corrispondono alla lista consentita specificata, come nel seguente esempio:

    Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.

    In questo esempio, si verificano le seguenti violazioni:

    • Il carico di lavoro specifica hostNetwork: true, ma la lista consentita non specifica hostNetwork: true.
    • Il carico di lavoro specifica hostPID: true, ma la lista consentita non specifica hostPID: true.
    • Il workload specifica un volume denominato data, ma la lista consentita non specifica un volume denominato data.
    • Il container specifica le variabili di ambiente denominate ENV_VAR1 e ENV_VAR2, ma la lista consentita non le specifica.
    • Il container specifica l'immagine k8s.gcr.io/diff/image, ma la lista consentita specifica k8s.gcr.io/pause2.
    • Il contenitore aggiunge le funzionalità SYS_ADMIN e SYS_PTRACE, ma la lista consentita non consente di aggiungerle.
    • Il container specifica un montaggio del volume denominato data, ma la lista consentita non specifica un montaggio del volume denominato data.

Se stai eseguendo il deployment di un carico di lavoro di proprietà di un fornitore di terze parti, apri una richiesta con il fornitore per risolvere le violazioni. Fornisci l'output del passaggio precedente del problema.

Versione GKE incompatibile

GKE potrebbe rifiutare un workload se la lista consentita specifica una versione GKE minima successiva alla versione GKE del cluster.

  1. Controlla se la lista consentita specifica una versione minima di GKE:

    kubectl describe workloadallowlist ALLOWLIST_NAME | grep "minGKEVersion"

    Sostituisci ALLOWLIST_NAME con il nome della lista consentita.

    Se l'output è vuoto, la lista consentita non specifica una versione GKE minima. Salta questa sezione. Se l'output è un valore, la lista consentita specifica una versione minima di GKE.

  2. Controlla la versione GKE del cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CLUSTER_LOCATION \
    --format="value(currentMasterVersion)"

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • CLUSTER_LOCATION: la Google Cloud posizione del cluster.

    L'output è simile al seguente:

    1.32.3-gke.1006000

  3. Se la versione GKE del cluster è precedente alla versione GKE minima della lista consentita, esegui l'upgrade del cluster alla versione GKE minima della lista consentita o a una versione successiva. Per ulteriori informazioni, consulta Eseguire l'upgrade del cluster.

Al termine dell'upgrade, prova a eseguire il deployment del workload nel cluster.

Mancata corrispondenza delle stringhe

Campi specifici nella specifica WorkloadAllowlist devono corrispondere esattamente alle stringhe dei campi corrispondenti nella specifica del workload.

  1. Apri la pagina di riferimento di WorkloadAllowlist CustomResourceDefinition (CRD).
  2. Per ogni campo nella specifica WorkloadAllowlist, controlla se il CRD richiede una corrispondenza esatta della stringa.

  3. Per ogni campo che richiede una corrispondenza esatta della stringa, controlla se il valore nella specifica WorkloadAllowlist corrisponde al valore corrispondente nella specifica del carico di lavoro.

    Ad esempio, ogni comando eseguito da un container deve corrispondere esattamente a un comando nella lista consentita. Qualsiasi deviazione dal comando esatto comporta un rifiuto.

Se non corrispondono, aggiorna la specifica WorkloadAllowlist in modo che corrisponda alla specifica del workload.

Mancate corrispondenze delle espressioni regolari

Campi specifici nella specifica WorkloadAllowlist supportano la corrispondenza delle espressioni regolari.

  1. Nella specifica WorkloadAllowlist, trova i campi che specificano le espressioni regolari.

  2. Assicurati che la sintassi dell'espressione regolare sia corretta. Il CRD WorkloadAllowlist supporta la sintassi delle espressioni regolari Google RE2. Verifica che le espressioni abbiano le seguenti proprietà:

    • L'espressione regolare inizia con il carattere ^ e termina con il carattere $. Ad esempio ^example-auth\.google\.com\/go_[a-z0-9]+\/google\/path$.
    • Ogni carattere speciale viene preceduto dal carattere di escape \. Cerca caratteri \ aggiuntivi o mancanti.
    • I percorsi delle immagini nella lista consentita non includono tag o digest. Ad esempio, utilizza k8s.gcr.io/pause invece di k8s.gcr.io/pause:3.1 o k8s.gcr.io/pause@sha256:1234567890.

Dopo aver risolto eventuali problemi relativi alle espressioni regolari, prova a eseguire il deployment del workload nel cluster.

Caratteri di escape in comandi e argomenti

GKE non può trovare corrispondenze tra comandi e argomenti se non inserisci caratteri di escape per i caratteri speciali. I requisiti per l'escape dei caratteri dipendono dalla modalità di applicazione della lista consentita. Ad esempio, l'applicazione di una lista consentita come file YAML o JSON ha requisiti di escape diversi rispetto alla creazione di una specifica della lista consentita utilizzando uno strumento a riga di comando. Questa sezione descrive i requisiti di escape per i file YAML.

Esegui l'escape di ogni carattere speciale nei campi commands e args della specifica WorkloadAllowlist, anche se non utilizzi un'espressione regolare. Per eseguire l'escape dei caratteri speciali, utilizza il carattere \, come nei seguenti esempi:

  • Comando: kubectl describe \$\{POD_NAME\}
  • Argomento: hostname \$NODE_NAME; dcgm-exporter --remote-hostengine-info \$\(NODE_IP\) --collectors /etc/dcgm-exporter/counters.csv

Interferenza dei webhook con i workload in una lista consentita

In alcuni casi, anche se un workload è configurato correttamente in modo che corrisponda a una lista consentita, potrebbe comunque essere rifiutato da GKE. Questa situazione può verificarsi se un altro controller di ammissione (webhook) nel cluster modifica i pod creati dal controller del workload dopo che sono stati consentiti dalla lista consentita. Queste modifiche possono fare in modo che la specifica del pod non corrisponda più alla lista consentita, con conseguente rifiuto da parte del webhook di ammissione di GKE Warden.

Questo problema è comune con gli agenti di monitoraggio e sicurezza di terze parti che inseriscono container sidecar o variabili di ambiente nei pod.

Il sintomo più comune è che il controller del carico di lavoro (ad esempio un DaemonSet o un deployment) viene creato correttamente, ma non riesce a creare alcun pod. Quando ispezioni gli eventi del controller, vedrai messaggi che indicano che i pod sono stati rifiutati dal webhook di ammissione.

  1. Segui i passaggi descritti nella sezione Problemi di deployment dei workload privilegiati per aggiungere l'etichetta cloud.google.com/matching-allowlist al tuo workload.
  2. Copia spec.template dal file manifest YAML del workload.
  3. Crea un nuovo manifest Pod e incolla la specifica copiata nel campo spec.

  4. Imposta i campi apiVersion, kind e metadata.name nel manifest del pod:

    apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here

    Sostituisci quanto segue:

    • POD_NAME: il nome del pod di test.
    • ALLOWLIST_NAME: il nome della lista consentita.

  5. Applica il manifest del pod:

    kubectl apply -f YOUR_POD_MANIFEST_FILE

    Sostituisci YOUR_POD_MANIFEST_FILE con il percorso del file manifest del pod.

  6. Esamina l'output del passaggio precedente. Se nella sezione "Mancata corrispondenza dei carichi di lavoro" visualizzi campi imprevisti, ad esempio variabili di ambiente aggiuntive (ad es. DD_AGENT_HOST), container o volumi, è un chiaro segnale che un altro webhook sta modificando i tuoi pod.

Per risolvere il problema, devi configurare il webhook in conflitto in modo da escluderlo dalla modifica dei pod del workload consentito. In genere questo viene fatto aggiungendo un'etichetta o un'annotazione al workload o al relativo spazio dei nomi per segnalare al webhook che deve essere escluso dalla mutazione. Ad esempio, con Datadog, aggiungeresti l'etichetta admission.datadoghq.com/enabled: "false" allo spazio dei nomi del tuo workload.

Consulta la documentazione del software di terze parti specifico che utilizzi per scoprire come escludere i carichi di lavoro dal relativo controller di ammissione.

Se impedisci all'altro webhook di modificare i pod, puoi contribuire a garantire che continuino a corrispondere alla lista consentita e vengano implementati correttamente nel tuo cluster Autopilot.

Bug e richieste di funzionalità per workload con privilegi e liste consentite

Se esegui un carico di lavoro privilegiato fornito da un partner GKE o da un provider di terze parti, quest'ultimo è responsabile della creazione, dello sviluppo e della manutenzione dei propri carichi di lavoro privilegiati e delle liste consentite. Se riscontri un bug o hai una richiesta di funzionalità per un partner o una lista consentita o un carico di lavoro privilegiato di terze parti, contatta il fornitore.

Passaggi successivi