Crittografia dei secret a livello di applicazione

Autopilot Standard

---

Scopri come criptare i Secret di Kubernetes a livello di applicazione utilizzando una chiave gestita da te in Cloud Key Management Service (Cloud KMS). Poiché questa funzionalità si basa sulle funzionalità di Cloud KMS, è consigliabile acquisire familiarità con la rotazione delle chiavi e la crittografia envelope.

---

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

Guidami

---

Panoramica

Per impostazione predefinita, Google Kubernetes Engine (GKE) cripta i contenuti dei clienti archiviati at-rest, 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 fornisce un ulteriore livello di sicurezza per i dati sensibili, ad esempio i secret, archiviati in etcd. Con questa funzionalità, puoi utilizzare una chiave gestita con Cloud KMS per criptare i dati a livello di applicazione. Questa crittografia protegge da malintenzionati che ottengono l'accesso 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 l'accesso alla chiave all'account di servizio GKE. Puoi utilizzare una chiave che abbia uno qualsiasi dei livelli di protezione supportati da Cloud KMS.

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

Nota: Quando utilizzi CMEK in GKE, i tuoi progetti possono consumare quote per le richieste crittografiche di Cloud KMS. Ad esempio, GKE può consumare queste quote quando utilizzi una chiave di crittografia delle chiavi di Cloud KMS per criptare o decriptare una chiave di crittografia dei dati in GKE. Le operazioni di crittografia e decriptazione mediante chiavi CMEK influiscono sulle quote di Cloud KMS solo se utilizzi chiavi hardware (Cloud HSM) o esterne (Cloud EKM). Per ulteriori informazioni, consulta Quote di Cloud KMS.

Crittografia envelope

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

La crittografia busta offre i seguenti vantaggi:

• La KEK può essere ruotata senza richiedere una nuova crittografia di tutti i secret. Ciò significa che puoi seguire più facilmente la best practice della rotazione della chiave regolare, senza un impatto significativo sulle prestazioni.

• I secret archiviati in Kubernetes possono basarsi su una radice di attendibilità esterna. Ciò significa che puoi utilizzare una radice di attendibilità centrale, ad esempio un Modulo di sicurezza hardware, per tutti i tuoi secret, e che un utente malintenzionato che accede ai tuoi container offline non potrà ottenere i tuoi secret.

Con la crittografia dei secret a livello di applicazione in GKE, i tuoi secret vengono criptati localmente mediante il provider AES-CBC con DEK locali, mentre le DEK vengono criptate con una KEK gestita dall'utente in Cloud KMS.

Per scoprire di più sulla crittografia busta, consulta Crittografia busta.

Cosa succede quando crei un secret

Ecco cosa succede quando crei un nuovo secret:

1. Il server API Kubernetes genera una DEK univoca 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 l'autenticazione in Cloud KMS.

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

5. Il server API Kubernetes salva il secret criptato e la DEK criptata. La DEK in testo non crittografato non viene salvata su disco.

6. Il server API Kubernetes crea una voce della cache che mappa la DEK criptata alla DEK in testo non crittografato. In questo modo il server API può decriptare il secret senza utilizzare Cloud KMS.

Quando un client richiede un secret al server API Kubernetes, ecco cosa succede:

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

2. Il server API Kubernetes controlla se nella cache è presente una voce di mappatura esistente e decripta il secret senza utilizzare Cloud KMS.

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

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

Cosa succede quando distruggi una chiave

Avviso: l'eliminazione di una chiave è irreversibile. I dati criptati con la versione eliminata non saranno recuperabili.

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

Se prevedi di eliminare una versione precedente della KEK dopo una rotazione della chiave, utilizza prima la nuova versione della KEK per ricriptare prima il secret.

A meno che non utilizzi una proiezione del volume di token dell'account di servizio, anche gli account di servizio utilizzati dai tuoi carichi di lavoro su GKE usano secret e, se una chiave viene eliminata, questi non diventano disponibili. L'impossibilità di accedervi significa che i carichi di lavoro non andranno a buon fine.

Nota: i carichi di lavoro di sistema su GKE utilizzano i secret per l'autenticazione degli account di servizio. Se una KEK viene eliminata e questi secret non sono più disponibili, il cluster non verrà avviato.

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 eliminato la KEK. Ciò consente ai pod riavviati o ripianificati di accedere al secret a meno che:

  • Il piano di controllo del cluster viene riavviato.
  • Il pod del server dell'API Kubernetes viene riavviato.
  • La voce di mapping DEK per il secret non si trova nella cache del server API Kubernetes.

Prima di eliminare una KEK, controlla se è utilizzata dal cluster. Puoi anche creare un criterio di avviso per l'eliminazione delle chiavi in Cloud KMS.

Prima di iniziare

• Per eseguire gli esercizi su questo argomento, sono necessari due progetti Google Cloud:

  • Progetto chiave: è qui che crei una KEK.

  • Progetto cluster: qui puoi creare un cluster che consente la crittografia dei secret a livello di applicazione.

  Nota: puoi utilizzare lo stesso progetto per il progetto chiave e per il progetto del cluster. Tuttavia, la prassi consigliata è utilizzare progetti separati.

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

  Abilita API Cloud KMS

• Nel tuo progetto chiave, l'utente che crea il keyring e la chiave deve avere le seguenti autorizzazioni IAM:

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

  Queste autorizzazioni (e molte altre) vengono concesse al roles/cloudkms.admin ruolo Identity and Access Management predefinito. Per scoprire di più su come concedere le autorizzazioni per la gestione delle chiavi, consulta la documentazione di Cloud KMS.

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

  Abilita 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 keyring, specifica una località che corrisponde a quella del cluster GKE:

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

• Un cluster a livello di regione deve utilizzare un keyring della stessa località. Ad esempio, un cluster nella regione asia-northeast1 deve essere protetto con un keyring della regione asia-northeast1.

Nota: la regione global di Cloud KMS non è supportata per l'utilizzo con GKE.

Puoi utilizzare gcloud CLI o la console Google Cloud.

Console

Nel tuo progetto chiave, crea un keyring:

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

   Vai a Key Management

2. Fai clic su Crea keyring.

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

4. Nel menu a discesa Posizione, seleziona la località del tuo cluster Kubernetes.

5. Fai clic su Crea.

Quindi, crea una chiave:

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

   Vai a Key Management

2. Fai clic sul nome del keyring per cui creerai 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 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 tuo progetto chiave, crea un keyring:

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

Sostituisci quanto segue:

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

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 località di Cloud KMS in cui hai creato il keyring.
• RING_NAME: il nome del keyring.
• KEY_PROJECT_ID: l'ID progetto chiave.

Concedi l'autorizzazione a utilizzare la chiave

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

[e-mail]

Sostituisci CLUSTER_PROJECT_NUMBER con il numero di progetto del cluster. Per trovare il numero del progetto utilizzando gcloud CLI, esegui questo 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/decriptazione CryptoKey Cloud KMS:

1. Apri il browser Cloud Key Management Service Keys (Chiave di servizio Cloud Key Management Service) nella console Google Cloud.
   Apri il browser delle chiavi Cloud KMS

2. Fai clic sul nome del keyring che contiene la chiave desiderata.

3. Seleziona la casella di controllo relativa alla chiave desiderata.

   Nel riquadro a destra della finestra diventa disponibile la scheda Autorizzazioni.

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

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

6. Fai clic su Salva.

gcloud

Concedi al tuo account di servizio GKE il ruolo Autore crittografia/decriptazione 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 località di Cloud KMS in cui hai creato il keyring.
• RING_NAME: il nome del keyring.
• SERVICE_ACCOUNT_NAME: il nome del tuo account di servizio GKE.
• KEY_PROJECT_ID: l'ID progetto chiave.

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 contiene la chiave è limitato dalla quota di chiavi. Assicurati di disporre di 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 in cluster GKE Standard e GKE Autopilot nuovi o esistenti utilizzando gcloud CLI o la console Google Cloud.

Dopo aver abilitato la crittografia dei secret a livello di applicazione, ti consigliamo di eseguire una rotazione della chiave. Puoi configurare la rotazione automatica delle chiavi in Cloud KMS. Per le istruzioni, consulta Configurare la rotazione automatica.

In un nuovo cluster

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

Console - Autopilot

Per creare un cluster Autopilot con la crittografia dei secret a livello di applicazione abilitata, segui questi 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, segui questi 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 che scegli per il nuovo cluster.
• COMPUTE_REGION: la regione di Compute Engine in cui vuoi creare il cluster.
• KEY_PROJECT_ID: l'ID progetto chiave.
• LOCATION: la località di Cloud KMS in cui hai creato il keyring.
• RING_NAME: il nome del keyring.
• 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 in un nuovo cluster Standard utilizzando il comando gcloud container clusters create con gli stessi flag.

In un cluster esistente

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

Importante: 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 di zona, il piano di controllo diventa non disponibile.

Console

Per aggiornare un cluster in modo da supportare 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 questo 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 di Compute Engine del cluster.
• KEY_PROJECT_ID: l'ID progetto chiave.
• LOCATION: la località di Cloud KMS in cui hai creato il keyring.
• RING_NAME: il nome del keyring.
• KEY_NAME: il nome della chiave.
• CLUSTER_PROJECT_ID: l'ID progetto del tuo cluster.

Aggiorna una chiave Cloud KMS

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

Importante: l'aggiornamento di un cluster esistente per l'utilizzo di una nuova chiave Cloud KMS riavvia il piano di controllo del cluster. Per i cluster di zona, il piano di controllo non è più 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 per 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 di Compute Engine del cluster.
• KEY_PROJECT_ID: l'ID progetto chiave.
• LOCATION: la località di Cloud KMS in cui hai creato il keyring.
• RING_NAME: il nome del keyring.
• 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 disabilitare 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 disabilitare la crittografia dei secret a livello di applicazione, esegui questo comando:

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

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster.
• COMPUTE_REGION: la regione di Compute Engine del cluster.
• CLUSTER_PROJECT_ID: l'ID progetto del tuo cluster.

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

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 nel campo Crittografia dei secret a livello di applicazione sia visualizzato Enabled e che l'elenco della chiave sia corretto.

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:

• CLUSTER_NAME: il nome del tuo cluster.
• COMPUTE_REGION: la regione di Compute Engine del cluster.
• CLUSTER_PROJECT_ID: l'ID progetto del tuo cluster.

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

Ti consigliamo di ruotare le chiavi in base a una pianificazione regolare, anche dopo aver abilitato la crittografia dei secret a livello di applicazione. Per istruzioni su come configurare la rotazione automatica delle chiavi o su come ruotare manualmente le chiavi, consulta la sezione 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 di KEK esegua il wrapping di un secret, cripta nuovamente il secret dopo la rotazione della chiave.

Ad esempio, crei e archivi un secret, Secret1. È criptato con DEK1, che a sua volta viene sottoposto a wrapping con KEKv1.

Dopo la rotazione della KEK, cripta nuovamente Secret1 in modo che venga aggregato da DEK2, che a sua volta viene aggregato con KEKv2, la KEK ruotata.

Nota: la rotazione della versione della chiave è un'operazione coerente e potrebbe verificarsi un ritardo prima che la nuova versione della chiave venga applicata. Ti consigliamo di attendere almeno tre ore prima di criptare nuovamente i tuoi secret dopo una rotazione. Per ulteriori informazioni, consulta Coerenza delle versioni delle chiavi.

Ricripta i tuoi secret

Dopo aver eseguito una rotazione della chiave, devi ricriptare i tuoi secret per eseguirne il wrapping con la nuova versione della KEK. Sebbene non sia possibile configurare la ricrittografia automatica utilizzando gcloud CLI, ad esempio puoi utilizzare un CronJob per eseguire il comando di ricrittografia a intervalli regolari.

Per ricriptare manualmente i tuoi secret dopo una rotazione della chiave, attendi almeno tre ore affinché la nuova versione diventi coerente. Tocca quindi ogni secret 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 indica quando avviene la rotazione (ad esempio, 20200909-090909).

Nota: la versione precedente della chiave continuerà a esistere e comporterà dei costi. Se la versione precedente non viene più in uso, potrebbe essere necessario eliminarla. L'eliminazione della versione della chiave è definitiva, quindi assicurati di criptare nuovamente i tuoi secret prima di farlo.

Limitazioni

• GKE supporta fino a 30.000 secret per cluster per la crittografia dei secret a livello di applicazione. Se archivi più di 30.000 secret, il cluster potrebbe diventare instabile al momento dell'upgrade, causando una potenziale interruzione dei carichi di lavoro.
• Assicurati che la dimensione media dei metadati di un secret in ogni spazio dei nomi sia inferiore a 5 KiB. Se la dimensione media dei metadati è superiore a 5 KiB, il cluster potrebbe entrare in uno stato non valido in cui alcuni secret sono criptati e altri vengono decriptati dopo l'abilitazione o la disattivazione della funzionalità.

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

  Nota: la chiave non deve necessariamente trovarsi nello stesso progetto del cluster. Per ulteriori informazioni sulle località supportate per Cloud KMS, consulta Località di Google Cloud.

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

Risoluzione dei problemi

La chiave Cloud KMS è disabilitata.

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

Per riabilitare una chiave disabilitata, vedi Abilitare una versione della chiave disabilitata.

Passaggi successivi

• Scopri di più sui secret in Kubernetes.
• Scopri di più sulla gestione dei secret mediante Cloud KMS.
• Scopri come proteggere il cluster.