Crittografia dei secret a livello di applicazione

Scopri come criptare i secret di Kubernetes a livello di applicazione utilizzando una chiave che gestisci in Cloud Key Management Service (Cloud KMS). Poiché questa funzionalità si basa sulle funzionalità di Cloud KMS, devi acquisire familiarità con la rotazione delle chiavi e la crittografia dell'involucro.

Per seguire le indicazioni dettagliate per questa attività direttamente nella console Google Cloud, fai clic su Procedura guidata:

Procedura guidata

Panoramica

Per impostazione predefinita, Google Kubernetes Engine (GKE) cripta i contenuti dei clienti archiviati a riposo, inclusi i secret. GKE gestisce questa crittografia predefinita per conto tuo senza che tu debba fare altro.

La crittografia dei secret a livello di applicazione offre un ulteriore livello di sicurezza per i dati sensibili, come i secret, archiviati in etcd. Utilizza una chiave gestita con Cloud KMS per criptare i dati in stato di riposo a livello di applicazione. Questa crittografia protegge dagli utenti malintenzionati che accedono a una copia offline di etcd.

Per utilizzare la crittografia dei secret a livello di applicazione, devi prima creare una chiave Cloud KMS e concedere all'account di servizio GKE l'accesso alla chiave. Puoi utilizzare una chiave con uno dei livelli di protezione supportati da Cloud KMS.

Assicurati che la chiave si trovi nella stessa posizione del cluster per ridurre la latenza e per evitare i casi in cui le risorse dipendono da servizi distribuiti su più domini di errore. Dopo aver creato una chiave, puoi attivare la funzionalità su un cluster nuovo o esistente specificando la chiave che vuoi utilizzare. Quando attivi la funzionalità, GKE cripta tutti i secret nuovi ed esistenti utilizzando la tua chiave di crittografia.

Crittografia envelope

Kubernetes offre la crittografia con envelope dei secret con un provider KMS, il che significa che per criptare i secret viene utilizzata una chiave locale, comunemente chiamata chiave di crittografia dei dati (DEK). La DEK stessa è criptata con un'altra chiave chiamata chiave di crittografia della chiave (KEK). Kubernetes non memorizza la KEK.

La crittografia envelope presenta i seguenti vantaggi:

  • Miglioramento delle prestazioni rispetto alla crittografia con chiave pubblica: GKE utilizza l'API Cloud KMS solo per criptare nuove DEK con la KEK o per decriptare una DEK quando la cache locale è vuota.
  • Migliore gestione delle chiavi su larga scala: una singola KEK può criptare più DEK. Il numero di chiavi da archiviare nel servizio Cloud KMS è molto inferiore al numero di chiavi che criptano i dati.
  • Possibilità di utilizzare una radice di attendibilità centrale: i secret archiviati in Kubernetes possono fare affidamento su una radice di attendibilità esterna. Ciò significa che puoi utilizzare un'radice di attendibilità centrale, ad esempio un modulo di sicurezza hardware, per tutti i tuoi secret. Un avversario che accede ai tuoi contenitori offline non può ottenere i tuoi segreti.

Con la crittografia dei secret a livello di applicazione in GKE, GKE cripta i secret utilizzando DEK locali e il provider AES-CBC. GKE cripta le DEK con una KEK che gestisci in Cloud KMS.

Per scoprire di più sulla crittografia dell'involucro, consulta Crittografia dell'involucro.

Cosa succede quando crei un secret

Quando crei un nuovo secret, ecco cosa succede:

  1. Il server API Kubernetes genera un DEK univoco per il secret utilizzando un generatore di numeri casuali.

  2. Il server API Kubernetes utilizza la DEK localmente per criptare il secret.

  3. Il plug-in KMS invia la DEK a Cloud KMS per la crittografia. Il plug-in KMS utilizza l'account di servizio GKE del tuo progetto per autenticarsi in Cloud KMS.

  4. Cloud KMS cripta la DEK utilizzando la KEK e la invia nuovamente al plug-in KMS.

  5. Il server API Kubernetes salva il secret e la DEK criptati. Il DEK in testo non viene salvato su un disco, ma solo nella memoria del server API.

  6. Il server dell'API Kubernetes crea una voce della cache che mappa la DEK criptata alla DEK in testo non cifrato in memoria. In questo modo, il server API decripta il secret senza utilizzare Cloud KMS.

Quando un client richiede un segreto al server dell'API Kubernetes, accade quanto segue:

  1. Il server API Kubernetes recupera il secret e la DEK criptati.

  2. Il server API Kubernetes controlla la cache per verificare la presenza di una voce di mappatura esistente e decripta il secret senza utilizzare Cloud KMS.

  3. Se non viene trovata una voce della cache, il plug-in KMS invia la DEK a Cloud KMS per la decrittografia utilizzando la KEK. La DEK decriptata viene poi utilizzata per decriptare il secret.

  4. Il server API Kubernetes restituisce il secret decriptato al client.

Che cosa succede quando distruggi una chiave

Quando distruggi una KEK in Cloud KMS utilizzata per criptare un secret in GKE, il secret non è più disponibile, a meno che non aggiorni il cluster per utilizzare prima una nuova KEK.

Se prevedi di distruggere una vecchia versione del KEK dopo una rotazione delle chiavi, utilizza prima la nuova versione del KEK per ricripptare il secret. Facoltativamente, puoi conservare la versione precedente della KEK per evitare di ricricare i secret, ma continuerai a ricevere la fatturazione per tutte le KEK attive in Cloud KMS. Per i dettagli sui prezzi, consulta Prezzi di Cloud KMS.

A meno che non utilizzi una proiezione del volume dei token dell'account di servizio, gli account di servizio utilizzati dai tuoi carichi di lavoro su GKE utilizzano anche i secret e, se una chiave viene distrutta, questi non sono più disponibili. L'impossibilità di accedere a queste risorse comporta il fallimento dei carichi di lavoro.

Si applicano le seguenti eccezioni:

  • I pod con accesso esistente ai secret come volumi montati o variabili di ambiente mantengono l'accesso.

  • Il server API Kubernetes può comunque utilizzare le voci di mappatura DEK memorizzate nella cache per decriptare un secret dopo aver distrutto la KEK. In questo modo, i pod riavviati o riprogrammati possono accedere al secret, a meno che non si verifichi una delle seguenti situazioni:

    • Il control plane del cluster viene riavviato.
    • Il pod del server API Kubernetes viene riavviato.
    • La voce di mappatura DEK per il secret non è nella cache del server dell'API Kubernetes.

Prima di distruggere un KEK, controlla se è in uso nel tuo cluster. Puoi anche creare un criterio di avviso per l'eliminazione delle chiavi in Cloud KMS. Distruggi le versioni precedenti del KEK solo se hai la certezza che nessun dato nel cluster sia criptato utilizzando la versione precedente. Prima di distruggere una KEK, controlla se la chiave è in uso. Per maggiori dettagli, consulta Distruggere e ripristinare le versioni delle chiavi.

Prima di iniziare

  • Per svolgere gli esercizi in questo argomento, hai bisogno di due progetti Google Cloud:

    • Progetto chiavi:è qui che crei una KEK.

    • Progetto cluster:qui crei un cluster che abilita la crittografia dei secret a livello di applicazione.

    Puoi utilizzare lo stesso progetto per il progetto principale e il progetto del cluster. Tuttavia, la pratica consigliata è utilizzare progetti distinti.

  • Nel progetto della chiave, assicurati di aver attivato l'API Cloud KMS.

    Abilita l'API Cloud KMS

  • Nel progetto di chiavi, l'utente che crea il keyring e la chiave deve disporre delle seguenti autorizzazioni IAM:

    • cloudkms.keyRings.getIamPolicy
    • cloudkms.keyRings.setIamPolicy

    Queste autorizzazioni (e molte altre) vengono concesse al ruolo Identity and Access Management predefinito.roles/cloudkms.admin Puoi scoprire di più sulla concessione delle autorizzazioni per la gestione delle chiavi nella documentazione di Cloud KMS.

  • Nel progetto del cluster, assicurati di aver attivato l'API Google Kubernetes Engine.

    Attiva l'API Google Kubernetes Engine

  • Assicurati di aver installato Google Cloud CLI.

  • Aggiorna gcloud alla versione più recente:

    gcloud components update

Crea una chiave Cloud KMS

Per creare una chiave Cloud KMS, devi prima creare un keyring. Le chiavi e i keyring sono risorse a livello di regione. Quando crei un portachiavi, specifica una posizione corrispondente a quella del tuo cluster GKE:

  • Un cluster zonale deve utilizzare un keyring di una regione superset. Ad esempio, un cluster nella zona us-central1-a può utilizzare una chiave solo nella regione us-central1.

  • Un cluster regionale deve usare un keyring dalla stessa posizione. Ad esempio, un cluster nella regioneasia-northeast1 deve essere protetto con un keyring della regioneasia-northeast1.

La regione Cloud KMS global non è supportata per l'utilizzo con GKE.

Puoi utilizzare la gcloud CLI o la console Google Cloud.

Console

Nel progetto di chiavi, crea un keyring:

  1. Vai alla pagina Gestione delle chiavi nella console Google Cloud.

    Vai a Gestione delle chiavi

  2. Fai clic su Crea keyring.

  3. Nel campo Nome del keyring, inserisci il nome del keyring.

  4. Dall'elenco Location (Posizione), seleziona la posizione del cluster Kubernetes.

  5. Fai clic su Crea.

Poi, crea una chiave:

  1. Vai alla pagina Gestione delle chiavi nella console Google Cloud.

    Vai a Gestione delle chiavi

  2. Fai clic sul nome del keyring per cui vuoi creare una chiave.

  3. Fai clic su Crea chiave.

  4. Nel campo Nome chiave, inserisci il nome della chiave.

  5. Accetta i valori predefiniti per Periodo di rotazione e A partire dal giorno oppure imposta un periodo di rotazione della chiave e un'ora di inizio della chiave se vuoi utilizzare valori diversi.

  6. [Facoltativo] Nel campo Etichette, fai clic su Aggiungi etichetta se vuoi aggiungere etichette alla chiave.

  7. Fai clic su Crea.

gcloud

Nel progetto di chiavi, crea un keyring:

gcloud kms keyrings create RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci quanto segue:

  • RING_NAME: il nome del nuovo portachiavi.
  • LOCATION: la posizione in cui vuoi creare il portachiavi.
  • KEY_PROJECT_ID: l'ID del tuo progetto principale.

Crea una chiave:

gcloud kms keys create KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --purpose=encryption \
    --project=KEY_PROJECT_ID

Sostituisci quanto segue:

  • KEY_NAME: il nome della nuova chiave.
  • LOCATION: la posizione Cloud KMS in cui hai creato la raccolta di chiavi.
  • RING_NAME: il nome del tuo mazzo di chiavi.
  • KEY_PROJECT_ID: l'ID progetto principale.

Concedi l'autorizzazione per utilizzare la chiave

L'account di servizio GKE nel progetto del cluster ha il seguente nome:

service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

Sostituisci CLUSTER_PROJECT_NUMBER con il numero del progetto del tuo cluster. Per trovare il numero del progetto utilizzando gcloud CLI, esegui il seguente comando:

gcloud projects describe CLUSTER_PROJECT_ID \
    --format="value(projectNumber)"

Per concedere l'accesso all'account di servizio, puoi utilizzare la console Google Cloud o gcloud CLI.

Console

Concedi al tuo account di servizio GKE il ruolo Autore crittografia/decrittografia CryptoKey Cloud KMS:

  1. Apri il browser Chiavi di Cloud Key Management Service nella console Google Cloud.
    Apri il browser delle chiavi Cloud KMS

  2. Fai clic sul nome del keyring contenente la chiave che ti interessa.

  3. Seleziona la casella di controllo per la chiave che ti interessa.

    La scheda Autorizzazioni nel riquadro della finestra a destra diventa disponibile.

  4. Nella finestra di dialogo Aggiungi membri, specifica l'indirizzo email dell'account di servizio GKE a cui stai concedendo l'accesso.

  5. Nel menu a discesa Seleziona un ruolo, seleziona Autore crittografia/decrittografia CryptoKey Cloud KMS.

  6. Fai clic su Salva.

gcloud

Concedi al tuo account di servizio GKE il ruolo Autore crittografia/decrittografia CryptoKey Cloud KMS:

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project=KEY_PROJECT_ID

Sostituisci quanto segue:

  • KEY_NAME: il nome della chiave.
  • LOCATION: la posizione Cloud KMS in cui hai creato la raccolta di chiavi.
  • RING_NAME: il nome del tuo mazzo di chiavi.
  • SERVICE_ACCOUNT_NAME: il nome del tuo account di servizio GKE.
  • KEY_PROJECT_ID: l'ID progetto principale.

Assicurati che la chiave abbia una quota sufficiente se si tratta di una chiave Cloud HSM

Se utilizzi una chiave Cloud HSM, il progetto Google Cloud che la contiene è limitato dalla quota chiavi. Assicurati di avere una quota sufficiente per utilizzare le chiavi Cloud HSM con la crittografia dei secret a livello di applicazione. Se la quota è esaurita, i nodi potrebbero perdere la connettività al piano di controllo del cluster.

Abilita la crittografia dei secret a livello di applicazione

Puoi abilitare la crittografia dei secret a livello di applicazione su cluster GKE Standard e GKE Autopilot nuovi o esistenti utilizzando la gcloud CLI o la console Google Cloud.

Best practice:

Dopo aver attivato la crittografia dei secret a livello di applicazione, esegui una rotazione delle chiavi. Puoi configurare la rotazione automatica delle chiavi in Cloud KMS.

Su un nuovo cluster

Puoi creare un nuovo cluster con la crittografia dei secret a livello di applicazione abilitata utilizzando la console Google Cloud o la gcloud CLI.

Console - Autopilot

Per creare un cluster Autopilot con la crittografia dei secret a livello di applicazione abilitata, svolgi i seguenti passaggi:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Nella sezione Autopilot, fai clic su Configura.

  4. Configura il cluster come preferisci.

  5. Nel riquadro di navigazione, fai clic su Opzioni avanzate ed espandi la sezione Sicurezza.

  6. Seleziona la casella di controllo Abilita la crittografia dei secret a livello di applicazione e scegli la chiave che hai creato in Creare una chiave Cloud KMS.

  7. Fai clic su Crea.

Console - Standard

Per creare un cluster standard con la crittografia dei secret a livello di applicazione abilitata, svolgi i seguenti passaggi:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Nella sezione Standard, fai clic su Configura.

  4. Configura il cluster come preferisci.

  5. Nel riquadro di navigazione, in Cluster, fai clic su Sicurezza.

  6. Seleziona la casella di controllo Abilita la crittografia dei secret a livello di applicazione e scegli la chiave che hai creato in Creare una chiave Cloud KMS.

  7. Fai clic su Crea.

gcloud

Per creare un cluster che supporti la crittografia dei secret a livello di applicazione, specifica un valore per il parametro --database-encryption-key nel comando di creazione.

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome scelto per il nuovo cluster.
  • COMPUTE_REGION: la regione Compute Engine dove vuoi creare il cluster.
  • KEY_PROJECT_ID: l'ID progetto principale.
  • LOCATION: la posizione Cloud KMS in cui hai creato la raccolta di chiavi.
  • RING_NAME: il nome del tuo mazzo di chiavi.
  • KEY_NAME: il nome della chiave.
  • CLUSTER_PROJECT_ID: l'ID progetto del tuo cluster.

Puoi abilitare la crittografia dei secret a livello di applicazione su un nuovo cluster standard utilizzando il comando gcloud container clusters create con gli stessi flag.

Su un cluster esistente

Puoi utilizzare gcloud CLI o la console Google Cloud per aggiornare un cluster esistente in modo che utilizzi la crittografia dei secret a livello di applicazione. GKE cripta tutti i secret esistenti e nuovi utilizzando la chiave di crittografia specificata.

L'aggiornamento di un cluster esistente per l'utilizzo della crittografia dei secret a livello di applicazione riavvia il piano di controllo del cluster. Per i cluster zonali, il piano di controllo diventa disponibile.

Console

Per aggiornare un cluster in modo che supporti la crittografia dei secret a livello di applicazione:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Sicurezza, nel campo Crittografia dei secret a livello di applicazione, fai clic su Modifica crittografia dei secret a livello di applicazione.

  4. Seleziona la casella di controllo Abilita la crittografia dei secret a livello di applicazione e scegli la chiave che hai creato in Creare una chiave Cloud KMS.

  5. Fai clic su Salva modifiche.

gcloud

Per abilitare la crittografia dei secret a livello di applicazione su un cluster esistente, esegui il seguente comando:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • COMPUTE_REGION: la regione Compute Engine del cluster.
  • KEY_PROJECT_ID: l'ID del tuo progetto principale.
  • LOCATION: la posizione Cloud KMS in cui hai creato la raccolta di chiavi.
  • RING_NAME: il nome del tuo mazzo di chiavi.
  • KEY_NAME: il nome della chiave.
  • CLUSTER_PROJECT_ID: l'ID progetto del tuo cluster.

Aggiornare una chiave Cloud KMS

Puoi utilizzare la gcloud CLI o la console Google Cloud per aggiornare un cluster esistente in modo che utilizzi una nuova chiave Cloud KMS.

L'aggiornamento di un cluster esistente per utilizzare una nuova chiave Cloud KMS fa riavviare il control plane del cluster. Per i cluster zonali, il piano di controllo diventa non disponibile.

Console

Per aggiornare un cluster in modo che utilizzi una nuova chiave Cloud KMS:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Sicurezza, nel campo Crittografia dei secret a livello di applicazione, fai clic su Modifica crittografia dei secret a livello di applicazione.

  4. Seleziona la nuova chiave di crittografia che vuoi utilizzare.

  5. Fai clic su Salva modifiche.

gcloud

Aggiorna il cluster esistente in modo da utilizzare una nuova chiave Cloud KMS:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • COMPUTE_REGION: la regione Compute Engine del cluster.
  • KEY_PROJECT_ID: l'ID progetto principale.
  • LOCATION: la posizione Cloud KMS in cui hai creato la raccolta di chiavi.
  • RING_NAME: il nome del tuo mazzo di chiavi.
  • KEY_NAME: il nome della chiave.
  • CLUSTER_PROJECT_ID: l'ID progetto del tuo cluster.

Disabilita la crittografia dei secret a livello di applicazione

Per disattivare la crittografia dei secret a livello di applicazione, puoi utilizzare gcloud CLI o la console Google Cloud.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Sicurezza, nel campo Crittografia dei secret a livello di applicazione, fai clic su Modifica crittografia dei secret a livello di applicazione.

  4. Deseleziona la casella di controllo Abilita la crittografia dei secret a livello di applicazione.

  5. Fai clic su Salva modifiche.

gcloud

Per disattivare la crittografia dei secret a livello di applicazione, esegui il seguente comando:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

Verifica che la crittografia dei secret a livello di applicazione sia attiva

Puoi verificare se un cluster utilizza la crittografia dei secret a livello di applicazione utilizzando la console Google Cloud o gcloud CLI.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Sicurezza, verifica che il campo Crittografia dei secret a livello di applicazione sia visualizzatoEnabled e che indichi la chiave corretta.

gcloud

Verifica se un cluster utilizza la crittografia dei secret a livello di applicazione:

gcloud container clusters describe CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --format='value(databaseEncryption)' \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

Se il cluster utilizza la crittografia dei secret a livello di applicazione, l'output è simile al seguente:

keyName=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME;state=ENCRYPTED

Ruota le chiavi

Best practice:

Ruota le chiavi con una pianificazione regolare, anche dopo aver attivato la crittografia dei secret a livello di applicazione. Per istruzioni su come configurare la rotazione automatica delle chiavi o su come ruotarle manualmente, consulta Rotazione delle chiavi.

Quando esegui una rotazione della chiave, i secret esistenti rimangono criptati con la versione precedente della chiave di crittografia della chiave (KEK). Per assicurarti che una versione più recente del KEK avvolga un secret, cripta di nuovo il secret dopo la rotazione delle chiavi.

Ad esempio, crei e memorizzi un secret, Secret1. È criptato con DEK1, che a sua volta è racchiuso in KEKv1.

Dopo la rotazione della KEK, cripta di nuovo Secret1 in modo che sia sottoposta a wrapping con DEK2, che a sua volta è sottoposta a wrapping con KEKv2, la KEK ruotata.

La rotazione delle versioni delle chiavi è un'operazione eventualmente coerente e potrebbe esserci un ritardo prima che la nuova versione della chiave venga applicata. Per ulteriori informazioni, consulta la sezione Coerenza delle versioni delle chiavi.

Ricriptare i secret

Dopo aver eseguito una rotazione della chiave, devi criptare di nuovo i secret per avvolgerli con la nuova versione della KEK. Attendi almeno tre ore prima di criptare di nuovo i secret dopo una rotazione.

Sebbene non sia possibile configurare la crittografia automatica utilizzando gcloud CLI, puoi, ad esempio, utilizzare un CronJob per eseguire il comando di crittografia a intervalli regolari.

Per criptare nuovamente manualmente i secret dopo una rotazione della chiave, attendi almeno tre ore affinché la nuova versione diventi coerente. Quindi, tocca ogni segreto per forzare la nuova crittografia utilizzando un comando come il seguente:

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Sostituisci TIME con una stringa che indichi quando avviene la rotazione (ad esempio 20200909-090909).

La vecchia versione della chiave continuerà a esistere e prevederà costi. Se la vecchia versione non è più in uso, ti consigliamo di distruggerla. L'eliminazione della versione della chiave è permanente, quindi assicurati di criptare di nuovo i tuoi secret prima di procedere.

Limitazioni

  • GKE supporta fino a 30.000 secret per cluster per la crittografia dei secret a livello di applicazione. Se memorizzi più di 30.000 secret, il cluster potrebbe diventare instabile al momento dell'upgrade, causando una potenziale interruzione dei carichi di lavoro.
  • Assicurati che le dimensioni medie dei metadati di un segreto in ogni spazio dei nomi siano inferiori a 5 KB. Se le dimensioni medie dei metadati sono superiori a 5 KB, il cluster potrebbe entrare in uno stato indesiderato in cui alcuni secret vengono criptati mentre altri vengono decriptati dopo l'attivazione o la disattivazione della funzionalità.

  • Devi selezionare una chiave nella stessa regione del cluster. Ad esempio, un cluster zonale in us-central1-a può utilizzare una chiave solo nella regione us-central1. Per i cluster regionali, le chiavi devono trovarsi nella stessa posizione per ridurre la latenza e per evitare i casi in cui le risorse dipendono da servizi distribuiti su più domini in errore.

    La chiave non deve necessariamente trovarsi nello stesso progetto del cluster. Per maggiori informazioni sulle località supportate per Cloud KMS, consulta le località di Google Cloud.

  • GKE supporta solo le chiavi di Cloud KMS. Non puoi utilizzare un altro fornitore KMS di Kubernetes o un altro fornitore di crittografia.

Risoluzione dei problemi

Per informazioni sulla risoluzione dei problemi relativi alla crittografia dei secret a livello di applicazione, inclusa la risoluzione dei problemi correlati agli aggiornamenti della crittografia dei secret non riusciti, consulta Risolvere i problemi relativi alla crittografia dei secret a livello di applicazione.

La chiave Cloud KMS è disabilitata

L'account di servizio predefinito di GKE non può utilizzare una chiave Cloud KMS disattivata per la crittografia dei secret a livello di applicazione.

Per riattivare una chiave disattivata, consulta Attivare una versione della chiave disattivata.

Passaggi successivi