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

.

Questa pagina mostra agli amministratori dei cluster e agli esperti di sicurezza come ruotare le autorità di certificazione (CA) e le chiavi di firma delaccount di serviziot che hai configurato per l'autorità del control plane GKE.

Devi avere familiarità con i seguenti concetti:

Pianificare le rotazioni delle credenziali

Questa pagina mostra come ruotare i seguenti componenti delle credenziali nel tuo 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 di 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 che Google Cloud utilizza per il ripristino di emergenza. Per saperne di più, vedi Ruotare le chiavi di crittografia del disco di avvio di etcd e del control plane.

Ruota le credenziali per evitare la scadenza della CA, per ridurre i rischi di compromissione della versione della chiave e nell'ambito delle pratiche di sicurezza della tua organizzazione. Per pianificare la frequenza con cui ruotare risorse specifiche dell'autorità del control plane GKE, considera quanto segue:

  • Per impostazione predefinita, i certificati GKE firmati dalle CA radice 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 carichi di lavoro in esecuzione, non configurare la rotazione automatica delle chiavi per queste chiavi.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

  • Avere un cluster esistente che utilizza CA autogestite e account di servizio account

  • Identifica gli ID progetto dei seguenti Google Cloud progetti:

    • Progetto delle chiavi: il progetto che contiene le risorse Cloud KMS e CA Service.
    • Progetto cluster: il progetto che contiene il cluster GKE.

  • Per eseguire le attività di convalida in questa pagina, verifica che siano attivati 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 Abilitare gli audit log di accesso ai dati.

Ruoli e autorizzazioni richiesti

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

Per ulteriori informazioni 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 asimmetriche Cloud KMS che utilizzi per la firma e la verifica dell'account di servizio non supportano la rotazione automatica delle chiavi.

Ruota le chiavi di firma e verifica del account di servizio

Quando configuri l'autorità del control plane GKE, aggiungi una chiave di firma dell'account di servizio e chiavi di verifica dell'account di servizio al cluster. GKE utilizza queste chiavi per firmare e convalidare i token di autenticazione per i service account Kubernetes. Durante una rotazione, aggiungi la nuova chiave all'elenco delle chiavi di verifica delaccount di serviziot, attendi la propagazione delle modifiche e poi sostituisci la chiave di firma deaccount di serviziont con la nuova chiave.

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

  1. Recupera il nome completo della risorsa della versione 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 posizione del cluster.
    • CLUSTER_PROJECT_ID: l'ID progetto del progetto 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.

  2. 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 dell'account di servizio.
    • 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.

  3. 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.

  4. 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.

  5. Per verificare che il nuovo percorso della versione della chiave sia completamente propagato, procedi nel seguente modo:

    1. 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 avere due voci di chiave, il che indica che entrambe le versioni della chiave sono disponibili nell'API GKE. Se vedi una sola voce di chiave, attendi 10 minuti e riprova a eseguire il comando.

    2. Connettiti al cluster per poter eseguire i comandi kubectl:

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

    3. Ottieni 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 chiave, il che indica che entrambe le versioni della chiave sono disponibili nel server API Kubernetes. Se vedi una sola voce di chiave, attendi 10 minuti e riprova a eseguire il comando.

  6. 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-key=NEW_KEY_VERSION_PATH

  7. Verifica che i nuovi token dell'account di servizio utilizzino la nuova versione della chiave:

    1. Crea un service account:

      kubectl create serviceaccount test-sa-1

    2. Crea un token per ServiceAccount:

      kubectl create token test-sa-1

    3. 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)")
      1. Verifica che sia in uso la nuova versione della chiave di firma:
        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)"
  ```
The output is the resource path of the new signing key version.

  8. Attendi la scadenza di ogni token nel cluster che utilizza la versione della chiave di firma del account di servizio originale. 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

  9. Attendi che trascorra la durata del token configurata dall'output del passaggio precedente. Al termine di questo periodo di tempo, tutti i token associati nel tuo cluster utilizzano la nuova versione della chiave di firma delaccount di serviziot.

  10. Rimuovi la versione originale della chiave 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

  11. (Facoltativo) Disabilita la versione originale della chiave. Dopo aver verificato che la versione della chiave originale non sia in uso e che il cluster sia 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 ulteriori informazioni, vedi Eliminare e ripristinare 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 autenticazione con la versione della chiave originale, perché la versione della chiave originale non esiste nella configurazione del cluster.

Ruotare le CA dell'autorità del control plane GKE

Le sezioni seguenti mostrano come ruotare le CA radice utilizzate dal cluster per l'autorità del control plane GKE.

Crea nuove versioni delle chiavi per le CA

  1. Crea una nuova versione della chiave per la chiave CA radice 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 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. Corrisponde alla posizione del cluster.
    • KEY_PROJECT_ID: l'ID progetto del tuo progetto chiave.

  2. Crea una nuova versione della chiave per la chiave della CA radice 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 radice di aggregazione per il cluster.

  3. Crea una nuova versione della chiave per la chiave CA radice 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 CA radice dell'API etcd per il cluster.

  4. Crea una nuova versione della chiave per la chiave CA radice 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 radice

  1. Recupera il nome completo della risorsa della nuova versione della chiave CA radice 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.

  2. 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.

  3. Ottieni il nome completo della risorsa della nuova versione della chiave CA radice 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

  4. 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 di CA di aggregazione.
    • AGGREGATION_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.

  5. Recupera il nome completo della risorsa della nuova versione della chiave CA radice 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

  6. Crea una nuova CA radice 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 radice dell'API etcd.
    • ETCD_API_CA_POOL_NAME: il nome del pool di CA API etcd.
    • ETCD_API_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.

  7. Recupera il nome completo della risorsa della nuova versione della chiave CA radice del 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

  8. Crea una nuova CA radice peer etcd nel pool di 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 di CA peer etcd.
    • ETCD_PEER_CA_KEY_PATH: il nome completo della risorsa della nuova versione della chiave dall'output del passaggio precedente.

  9. Prima di continuare, propaga le modifiche alla CA radice al bundle di attendibilità del cluster seguendo le istruzioni riportate nella sezione Riavvia il control plane e i nodi.

Sostituisci le CA radice originali con le nuove CA radice

Dopo aver riavviato il piano di controllo e i nodi, segui questi passaggi:

  1. Attiva la nuova CA radice del cluster:

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

  2. Attiva la nuova CA radice di aggregazione:

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

  3. Abilita la nuova CA radice 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

  4. Abilita la nuova CA radice 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

  5. Disabilita la CA radice 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 radice del cluster originale che stai ruotando.

  6. 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 radice di aggregazione originale che stai ruotando.

  7. Disabilita la CA radice 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 radice dell'API etcd originale che stai ruotando.

  8. Disattiva la CA radice 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 radice peer etcd originale che stai ruotando.

  9. A questo punto, le nuove CA radice emettono tutti i nuovi certificati nel cluster. Per emettere nuovi certificati per kubelet su ogni nodo, riavvia il piano di controllo e i nodi. Questo passaggio è obbligatorio perché i certificati kubelet hanno una lunga durata.

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

Elimina le CA radice originali

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

  • Il cluster è rimasto in stato integro per più giorni dopo la sostituzione delle CA radice originali con le nuove CA radice.
  • Hai sostituito tutti i certificati emessi dalle CA radice originali con nuovi certificati.

Per eliminare le CA radice 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.

  1. Elimina la CA radice 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 radice del cluster originale che stai ruotando.

  2. Elimina la CA principale 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 radice di aggregazione originale che stai ruotando.

  3. Elimina la CA radice 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 radice dell'API etcd originale che stai ruotando.

  4. Elimina la CA radice 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 radice peer etcd originale che stai ruotando.

  5. (Facoltativo) Propaga le modifiche alle CA radice al bundle di attendibilità del cluster. Per istruzioni, vedi la sezione Riavviare il control plane e i nodi. Se salti questo passaggio, le CA radice originali vengono rimosse durante l'upgrade successivo della versione del piano di controllo e del nodo.

Riavvia il control plane e i nodi

Quando apporti modifiche alla configurazione della CA radice del cluster, ad esempio l'attivazione, la disattivazione o la revoca dei certificati CA radice, devi propagare queste modifiche al bundle di attendibilità del cluster. Per propagare le modifiche al trust bundle per il cluster, riavvia il control plane e (in alcuni scenari) i nodi.

  1. Esegui l'upgrade del control plane del cluster alla stessa versione già in uso.

    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

  2. Se generi manualmente i certificati utilizzando le richieste di firma del certificato Kubernetes, riemettere tutti questi certificati e fornire i nuovi certificati ai client API.

  3. Solo per la rotazione della CA radice del cluster, attiva la ricreazione dei nodi eseguendo l'upgrade di ciascun node pool alla stessa versione che utilizza già.

    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 pool di nodi da aggiornare.

    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

Se hai eseguito i passaggi descritti in questa sezione durante una rotazione CA, procedi alla fase successiva della rotazione, che è una delle seguenti sezioni di questa pagina:

Passaggi successivi