Risolvere i problemi relativi alla crittografia dei secret a livello di applicazione

La crittografia dei secret a livello di applicazione aggiunge un livello di protezione configurabile per i dati sensibili in Google Kubernetes Engine (GKE), come credenziali e chiavi. I problemi con questa configurazione possono impedire il corretto funzionamento di questo livello di sicurezza aggiuntivo.

Utilizza questo documento per risolvere i problemi di crittografia dei secret a livello di applicazione ispezionando i campi di debug disponibili nell'oggetto Cluster dell'API GKE. Questi campi ti aiutano a diagnosticare la causa principale di errori comuni, come aggiornamenti non riusciti o problemi con la chiave Cloud KMS.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma e per gli ingegneri della sicurezza responsabili della protezione delle informazioni sensibili archiviate nei cluster GKE. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Aggiornamento non riuscito

Quando aggiorni la configurazione della crittografia dei secret a livello di applicazione, GKE deve riscrivere tutti gli oggetti Secret nel cluster Kubernetes. GKE esegue questa operazione per garantire che tutti i secret siano criptati dalla nuova chiave Cloud KMS o scritti senza crittografia, se è questa la configurazione che hai scelto.

Questa operazione di aggiornamento può non riuscire a causa di una delle seguenti condizioni:

  • Il piano di controllo Kubernetes non è temporaneamente disponibile durante l'aggiornamento.
  • Un AdmissionWebhook definito dall'utente impedisce a GKE di aggiornare gli oggetti Secret.
  • La chiave Cloud KMS aggiornata o precedente viene disattivata prima del completamento dell'operazione di aggiornamento.

Finché l'operazione di aggiornamento non va a buon fine, non interagire con le chiavi Cloud KMS aggiornate o precedenti.

Campi di debug

I cluster GKE nuovi che eseguono la versione 1.29 e successive contengono campi aggiuntivi che ti aiutano a monitorare gli aggiornamenti di Cluster.DatabaseEncryption e a ripristinare gli errori.

I passaggi seguenti si applicano solo ai cluster in cui il campo DatabaseEncryption.CurrentState non è vuoto. Se il campo CurrentState è vuoto, la funzionalità non è ancora abilitata su questa versione del cluster.

A questi campi si applicano i seguenti limiti:

  • Sono solo output, il che significa che non puoi impostarli durante le richieste di creazione o aggiornamento del cluster.

Campo CurrentState

Puoi controllare lo stato attuale di un'operazione di aggiornamento di DatabaseEncryption esaminando il campo CurrentState in Cluster.DatabaseEncryption.

Valore di CurrentState Descrizione

CURRENT_STATE_ENCRYPTED

CURRENT_STATE_ALL_OBJECTS_ENCRYPTION_ENABLED

CURRENT_STATE_DECRYPTED

 L'ultima operazione di aggiornamento è stata completata correttamente. Non sono necessari ulteriori interventi da parte tua. Puoi eliminare le chiavi utilizzate in precedenza.

CURRENT_STATE_ENCRYPTION_PENDING

CURRENT_STATE_ALL_OBJECTS_ENCRYPTION_PENDING

CURRENT_STATE_DECRYPTION_PENDING

 L'aggiornamento è in corso.

CURRENT_STATE_ENCRYPTION_ERROR

CURRENT_STATE_ALL_OBJECTS_ENCRYPTION_ERROR

CURRENT_STATE_DECRYPTION_ERROR

Si è verificato un errore con l'aggiornamento più recente. Non disabilitare o distruggere le chiavi Cloud KMS utilizzate in precedenza, poiché potrebbero essere ancora in uso da parte di GKE.

Per ulteriori informazioni, consulta il campo LastOperationErrors.

Campo LastOperationErrors

Quando un'operazione di aggiornamento non va a buon fine, l'errore sottostante del control plane GKE viene visualizzato nell'output di gcloud container clusters update.

I messaggi di errore delle due operazioni di aggiornamento non riuscite più recenti sono disponibili anche in Cluster.DatabaseEncryption.LastOperationErrors.

Campo DecryptionKeys

La chiave Cloud KMS utilizzata per le nuove operazioni di crittografia viene visualizzata in DatabaseEncryption.KeyName. In genere, questa è l'unica chiave utilizzata dal cluster.

Tuttavia, DatabaseEncryption.DecryptionKeys contiene chiavi aggiuntive che vengono utilizzate anche dal cluster se è in corso un aggiornamento o dopo un errore.

Esegui il ripristino dopo un aggiornamento non riuscito

Per eseguire il ripristino da un aggiornamento non riuscito:

  1. Esamina il messaggio di errore e risolvi i problemi indicati.
  2. Riprova la richiesta di aggiornamento eseguendo il comando non riuscito, ad esempio gcloud container clusters update ... --database-encryption-key. Ti consigliamo di riprovare con la stessa richiesta di aggiornamento che hai inviato originariamente o di aggiornare il cluster riportandolo allo stato precedente. GKE potrebbe non essere in grado di passare a una chiave o a uno stato di crittografia diverso se non riesce a leggere uno o più secret.

Le sezioni seguenti elencano i motivi comuni degli errori.

Errore della chiave Cloud KMS

Se il messaggio di errore contiene un riferimento a una o più chiavi Cloud KMS, esamina la configurazione delle chiavi Cloud KMS per assicurarti che le versioni delle chiavi pertinenti siano utilizzabili.

Se l'errore indica che una chiave Cloud KMS è stata disabilitata o eliminata, riattiva la chiave o la versione della chiave.

Errore: impossibile utilizzare la chiave Cloud KMS configurata per la crittografia a livello di applicazione

Se il service account predefinito di GKE non riesce ad accedere alla chiave Cloud KMS, viene visualizzato il seguente messaggio di errore:

Cluster problem detected (Kubernetes Engine Service Agent account unable to use CloudKMS key configured for Application Level encryption).

Per risolvere il problema, riattiva la chiave disattivata.

Impossibile aggiornare il secret

Il seguente errore potrebbe verificarsi se l'API Kubernetes ha rifiutato la richiesta di aggiornamento a causa di un webhook di ammissione:

error admission webhook WEBHOOK_NAME denied the request

Per risolvere questo errore, rimuovi il webhook o modificalo in modo che GKE possa aggiornare i secret in tutti gli spazi dei nomi durante gli aggiornamenti delle chiavi.

Errore: lo spazio dei nomi è gestito

Il seguente errore si verifica quando tenti di criptare nuovamente i Secret che si trovano in uno spazio dei nomi gestito da GKE, ad esempio kube-system, in un cluster Autopilot. Il messaggio di errore è simile al seguente:

Error from server (Forbidden): secrets "alertmanager" is
forbidden: User cannot patch resource "secrets" in API group "" in the namespace "gke-gmp-system":
GKE Warden authz [denied by managed-namespaces-limitation]: the namespace "gke-gmp-system"
is managed and the request's verb "patch" is denied'

I cluster GKE Autopilot non consentono di modificare le risorse Kubernetes, inclusi i secret, negli spazi dei nomi gestiti.

Per risolvere questo errore, segui questi passaggi:

  • Se utilizzi i comandi kubectl per crittografare nuovamente i secret, utilizza il flag --namespace per limitare l'ambito del comando agli spazi dei nomi che gestisci.
  • Se utilizzi un CronJob per criptare nuovamente i secret, eseguine il deployment solo negli spazi dei nomi che gestisci.

Piano di controllo che non risponde dopo la disattivazione della crittografia

Se disabiliti la crittografia dei secret a livello di applicazione troppo rapidamente dopo averla abilitata, il job di crittografia iniziale potrebbe essere interrotto e il control plane kube-apiserver del cluster potrebbe non rispondere.

Di seguito sono riportati i sintomi di questo problema:

  • Le operazioni del cluster come list node, list pods e get apiserver readiness non riescono con il codice di errore 13 e il messaggio Internal Server Error.
  • I controller Kube non funzionano e i pod eliminati da StatefulSet o ReplicaSet non vengono ricreati.
  • Le chiamate webhook non vanno a buon fine perché la connessione viene rifiutata.

Per mitigare questo problema, segui questi passaggi:

  • Riattiva la crittografia dei secret a livello di applicazione utilizzando la stessa chiave Cloud KMS che hai utilizzato in precedenza per abilitare la crittografia.

Per evitare questo problema, assicurati che:

  • Dopo aver attivato la crittografia dei secret a livello di applicazione, verifica che il cluster sia stabile per alcune ore prima di disattivare la crittografia.

Passaggi successivi