Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Ruotare le CA e le chiavi del piano di controllo gestito dal cliente

Standard

Questa pagina mostra agli amministratori di cluster e ai Security Engineer come ruotare le autorità di certificazione (CA) e le chiavi di firma dei account di servizio configurate per GKE control plane authority.

Dovresti avere familiarità con i seguenti concetti:

Pianifica le rotazioni delle credenziali

Questo documento mostra come ruotare i seguenti componenti delle credenziali nel control plane:

La CA radice del cluster, la CA radice di aggregazione, la CA radice dell'API etcd e la CA radice peer etcd.
Le chiavi di firma e verifica del ServiceAccount Kubernetes.

Puoi anche ruotare le chiavi di crittografia gestite dal cliente che hai utilizzato per criptare i dischi di avvio del control plane, i dischi etcd e il backup interno di etcd utilizzato da Google Cloud per il ripristino di emergenza. Per saperne di più, consulta Ruota le chiavi di crittografia del disco di avvio di etcd e del control plane.

Ruota le credenziali per evitare la scadenza della CA, per mitigare le compromissioni delle versioni delle chiavi e nell'ambito delle pratiche di sicurezza della tua organizzazione. Per pianificare la frequenza con cui ruotare risorse specifiche di GKE control plane authority, tieni presente quanto segue:

Per impostazione predefinita, i certificati GKE firmati dalle CA root in Certificate Authority Service (CA Service) scadono un anno dopo la data di creazione.
Le chiavi in Cloud Key Management Service (Cloud KMS) non scadono. Esegui una rotazione manuale delle chiavi solo se la tua organizzazione ha requisiti per rotazione della chiave. Per ridurre al minimo le interruzioni dei workload in esecuzione, non configurare la rotazione automatica delle chiavi per queste chiavi.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Disporre di un cluster esistente che utilizza CA autogestite e account di servizio account ed esegue GKE versione 1.35.2-gke.1842000 o successive.
Identifica gli ID progetto dei seguenti progetti Google Cloud :
- Progetto chiave: il progetto che contiene le risorse Cloud KMS e CA Service.
- Progetto cluster: il progetto che contiene il tuo cluster GKE.
Per eseguire le attività di convalida descritte in questo documento, verifica che siano abilitati i seguenti audit log di accesso ai dati:
- API Cloud Key Management Service (KMS): DATA_READ
- Certificate Authority Service: ADMIN_READ
Per abilitare questi tipi di log, consulta Abilita il controllo dell'accesso ai dati.

Ruoli e autorizzazioni richiesti

Per ottenere le autorizzazioni necessarie per ruotare le CA e le chiavi gestite dal cliente, chiedi all'amministratore di concederti i seguenti ruoli IAM:

Gestisci le chiavi o le versioni delle chiavi: Cloud KMS Admin (roles/cloudkms.admin) sul progetto delle chiavi
Gestisci le CA root: CA Service Admin (roles/privateca.admin) sul tuo progetto chiave
Configura i cluster in modo che utilizzino le nuove credenziali: Kubernetes Engine Cluster Admin (roles/container.clusterAdmin) nel progetto del cluster

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Limitazioni

Le chiavi Cloud KMS asimmetriche che utilizzi per la firma e la verifica dei account di servizio non supportano la rotazione automatica delle chiavi.

Ruota le chiavi di firma e verifica del account di servizio

Quando configuri GKE control plane authority, aggiungi al cluster una chiave di firma del service account e chiavi di verifica del account di servizio. GKE utilizza queste chiavi per firmare e convalidare i token di connessione per i ServiceAccount Kubernetes. Durante una rotazione, aggiungi la nuova chiave all'elenco delle chiavi di verifica del account di servizio, attendi la propagazione delle modifiche e poi sostituisci la chiave di firma del account di servizio con la nuova chiave.

Per ruotare le chiavi del account di servizio, segui questi passaggi:

Recupera il nome completo della risorsa della versione della chiave originale della chiave di firma del service account:
```
gcloud container clusters describe CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del tuo cluster.
- CONTROL_PLANE_LOCATION: la località del cluster.
- CLUSTER_PROJECT_ID: l'ID progetto del progetto del cluster.
L'output è simile al seguente:
```
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION
```
In questo output, SIGNING_KEY_NAME è il nome della chiave e ORIGINAL_SIGNING_KEY_VERSION è il numero della versione della chiave di firma originale.
Crea una nuova versione della chiave di firma del account di servizio:
```
gcloud kms keys versions create \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
Sostituisci quanto segue:
- SIGNING_KEY_NAME: il nome della chiave di firma del service account.
- KEYRING_NAME: il nome delle chiavi automatizzate che contengono la chiave.
- CONTROL_PLANE_LOCATION: la Google Cloud posizione delle chiavi automatizzate.
- KEY_PROJECT_ID: l'ID progetto del tuo progetto chiave.

Recupera il nome completo della risorsa della nuova versione della chiave:

gcloud kms keys versions list \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

L'output è simile al seguente:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION

In questo output, SIGNING_KEY_NAME è il nome della chiave e NEW_SIGNING_KEY_VERSION è il numero della nuova versione della chiave di firma.

Aggiungi la nuova versione della chiave all'insieme di chiavi di verifica del account di servizio per il cluster:
```
gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH
```
Sostituisci quanto segue:
- ORIGINAL_KEY_VERSION_PATH: il nome completo della risorsa della versione della chiave di firma originale dall'output del primo passaggio di questa sezione. Ad esempio, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1.
- NEW_KEY_VERSION_PATH: il nome completo della risorsa della nuova versione della chiave di firma dall'output del passaggio precedente. Ad esempio, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.
Al termine dell'operazione di aggiornamento del cluster, potrebbero essere necessari fino a 10 minuti prima che il nuovo percorso della versione della chiave venga propagato al server API Kubernetes e a ogni endpoint API GKE.

Per verificare che il percorso della nuova versione della chiave sia stato propagato completamente, segui questi passaggi:

Ottieni il componente pubblico delle chiavi di firma del cluster dall'API GKE come set di chiavi web JSON (JWKS):

curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks

L'output è simile al seguente:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

Questo output deve contenere due voci di chiave, il che indica che entrambe le versioni della chiave sono disponibili nell'API GKE. Se vedi una sola voce della chiave, attendi 10 minuti e riprova a eseguire il comando.

Connettiti al cluster per poter eseguire i comandi kubectl:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Recupera il componente pubblico delle chiavi di firma del cluster dal server API Kubernetes come JWKS:

kubectl get --raw /openid/v1/jwks | jq

L'output è simile al seguente:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

Questo output deve contenere due voci di chiave, il che indica che entrambe le versioni della chiave sono disponibili nel server API Kubernetes. Se vedi una sola voce della chiave, attendi 10 minuti e riprova a eseguire il comando.

Aggiorna il cluster in modo che utilizzi la nuova versione della chiave come chiave di firma del account di servizio:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-signing-keys=NEW_KEY_VERSION_PATH

Verifica che i nuovi token del account di servizio utilizzino la nuova versione della chiave:

Crea un ServiceAccount:

kubectl create serviceaccount test-sa-1

Crea un token per il ServiceAccount:
```
kubectl create token test-sa-1
```

Estrai un digest firmato di recente da Logging:

export SIGNED_DIGEST=$(gcloud logging read \
    'resource.type="gke_cluster"
    AND resource.labels.cluster_name="CLUSTER_NAME"
    AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT"
    AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \
    --freshness=1h \
    --bucket=_Required \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.metadata.toBeSignedDigest)")

Verifica che la nuova versione della chiave di firma sia in uso:

gcloud logging read \
    'resource.type="cloudkms_cryptokeyversion" 
    AND protoPayload.methodName="AsymmetricSign"
    AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \
    --freshness=1h \
    --bucket=_Default \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.resourceName)"

L'output è il percorso della risorsa della nuova versione della chiave di firma.

Attendi la scadenza di ogni token nel cluster che utilizza la versione originale della chiave di firma del account di servizio. Per impostazione predefinita, la durata del token è di un'ora, con un massimo configurabile di 24 ore. Per controllare la durata del token configurata nel cluster, esegui questo comando:
```
kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1
```
Nota: se memorizzi i token ServiceAccount in Secret, ricrea i Secret in modo che Kubernetes generi nuovi token firmati dalla nuova versione della chiave.
Attendi che trascorra la durata del token configurata nell'output del passaggio precedente. Trascorso questo periodo di tempo, tutti i token associati nel tuo cluster utilizzano la nuova versione della chiave di firma del account di servizio.

Rimuovi la versione della chiave originale dall'elenco delle chiavi di verifica per il cluster:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=NEW_KEY_VERSION_PATH

(Facoltativo) Disattiva la versione della chiave originale. Dopo aver verificato che la versione della chiave originale non è in uso e che il cluster è integro, elimina la versione della chiave.

A meno che tu non stia ruotando le chiavi in risposta a un evento critico, ti consigliamo di attendere alcuni giorni prima di eliminare la versione originale della chiave. Per saperne di più, consulta Elimina e ripristina le versioni delle chiavi.

Dopo aver completato questi passaggi, ogni token account di servizio nuovo ed esistente nel tuo cluster viene firmato dalla nuova versione della chiave. Il server API rifiuta qualsiasi richiesta che utilizza un token di connessione con la versione della chiave originale, perché questa versione non esiste nella configurazione del cluster.

Ruota le CA GKE control plane authority

Le sezioni seguenti mostrano come ruotare le CA root utilizzate dal cluster per GKE control plane authority.

Crea nuove versioni delle chiavi per le CA

Crea una nuova versione della chiave per la chiave della CA root del cluster:
```
gcloud kms keys versions create \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
Sostituisci quanto segue:
- CLUSTER_CA_KEY_NAME: il nome della chiave della CA radice del cluster.
- KEYRING_NAME: il nome delle chiavi automatizzate che contengono la chiave.
- CONTROL_PLANE_LOCATION: la Google Cloud posizione delle chiavi automatizzate. Questa è la stessa località del cluster.
- KEY_PROJECT_ID: l'ID progetto del tuo progetto chiave.

Crea una nuova versione della chiave per la chiave della CA root di aggregazione:

gcloud kms keys versions create \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci AGGREGATION_CA_KEY_NAME con il nome della chiave CA root di aggregazione per il cluster.

Crea una nuova versione della chiave per la chiave CA root dell'API etcd:

gcloud kms keys versions create \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci ETCD_API_CA_KEY_NAME con il nome della chiave della CA root dell'API etcd per il cluster.

Crea una nuova versione della chiave per la chiave CA root peer etcd:

gcloud kms keys versions create \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci ETCD_PEER_CA_KEY_NAME con il nome della chiave della CA radice peer etcd per il cluster.

Crea nuove CA root

Ottieni il nome completo della risorsa della nuova versione della chiave della CA root del cluster:

gcloud kms keys versions list \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

L'output è simile al seguente:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION

In questo output, VERSION è il numero della nuova versione della chiave.

Crea una nuova CA radice del cluster nel pool di CA del cluster:
```
gcloud privateca roots create CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=CLUSTER_CA_KEY_PATH \
    --subject="CN=cluster-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Sostituisci quanto segue:
- CLUSTER_ROOT_CA_NAME: un nome per la nuova CA radice.
- CLUSTER_CA_POOL_NAME: il nome del pool di CA del cluster.
- CLUSTER_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.
- ORGANIZATION: il nome della tua organizzazione.

Ottieni il nome completo della risorsa della nuova versione della chiave della CA principale di aggregazione:

gcloud kms keys versions list \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

L'output è simile al seguente:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION

Crea una nuova CA radice di aggregazione nel pool di CA di aggregazione:
```
gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=AGGREGATION_CA_KEY_PATH \
    --subject="CN=aggregation-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Sostituisci quanto segue:
- AGGREGATION_ROOT_CA_NAME: un nome per la nuova CA radice di aggregazione.
- AGGREGATION_CA_POOL_NAME: il nome del pool CA di aggregazione.
- AGGREGATION_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.

Ottieni il nome completo della risorsa della nuova versione della chiave della CA root dell'API etcd:

gcloud kms keys versions list \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

L'output è simile al seguente:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSION

Crea una nuova CA root dell'API etcd nel pool di CA dell'API etcd:
```
gcloud privateca roots create ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_API_CA_KEY_PATH \
    --subject="CN=etcd-api-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Sostituisci quanto segue:
- ETCD_API_ROOT_CA_NAME: un nome per la nuova CA root dell'API etcd.
- ETCD_API_CA_POOL_NAME: il nome del pool di CA dell'API etcd.
- ETCD_API_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.

Ottieni il nome completo della risorsa della nuova versione della chiave della CA root peer etcd:

gcloud kms keys versions list \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

L'output è simile al seguente:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSION

Crea una nuova CA radice peer etcd nel pool CA peer etcd:
```
gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_PEER_CA_KEY_PATH \
    --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Sostituisci quanto segue:
- ETCD_PEER_ROOT_CA_NAME: un nome per la nuova CA radice peer etcd.
- ETCD_PEER_CA_POOL_NAME: il nome del pool CA peer etcd.
- ETCD_PEER_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.
Prima di continuare, propaga le modifiche alla CA root al bundle di attendibilità del cluster seguendo le istruzioni riportate nella sezione Riavvia il control plane e i nodi.

Sostituisci le CA principali originali con le nuove CA principali

Dopo aver riavviato il control plane e i nodi, segui questi passaggi:

Attiva la CA root del nuovo cluster:

gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Attiva la nuova CA root di aggregazione:

gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Abilita la nuova CA root dell'API etcd:

gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Attiva la nuova CA root peer etcd:

gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Disattiva la CA root del cluster originale:

gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci ORIGINAL_CLUSTER_ROOT_CA con il nome della CA principale del cluster originale di cui stai eseguendo la rotazione.

Disattiva la CA radice di aggregazione originale:

gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci ORIGINAL_AGGREGATION_ROOT_CA con il nome della CA root di aggregazione originale di cui stai eseguendo la rotazione.

Disabilita la CA root dell'API etcd originale:

gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci ORIGINAL_ETCD_API_ROOT_CA con il nome della CA root dell'API etcd originale di cui stai eseguendo la rotazione.

Disattiva la CA root peer etcd originale:

gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Sostituisci ORIGINAL_ETCD_PEER_ROOT_CA con il nome della CA root peer etcd originale di cui stai eseguendo la rotazione.

A questo punto, le nuove CA principali emettono tutti i nuovi certificati nel cluster. Per emettere nuovi certificati per kubelet su ogni nodo, riavvia il control plane e i nodi. Questo passaggio è necessario perché i certificati kubelet hanno una durata prolungata.

Dopo diversi giorni in cui il cluster rimane in uno stato integro, puoi eliminare le CA root originali, come descritto nella sezione successiva.

Elimina le CA radice originali

Questa sezione mostra come eliminare le CA root originali. Prima di seguire questi passaggi, verifica quanto segue:

Il cluster è rimasto in uno stato integro per diversi giorni dopo la sostituzione delle CA radice originali con quelle nuove.
Hai sostituito tutti i certificati emessi dalle CA radice originali con nuovi certificati.

Per eliminare le CA root originali, utilizza il comando gcloud privateca roots delete, come descritto nei passaggi seguenti. In questi comandi, il flag --ignore-active-certificates elimina la CA dopo un periodo di tolleranza, anche se la CA ha certificati non revocati o non scaduti.

Elimina la CA root del cluster originale:

gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Sostituisci ORIGINAL_CLUSTER_ROOT_CA con il nome della CA principale del cluster originale di cui stai eseguendo la rotazione.

Elimina la CA radice di aggregazione originale:

gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Sostituisci ORIGINAL_AGGREGATION_ROOT_CA con il nome della CA root di aggregazione originale di cui stai eseguendo la rotazione.

Elimina la CA root dell'API etcd originale:

gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Sostituisci ORIGINAL_ETCD_API_ROOT_CA con il nome della CA root dell'API etcd originale di cui stai eseguendo la rotazione.

Elimina la CA root peer etcd originale:

gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Sostituisci ORIGINAL_ETCD_PEER_ROOT_CA con il nome della CA root peer etcd originale di cui stai eseguendo la rotazione.

(Facoltativo) Propaga le modifiche alle CA root al bundle di attendibilità del cluster. Per istruzioni, consulta la sezione Riavvia il control plane e i nodi. Se salti questo passaggio, le CA radice originali vengono rimosse durante il successivo upgrade della versione del control plane e dei nodi.

Riavvia il control plane e i nodi

Quando apporti modifiche alla configurazione della CA root del cluster, ad esempio abilitando le CA root, disabilitandole o revocando i certificati, devi propagare queste modifiche al trust bundle del cluster. Per propagare le modifiche al trust bundle per il cluster, devi riavviare il control plane e (in alcuni scenari) i nodi.

Esegui l'upgrade del control plane del cluster alla stessa versione che utilizza già.

Attenzione: nei cluster di zona, il control plane non è disponibile fino al completamento dell'operazione di upgrade. Nei cluster Autopilot e nei cluster Standard regionali, il control plane rimane disponibile.
1. Trova la versione di GKE già utilizzata dal control plane:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"
```
  Sostituisci quanto segue:
  - CLUSTER_NAME: il nome del tuo cluster GKE.
  - CLUSTER_VERSION: la versione di GKE già in esecuzione nel cluster.
  - CLUSTER_PROJECT_ID: l'ID progetto del tuo progetto cluster.
2. Esegui l'upgrade del control plane:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```
Solo per la rotazione della CA radice del cluster, attiva la nuova creazione dei nodi eseguendo l'upgrade di ogni node pool alla stessa versione già in uso.

Attenzione: GKE inizia immediatamente a ricreare i nodi per questa modifica utilizzando la strategia di upgrade dei nodi, indipendentemente dalle policy di manutenzione attive. GKE dipende dalla disponibilità delle risorse per la modifica. La disabilitazione degli upgrade automatici dei nodi non impedisce questa modifica. Prima di avviare questa modifica, prepara i workload eseguiti sui nodi per l'interruzione.
1. Trova la versione di GKE utilizzata dal pool di nodi:
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(version)"
```
  Sostituisci NODE_POOL_NAME con il nome del node pool di cui eseguire l'upgrade.
2. Esegui l'upgrade del pool di nodi:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```
Al termine dell'upgrade del control plane e dei nodi, aggiorna tutti i client API Kubernetes, come l'interfaccia a riga di comando kubectl, per utilizzare il trust bundle aggiornato. Se generi manualmente i certificati utilizzando le CertificateSigningRequest di Kubernetes, emetti nuovamente tutti i certificati e fornisci i nuovi certificati ai client API.

Se hai eseguito i passaggi descritti in questa sezione durante una rotazione delle CA, vai alla fase successiva della rotazione, che corrisponde a una delle seguenti sezioni di questo documento:

Sostituisci le CA root originali con le nuove CA root.
Elimina le CA root originali.

Ruotare le CA e le chiavi del piano di controllo gestito dal cliente Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Pianifica le rotazioni delle credenziali

Prima di iniziare

Ruoli e autorizzazioni richiesti

Limitazioni

Ruota le chiavi di firma e verifica del account di servizio

Ruota le CA GKE control plane authority

Crea nuove versioni delle chiavi per le CA

Crea nuove CA root

Sostituisci le CA principali originali con le nuove CA principali

Elimina le CA radice originali

Riavvia il control plane e i nodi

Passaggi successivi

Ruotare le CA e le chiavi del piano di controllo gestito dal cliente