Crittografia dei secret a livello di applicazione

Autopilot . Standard

---

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

---

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 archiviati inattivi dei clienti. inclusi i secret. GKE gestisce e gestisce questa impostazione la crittografia per te senza che tu debba fare altro.

La crittografia dei secret a livello di applicazione fornisce un ulteriore livello di sicurezza per i dati sensibili, come come Secret, archiviati in etcd. Puoi utilizzare una chiave gestita con Cloud KMS per criptare i dati in si trovano al livello dell'applicazione. Questa crittografia protegge da malintenzionati che accedere a una copia offline di etcd.

Per utilizzare la crittografia dei secret a livello di applicazione, devi prima creare una chiave Cloud KMS e fornire l'accesso all'account di servizio GKE alla chiave. Puoi utilizzare una chiave dispone di 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 previeni i casi in cui le risorse dipendono da servizi distribuiti in più errori domini. Dopo aver creato una chiave, puoi abilitare la funzionalità su una chiave nuova o esistente specificando la chiave che vuoi utilizzare. Quando attivi la funzionalità, GKE cripta tutti i secret nuovi ed esistenti usando la tua crittografia chiave.

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

Crittografia envelope

Kubernetes offre la crittografia envelope I secret con un provider KMS, ovvero una chiave locale, chiamata chiave di crittografia dei dati (DEK), viene utilizzata per criptare i secret. DEK a sua volta è criptata con un'altra chiave denominata chiave di crittografia della chiave (KEK). Kubernetes non archivia la KEK.

La crittografia della busta offre i seguenti vantaggi:

• Prestazioni migliorate rispetto alla crittografia della chiave pubblica: GKE usa l'API Cloud KMS solo per criptare le 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 in Cloud KMS è molto inferiore al numero di chiavi che criptano i tuoi dati.
• Capacità di utilizzare una radice di attendibilità centrale: i secret archiviati in Kubernetes può affidarsi a una radice di attendibilità esterna. Ciò significa che puoi una radice di attendibilità centrale, ad esempio una piattaforma di sicurezza modulo, per tutte le Secret. Un utente malintenzionato che accede ai container offline non può ottenere Secret.

Con la crittografia dei secret a livello di applicazione in GKE, GKE cripta i secret che utilizzano le DEK locali Provider AES-CBC. GKE cripta le DEK con una KEK che puoi gestire di Cloud KMS.

Per scoprire di più sulla crittografia envelope, consulta Crittografia buste.

Cosa succede quando crei un secret

Quando crei un nuovo secret, ecco cosa succede:

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. KMS utilizza l'account di servizio GKE del progetto devono eseguire l'autenticazione in Cloud KMS.

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

5. Il server API di Kubernetes salva il secret criptato e la DEK criptata. La DEK in testo non crittografato non viene salvata su un disco e viene archiviata solo nel server API la memoria.

6. Il server API Kubernetes crea una voce di cache che mappa la DEK criptata. la DEK in testo non crittografato in memoria. Questo consente al server API di decriptare il secret senza utilizzare Cloud KMS.

Ecco cosa accade quando un client richiede un secret al server API di Kubernetes si verifica quanto segue:

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

2. Il server API di 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 della cache, il plug-in KMS invia la DEK a Cloud KMS per la decrittografia mediante KEK. La DEK decriptata viene quindi utilizzato per decriptare il secret.

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

Cosa succede quando elimini una chiave

Avviso: l'eliminazione di una chiave non è reversibile: tutti i dati criptati la versione eliminata non sarà recuperabile.

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

Se prevedi di eliminare una vecchia versione KEK dopo un rotazione della chiave, utilizza la nuova versione della KEK ricripta il secret. In via facoltativa, puoi conservare precedente della KEK per evitare la ricrittografia dei secret, ma e fatturate per tutte le KEK attive in Cloud KMS. Per i dettagli sui prezzi, vedi Prezzi di Cloud KMS.

Nota: elimina le versioni KEK precedenti solo se hai la certezza che Nessun dato nel cluster è criptato utilizzando la versione precedente. Prima di eliminare una KEK, verificare se la chiave è in uso. Per maggiori dettagli, vedi Elimina e ripristina le versioni delle chiavi.

A meno che non utilizzi una proiezione del volume di token dell'account di servizio, i servizi usati dai tuoi carichi di lavoro su GKE usano anche i secret se una chiave viene eliminata, non sono più disponibili. Incapacità di accedere a questi significa che i carichi di lavoro avranno esito negativo.

Si applicano le seguenti eccezioni:

• Pod con accesso esistente ai secret come ambienti o volumi montati mantengono l'accesso.

• Il server API Kubernetes può comunque utilizzare le voci di mappatura DEK memorizzate nella cache per decriptare un secret dopo l'eliminazione della KEK. Questo consente di riavviare o ripianificare i pod accedere al secret a meno che non si verifichi una delle seguenti situazioni:

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

Prima di eliminare una KEK, verifica se viene 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 di questo argomento, sono necessari due progetti Google Cloud:

  • Progetto chiave: è qui che crei una KEK.

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

  Nota: puoi utilizzare lo stesso progetto per il progetto chiave e per il progetto del cluster. ma si consiglia di utilizzare progetti separati.

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

  Abilita l'API Cloud KMS

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

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

  Queste e molte altre autorizzazioni vengono concesse roles/cloudkms.admin Ruolo Identity and Access Management. Puoi apprendere scopri di più su concedere autorizzazioni per gestire le chiavi nella 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 all'ultima versione:

  gcloud components update

Crea una chiave Cloud KMS

Per creare una chiave Cloud KMS, devi prima creare un keyring. Chiavi e sono risorse a livello di regione. Quando crei un keyring, specifica una località che corrisponde alla località del cluster GKE:

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

• Un cluster a livello di regione deve usano un keyring della stessa posizione. Ad esempio, un cluster La regione asia-northeast1 deve essere protetta con un keyring Regione asia-northeast1.

Nota: l'uso della regione global di Cloud KMS non è supportato con e GKE.

Puoi utilizzare gcloud CLI o la console Google Cloud.

Console

Nel progetto chiave, 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 keyring, inserisci il nome del keyring.

4. Dal menu a discesa Località, seleziona la posizione del tuo cluster Kubernetes in un cluster Kubernetes.

5. Fai clic su Crea.

Quindi, 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 il quale 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 della chiave se se vuoi utilizzare valori diversi.

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

7. Fai clic su Crea.

gcloud

Nel 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 tuo keyring.
• KEY_PROJECT_ID: l'ID progetto chiave.

Concedi l'autorizzazione a utilizzare la chiave

L'account di servizio GKE nel progetto cluster ha quanto segue nome:

[e-mail]

Sostituisci CLUSTER_PROJECT_NUMBER con il tuo cluster numero di progetto. 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 oppure la con gcloud CLI.

Console

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

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

2. Fai clic sul nome del keyring contenente la chiave desiderata.

3. Seleziona la casella di controllo della chiave desiderata.

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

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

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

6. Fai clic su Salva.

gcloud

Concedi al tuo account di servizio GKE 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 località di Cloud KMS in cui hai creato il keyring.
• RING_NAME: il nome del tuo keyring.
• SERVICE_ACCOUNT_NAME: il nome del tuo l'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 è limitata dalla tua quota di chiavi. Assicurati che disponi di una quota sufficiente per utilizzare le tue chiavi Cloud HSM con la crittografia dei secret a livello di applicazione. Se la quota è esaurita, i nodi potrebbero perdere la connettività al cluster dal piano di controllo.

Abilita la crittografia dei secret a livello di applicazione

Puoi abilitare la crittografia dei secret a livello di applicazione su GKE Standard nuovi o esistenti GKE Autopilot e i cluster GKE Autopilot usando lgcloud CLId 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 istruzioni, consulta la sezione Configurazione della rotazione automatica.

In un nuovo cluster

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

Console - Autopilot

Per creare un cluster Autopilot con la crittografia dei secret a livello di applicazione abilitata, esegui 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 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, esegui la 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 nella tua 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 tuo keyring.
• KEY_NAME: il nome della chiave.
• CLUSTER_PROJECT_ID: l'ID progetto del 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 per utilizzare la crittografia dei secret a livello di applicazione. GKE cripta tutti i tuoi nuovi ed esistenti usando la chiave di crittografia specificata.

Importante: l'aggiornamento di un cluster esistente per utilizzare la crittografia dei secret a livello di applicazione riavvia la dal piano di controllo del cluster. Per i cluster di zona, il piano di controllo non è 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, in Crittografia dei secret a livello di applicazione fai clic su Modifica la 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 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 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 di Compute Engine nel 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 tuo keyring.
• KEY_NAME: il nome della chiave.
• CLUSTER_PROJECT_ID: l'ID progetto del cluster.

Aggiorna una chiave Cloud KMS

Puoi utilizzare gcloud CLI o la console Google Cloud per aggiornare esistente per utilizzare una nuova chiave Cloud KMS.

Importante: aggiorna un cluster esistente per utilizzare una nuova chiave Cloud KMS riavvia il piano di controllo del cluster. Per i cluster di zona, il controllo non sarà 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, in Crittografia dei secret a livello di applicazione fai clic su Modifica la 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 nel 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 tuo keyring.
• KEY_NAME: il nome della chiave.
• CLUSTER_PROJECT_ID: l'ID progetto del 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 nella 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, in Crittografia dei secret a livello di applicazione fai clic su Modifica la 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 nel cluster.
• CLUSTER_PROJECT_ID: l'ID progetto del 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 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 venga visualizzato il campo Crittografia dei secret a livello di applicazione. Enabled e elenca 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:

• CLUSTER_NAME: il nome del tuo cluster.
• COMPUTE_REGION: la regione di Compute Engine nel cluster.
• CLUSTER_PROJECT_ID: l'ID progetto del 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 regolarmente, anche dopo aver abilitare la crittografia dei secret a livello di applicazione. Per istruzioni su come configurare la rotazione automatica delle chiavi per ruotare manualmente le chiavi, consulta la sezione Rotazione delle chiavi.

Quando esegui una rotazione della chiave, i secret esistenti rimangono criptati la versione precedente della chiave di crittografia della chiave (KEK). Per assicurarti che una versione KEK più recente esegua il wrapping di Secret, ricripta il secret dopo la rotazione della chiave.

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

Una volta che la KEK ruota, criptizzi nuovamente Secret1 in modo che venga sottoposto a wrapping da DEK2, che a sua volta è aggregato con KEKv2, la KEK ruotata.

Nota: la rotazione della versione della chiave è un'operazione a coerenza finale e l'applicazione della nuova versione della chiave potrebbe subire un ritardo. Ti consigliamo di attendere almeno tre ore prima di ricriptare i secret dopo una rotazione. Consulta Coerenza delle versioni della chiave per ulteriori informazioni informazioni.

Ricripta i tuoi secret

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

Per ricriptare manualmente i tuoi secret dopo la rotazione della chiave, attendi almeno tre ore necessarie affinché la nuova versione diventi coerente. Poi tocca ogni secret per forzare la ricrittografia 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 viene eseguita la rotazione (ad esempio, 20200909-090909).

Nota: la versione precedente della chiave esisterà ancora e prevede dei costi. Se la versione precedente non è più in uso, ti consigliamo di eliminarlo. L'eliminazione della versione della chiave è definitiva, quindi assicurati di criptare nuovamente i tuoi secret prima ce la puoi fare.

Limitazioni

• GKE supporta fino a 30.000 secret per cluster la crittografia dei secret a livello di applicazione. Se archivi più di 30.000 secret, il cluster potrebbe diventano instabili al momento dell'upgrade, causando una potenziale interruzione carichi di lavoro con scale out impegnativi.
• 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, mentre altri decriptato dopo l'attivazione o la disattivazione della funzionalità.

• Devi selezionare una chiave nella stessa regione del cluster. Ad esempio, un un cluster 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à ridurre la latenza ed evitare casi in cui le risorse dipendono dai servizi distribuiti su più domini in errore.

  Nota: non è necessario che la chiave si trovi nello stesso progetto del cluster. Per per ulteriori informazioni sulle località supportate per Cloud KMS, vedi Località di Google Cloud.

• GKE supporta solo le chiavi di Cloud KMS. Non puoi usa un altro cluster Kubernetes Fornitore KMS o un altro di crittografia lato client.

Risoluzione dei problemi

Per informazioni sulla risoluzione dei problemi di crittografia dei secret a livello di applicazione, inclusa la risoluzione dei problemi con aggiornamenti della crittografia dei secret non riusciti, consulta Risolvi 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 un account Chiave Cloud KMS per crittografia dei secret a livello di applicazione.

Per riattivare una chiave disattivata, consulta: Abilitare una versione della chiave disabilitata.

Passaggi successivi

• Scopri di più sui secret in Kubernetes.
• Scopri di più sulla gestione dei secret tramite Cloud KMS.
• Scopri come migliorare la protezione del tuo cluster.