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

I workload con privilegi nei cluster Google Kubernetes Engine (GKE) Autopilot devono essere configurati correttamente per evitare problemi. Le 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 di workload con privilegi su Autopilot. Trova indicazioni su come risolvere gli errori di sincronizzazione delle liste consentite e diagnosticare il motivo per cui un workload con privilegi 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 autorizzazioni elevate sui cluster Autopilot. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività utente GKE comuni. Cloud de Confiance by S3NS

Problemi di sincronizzazione delle liste consentite

Quando esegui il deployment di un AllowlistSynchronizer, GKE tenta di installare e sincronizzare i file delle liste consentite che specifichi. Se questa sincronizzazione non riesce, il campo status di AllowlistSynchronizer segnala l'errore.

Recupera 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ù AllowlistSynchronizer

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 contenente più allowlistPaths.

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

Ordinamento dei container dei workload

Nei cluster GKE con versioni precedenti alla 1.34.0-gke.0000000, se una o più immagini container dei workload corrispondono a un'immagine container specificata in un WorkloadAllowlist in-cluster, i container dei 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 workload in modo che vengano ordinati nell'ordine corretto.

Problemi di deployment dei workload con privilegi

Dopo aver installato correttamente una lista consentita, esegui il deployment del workload 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 con privilegi è stato rifiutato, richiedi informazioni dettagliate a GKE sulle violazioni delle liste consentite:

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

    kubectl get workloadallowlist

    Trova il nome della lista consentita che deve essere applicata al workload con privilegi.

  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 la procedura di deployment del workload utilizza altri strumenti, contatta il fornitore del workload per aprire un problema. Salta i passaggi rimanenti.

  3. Aggiungi la seguente etichetta alla sezione spec.metadata.labels della specifica del pod del workload 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 workload 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 workload specifica hostNetwork: true, ma la lista consentita non specifica hostNetwork: true.
    • Il workload 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 specifica queste variabili di ambiente.
    • Il container specifica l'immagine k8s.gcr.io/diff/image, ma la lista consentita specifica k8s.gcr.io/pause2.
    • Il container aggiunge le funzionalità SYS_ADMIN e SYS_PTRACE, ma la lista consentita non consente di aggiungere queste funzionalità.
    • Il container specifica un mount del volume denominato data, ma la lista consentita non specifica un mount del volume denominato data.

Se stai eseguendo il deployment di un workload di proprietà di un fornitore di terze parti, apri un problema con questo fornitore per risolvere le violazioni. Fornisci l'output del passaggio precedente nel 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. Verifica se la lista consentita specifica una versione GKE minima:

    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 GKE minima.

  2. Verifica 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 Cloud de Confiance 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

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

  1. Apri la pagina di riferimento della definizione di risorsa personalizzata (CRD) WorkloadAllowlist.
  2. Per ogni campo nella specifica WorkloadAllowlist, verifica se la CRD richiede una corrispondenza esatta delle stringhe.

  3. Per ogni campo che richiede una corrispondenza esatta delle stringhe, verifica se il valore nella specifica WorkloadAllowlist corrisponde al valore corrispondente nella specifica del workload.

    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 c'è corrispondenza, aggiorna la specifica WorkloadAllowlist in modo che corrisponda alla specifica del workload.

Mancata corrispondenza delle espressioni regolari

I 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 delle espressioni regolari sia corretta. La 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 è preceduto dal carattere di escape \. Cerca i caratteri \ aggiuntivi o mancanti.
    • I percorsi delle immagini nella lista consentita non includono tag o digest. Ad esempio, utilizza k8s.gcr.io/pause anziché 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 utilizzi il carattere di escape per i caratteri speciali. I requisiti per i caratteri di escape 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.

Utilizza il carattere di escape per ogni carattere speciale nei campi commands e args della specifica WorkloadAllowlist, anche se non utilizzi un'espressione regolare. Per utilizzare il carattere di escape per i 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, il che comporta il rifiuto da parte del webhook di ammissione 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 workload (ad esempio un DaemonSet o un Deployment) viene creato correttamente, ma non riesce a creare alcun pod. Quando esamini gli eventi del controller, vedrai messaggi che indicano che i pod sono stati rifiutati dal webhook di ammissione.

  1. Segui i passaggi nella sezione Problemi di deployment dei workload con privilegi per aggiungere l'etichetta cloud.google.com/matching-allowlist al workload.
  2. Copia spec.template dal manifest YAML del workload.
  3. Crea un nuovo manifest del 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 "Workload Mismatches" (Mancata corrispondenza dei workload) vedi campi imprevisti, come variabili di ambiente aggiuntive (ad esempio DD_AGENT_HOST), container o volumi, è un forte indicatore che un altro webhook sta modificando i pod.

Per risolvere il problema, devi configurare il webhook in conflitto in modo da escluderlo dalla modifica dei pod del workload nella lista consentita. In genere, questa operazione viene eseguita aggiungendo un'etichetta o un'annotazione al carico di lavoro o al relativo spazio dei nomi per segnalare al webhook che deve essere escluso dalla mutazione. Ad esempio, con Datadog, devi aggiungere l'etichetta admission.datadoghq.com/enabled: "false" allo spazio dei nomi del workload.

Consulta la documentazione del software di terze parti specifico che stai utilizzando per scoprire come escludere i workload dal relativo controller di ammissione.

Impedendo all'altro webhook di modificare i pod, puoi contribuire a garantire che continuino a corrispondere alla lista consentita e che venga eseguito il deployment correttamente nel cluster Autopilot.

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

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

Passaggi successivi