Crittografia dei secret a livello di applicazione

Questo tutorial mostra come criptare i Secret di Kubernetes a livello di applicazione utilizzando una chiave che gestisci in Cloud Key Management Service (Cloud KMS). Il processo di crittografia dei secret fornisce un ulteriore livello di sicurezza per i carichi di lavoro sensibili.

Questa pagina è rivolta agli esperti di sicurezza che vogliono criptare i secret. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli utente e attività comuni di GKE.

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

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 memorizzati nel database dello stato del cluster. Se abilitata, utilizzi una chiave gestita con Cloud KMS per criptare questi dati a livello di applicazione.

In GKE versione 1.35 o successive, le risorse Kubernetes specifiche criptate dipendono dall'archivio coppia chiave-valore che ospita lo stato del cluster, come segue:

  • Spanner: la crittografia dei secret a livello di applicazione cripta tutti gli oggetti API Kubernetes.
  • etcd: la crittografia dei secret a livello di applicazione cripta principalmente i secret.

Per utilizzare la crittografia dei secret a livello di applicazione, devi prima creare una chiave Cloud KMS e concedere a Kubernetes Engine Service Agent l'accesso alla chiave. Puoi utilizzare una chiave con 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 in più domini in 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 gli oggetti nel database dello stato del cluster con la tua chiave di crittografia. I tipi di API specifici crittografati dipendono dal coppia chiave-valore store utilizzato dal cluster, come descritto nell'elenco precedente.

Crittografia envelope

Kubernetes offre la crittografia 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 archivia la KEK.

La crittografia envelope offre i seguenti vantaggi:

  • Prestazioni migliorate rispetto alla crittografia con chiave pubblica: GKE utilizza 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 che devi archiviare nel servizio Cloud KMS è di gran lunga inferiore al numero di chiavi che criptano i tuoi 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 una radice di attendibilità centrale, ad esempio un modulo di sicurezza hardware, per tutti i tuoi secret. Un malintenzionato che accede ai tuoi container offline non può ottenere i tuoi segreti.

Con la crittografia dei secret a livello di applicazione in GKE, GKE cripta i tuoi secret utilizzando le 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 a busta, consulta Crittografia a busta.

Cosa succede quando i dati vengono criptati

Quando crei una nuova risorsa Kubernetes idonea alla crittografia, ecco cosa succede:

  1. GKE genera una DEK utilizzando un generatore di numeri casuali.

  2. GKE cripta i dati localmente nel control plane utilizzando questa DEK.

  3. GKE invia la DEK a Cloud KMS per la crittografia. Questa operazione utilizza l'agente di servizio Kubernetes Engine del tuo progetto per autenticarsi in Cloud KMS.

  4. Cloud KMS cripta la DEK utilizzando la KEK e la invia di nuovo al piano di controllo GKE.

  5. Il control plane di GKE archivia i dati criptati insieme alla DEK criptata nel database del cluster. La DEK in testo non crittografato non viene scritta su disco, anche se viene memorizzata nella cache per migliorare le prestazioni.

Quando un client richiede i dati dal server API Kubernetes, ecco cosa succede:

  1. Il control plane GKE recupera i dati criptati dal database dello stato del cluster.

  2. Il control plane GKE controlla la cache di memoria per la DEK in testo normale. Se la cache contiene la DEK in testo non crittografato, GKE la utilizza per decriptare i dati.

  3. Se la DEK non è nella cache, GKE invia la DEK criptata a Cloud KMS per la decriptazione utilizzando la tua KEK.

  4. GKE riceve la DEK decriptata da Cloud KMS e la utilizza per decriptare i dati.

  5. Il server API Kubernetes restituisce i dati decriptati al client.

Cosa succede quando distruggi una chiave

Se prevedi di distruggere una versione precedente della KEK dopo una rotazione delle chiavi, assicurati che i dati nel cluster siano protetti dalla nuova versione della KEK. La procedura dipende dall'ambito di crittografia del cluster (verifica l'ambito di crittografia).

Se vuoi, puoi conservare la versione precedente della KEK per evitare di criptare nuovamente i secret, ma continuerai a ricevere addebiti per tutte le KEK attive in Cloud KMS. Per i dettagli, consulta i prezzi di Cloud KMS.

A meno che non utilizzi una proiezione del volume dei token dei service account, i service account utilizzati dai tuoi workload su GKE utilizzano anche i secret e, se una chiave viene eliminata, questi diventano non disponibili. L'impossibilità di accedere a questi elementi comporta l'errore dei workload.

Si applicano le seguenti eccezioni:

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

  • Il control plane GKE può comunque utilizzare le voci di mappatura DEK memorizzate nella cache per decriptare i dati dopo l'eliminazione della KEK. In questo modo, i pod riavviati o ripianificati possono accedere ai dati, a meno che non si verifichi una delle seguenti situazioni:

    • Il control plane del cluster viene riavviato.
    • Il pod del control plane GKE viene riavviato.
    • La DEK non si trova nella cache del control plane GKE.

Prima di eliminare una KEK, controlla se è utilizzata dal tuo cluster. Puoi anche creare una policy di avviso per la distruzione delle chiavi in Cloud KMS. Elimina le versioni precedenti della KEK solo quando hai la certezza che nessun dato nel cluster sia criptato utilizzando la versione precedente. Prima di eliminare una KEK, controlla se la chiave è in uso. Per maggiori dettagli, consulta Elimina e ripristina le versioni delle chiavi.

Puoi pianificare l'eliminazione di una versione della chiave dopo un periodo configurabile. In questo periodo, se cambi idea, puoi ripristinare la versione della chiave per evitare l'eliminazione. Tuttavia, una volta raggiunta l'ora di eliminazione pianificata e la versione della chiave viene eliminata, questa azione è irreversibile. Tutti i dati criptati con questa versione della chiave diventeranno indecriptabili in modo permanente.

Prima di iniziare

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

    • Progetto chiave: qui 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 chiave e il progetto cluster. Tuttavia, la prassi consigliata è utilizzare progetti separati.

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

    Abilita l'API Cloud KMS

  • Nel progetto delle chiavi, l'utente che crea la chiave automatizzata 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 roles/cloudkms.admin predefinito. Puoi scoprire di più sulla concessione delle 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. Le chiavi e i portachiavi sono risorse regionali. Quando crei una chiave automatizzata, specifica una località che corrisponda a quella del tuo cluster GKE:

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

  • Un cluster regionale deve utilizzare chiavi automatizzate dalla stessa località. Ad esempio, un cluster nella regione asia-northeast1 deve essere protetto con chiavi automatizzate della regione asia-northeast1.

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

Puoi utilizzare gcloud CLI o la console Google Cloud .

Console

Nel progetto di gestione delle chiavi, crea chiavi automatizzate:

  1. Vai alla pagina Key Management nella console Google Cloud .

    Vai a Gestione delle chiavi

  2. Fai clic su Crea keyring.

  3. Nel campo Nome chiavi automatizzate, inserisci il nome delle chiavi automatizzate.

  4. Dall'elenco Località, seleziona la località del tuo cluster Kubernetes.

  5. Fai clic su Crea.

Poi, crea una chiave:

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

    Vai a Gestione delle chiavi

  2. Fai clic sul nome delle chiavi automatizzate 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 progetto chiave, crea una chiave automatizzata:

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

Sostituisci quanto segue:

  • RING_NAME: il nome del nuovo keyring.
  • LOCATION: la località in cui vuoi creare le chiavi automatizzate.
  • KEY_PROJECT_ID: il tuo 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à Cloud KMS in cui hai creato le chiavi automatizzate.
  • RING_NAME: il nome delle chiavi automatizzate.
  • KEY_PROJECT_ID: il tuo ID progetto chiave.

Concedere l'autorizzazione per utilizzare la chiave

L'agente di servizio Kubernetes Engine 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 di progetto del tuo cluster. Per trovare il numero di progetto utilizzando gcloud CLI, esegui questo comando:

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

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

Console

Concedi all'agente di servizio Kubernetes Engine il ruolo Cloud KMS CryptoKey Encrypter/Decrypter:

  1. Nella console Google Cloud , vai alla pagina Gestione chiavi.

    Vai a Gestione delle chiavi

  2. Fai clic sul nome delle chiavi automatizzate contenenti la chiave desiderata.

  3. Seleziona la casella di controllo relativa alla 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 del Kubernetes Engine Service Agent a cui stai concedendo l'accesso.

  5. Nel menu a discesa Seleziona un ruolo, seleziona Cloud KMS CryptoKey Encrypter/Decrypter.

  6. Fai clic su Salva.

gcloud

Concedi al tuo Kubernetes Engine Service Agent il ruolo CryptoKey Encrypter/Decrypter di 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 di Cloud KMS in cui hai creato le chiavi automatizzate.
  • RING_NAME: il nome delle chiavi automatizzate.
  • SERVICE_ACCOUNT_NAME: il nome del tuo Kubernetes Engine Service Agent.
  • KEY_PROJECT_ID: l'ID progetto della 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 control plane 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 gcloud CLI o la console Google Cloud .

Best practice:

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

Abilita su un nuovo cluster

Puoi creare un nuovo cluster con la crittografia dei secret a livello di applicazione abilitata utilizzando la consoleGoogle 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. Nella console Google Cloud , vai alla pagina Crea un cluster Autopilot.

    Vai a Crea un cluster Autopilot

  2. Configura il cluster come preferisci.

  3. Nel riquadro di navigazione, fai clic su Impostazioni avanzate ed espandi la sezione Sicurezza.

  4. In Cripta i secret a livello di applicazione, seleziona Chiave Cloud KMS e scegli la chiave che hai creato in Crea una chiave Cloud KMS.

  5. 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. Nella console Google Cloud , vai alla pagina Crea un cluster Kubernetes.

    Vai a Crea un cluster Kubernetes

  2. Configura il cluster come preferisci.

  3. Nel riquadro di navigazione, fai clic su Impostazioni avanzate.

  4. Nella riga Crittografia dei secret a livello di applicazione, fai clic su Modifica configurazione.

  5. In Cripta i secret a livello di applicazione, seleziona Chiave Cloud KMS e scegli la chiave che hai creato in Crea una chiave Cloud KMS.

  6. Fai clic su Salva.

  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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
  • CONTROL_PLANE_LOCATION: la regione di Compute Engine del control plane del tuo cluster.
  • KEY_PROJECT_ID: il tuo ID progetto chiave.
  • LOCATION: la località Cloud KMS in cui hai creato le chiavi automatizzate.
  • RING_NAME: il nome delle chiavi automatizzate.
  • 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.

Abilita 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 tuoi secret esistenti e nuovi utilizzando la chiave di crittografia specificata.

L'aggiornamento di un cluster esistente per utilizzare la crittografia dei secret a livello di applicazione riavvia il control plane del cluster. Durante questa procedura, GKE crittografa nuovamente tutti i secret esistenti con la nuova chiave, quindi prevedi un tempo di esecuzione dell'operazione a lunga esecuzione. Per i cluster di zona, il control plane diventa 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, 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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
  • CONTROL_PLANE_LOCATION: la località di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
  • KEY_PROJECT_ID: l'ID progetto della chiave.
  • LOCATION: la località Cloud KMS in cui hai creato le chiavi automatizzate.
  • RING_NAME: il nome delle chiavi automatizzate.
  • 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 che utilizzi una nuova chiave Cloud KMS.

L'aggiornamento di un cluster esistente per utilizzare una nuova chiave Cloud KMS riavvia il control plane del cluster. Durante questa procedura, GKE ricripta tutti i secret esistenti con la nuova chiave, quindi prevedi un'operazione di lunga durata. Per i cluster zonali, il control plane non è disponibile durante l'aggiornamento.

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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
  • CONTROL_PLANE_LOCATION: la località di Compute Engine del control plane del tuo cluster. Specifica una regione per i cluster a livello di regione o una zona per i cluster a livello di zona.
  • KEY_PROJECT_ID: l'ID progetto della chiave.
  • LOCATION: la località Cloud KMS in cui hai creato le chiavi automatizzate.
  • RING_NAME: il nome delle chiavi automatizzate.
  • 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 consoleGoogle 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 questo comando:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • CONTROL_PLANE_LOCATION: la località di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
  • 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 consoleGoogle 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 che vuoi ispezionare.

  3. In Sicurezza, individua il campo Crittografia dei secret a livello di applicazione. Il valore in questo campo indica quali oggetti sono criptati, come segue:

    • Abilitato (tutti gli oggetti): tutti gli oggetti API di Kubernetes nel database dello stato del cluster sono criptati.
    • Attivato: vengono criptati solo i secret.

gcloud

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

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(databaseEncryption.state)' \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • CONTROL_PLANE_LOCATION: la località di Compute Engine del control plane del tuo cluster. Specifica una regione per i cluster a livello di regione o una zona per i cluster a livello di zona.
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster.

L'output indica quali oggetti sono criptati, come segue:

  • ALL_OBJECTS_ENCRYPTION_ENABLED: tutti gli oggetti API Kubernetes nel database dello stato del cluster sono criptati.
  • ENCRYPTED: vengono criptati solo i secret.

Se l'output è DECRYPTED, la crittografia dei secret a livello di applicazione è disabilitata.

Ruota le chiavi

Best practice:

Ruota le chiavi regolarmente, anche dopo aver abilitato la crittografia dei secret a livello di applicazione. Per istruzioni su come configurare la rotazione automatica delle chiavi o ruotare manualmente le chiavi, vedi 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 della KEK esegua il wrapping di un secret, crittografa nuovamente il secret dopo la rotazione della chiave.

Ad esempio, crei e archivi un secret, Secret1. Viene criptata con DEK1, che a sua volta è aggregata con KEKv1.

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

La rotazione della versione della chiave è un'operazione con coerenza finale e potrebbe verificarsi un ritardo prima che la nuova versione della chiave diventi effettiva. Per saperne di più, consulta Coerenza delle versioni delle chiavi.

Crittografa nuovamente i secret

Dopo aver eseguito una rotazione della chiave, devi criptare nuovamente i secret per eseguirne il wrapping con la nuova versione della KEK. Puoi criptare nuovamente i secret in uno dei seguenti modi:

  • Manualmente, eseguendo un comando kubectl in un terminale.
  • Automaticamente, utilizzando un workload ricorrente, come un CronJob, per eseguire un comando kubectl a intervalli regolari.

Dopo la rotazione della chiave, attendi almeno tre ore prima che la nuova versione diventi coerente. Quindi, attiva la nuova crittografia eseguendo un comando simile al seguente:

kubectl get secrets --namespace=NAMESPACE -o json \
    | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Sostituisci quanto segue:

  • NAMESPACE: lo spazio dei nomi in cui aggiornare i secret. Nei cluster Standard, puoi facoltativamente utilizzare il flag --all-namespaces per aggiornare ogni secret nel cluster con lo stesso comando. Nei cluster Autopilot, puoi aggiornare solo gli spazi dei nomi di tua proprietà.
  • TIME: una stringa che indica quando avviene la rotazione (ad esempio 20200909-090909).

Dopo la rotazione delle chiavi, la versione precedente della chiave continua a esistere e potrebbe generare costi. L'eliminazione della versione della chiave è definitiva, quindi assicurati che la versione precedente della chiave non sia più in uso prima di eliminarla. Per saperne di più, consulta Visualizza l'utilizzo delle chiavi.

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 workload.
  • 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 anomalo 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 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 impedire casi in cui le risorse dipendono da servizi distribuiti su più domini in errore.

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

  • GKE supporta solo le chiavi di Cloud KMS. Non puoi utilizzare un altro provider KMS Kubernetes o un altro provider 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 relativi agli 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

Il Kubernetes Engine Service Agent non può utilizzare una chiave Cloud KMS disabilitata per la crittografia dei secret a livello di applicazione.

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

La versione della chiave Cloud KMS è stata eliminata

Quando lo stato del cluster contiene il messaggio: KEY_VERSION_URI is not enabled, current state is: DESTROYED, significa che la versione della chiave utilizzata per la crittografia dei secret a livello di applicazione è stata eliminata.

Sostituisci KEY_VERSION_URI con l'URI della versione della chiave.

Passaggi successivi