Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere i problemi relativi al deployment dei workload Autopilot con privilegi

Autopilot

I workload privilegiati nei cluster Google Kubernetes Engine (GKE) Autopilot devono essere configurati correttamente per evitare problemi. Errori di configurazione 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 su come risolvere gli errori di sincronizzazione della lista consentita 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 privilegi elevati sui 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

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 dei 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:

Visualizza un elenco delle liste consentite installate nel cluster:
```
kubectl get workloadallowlist
```
Trova il nome della lista consentita da applicare al workload con privilegi.
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.
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.

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 consente specifica k8s.gcr.io/pause2.
Il container 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 fornito da un provider di terze parti, apri un problema con il provider per risolvere le violazioni. Fornisci l'output del passaggio precedente del problema.

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 tuo cluster modifica i pod creati dal controller del carico di lavoro dopo che sono stati consentiti dalla lista consentita. Queste modifiche possono causare la mancata corrispondenza della specifica del pod con la 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.

Sintomo

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.

Diagnosi

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

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.

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.
Esamina l'output del passaggio precedente. Se nella sezione "Mancate corrispondenze del carico di lavoro" visualizzi campi imprevisti, ad esempio variabili di ambiente aggiuntive (ad esempio DD_AGENT_HOST), container o volumi, è un forte segnale che un altro webhook sta modificando i tuoi pod.

Risoluzione

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 suo spazio dei nomi per segnalare all'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 carico di lavoro.

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 i workload con privilegi e le liste consentite

I partner sono responsabili 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 workload privilegiato o una lista consentita, contatta il partner corrispondente.

Passaggi successivi

Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedere assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:
- Aprire una richiesta di assistenza contattando l'assistenza clienti cloud.
- Ricevere assistenza dalla community ponendo domande su Stack Overflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per ulteriore assistenza della community.
- Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico.

Risolvere i problemi relativi al deployment dei workload Autopilot con privilegi Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.