Faire tourner les clés et les autorités de certification du plan de contrôle géré par le client

.

Cette page explique aux administrateurs de cluster et aux ingénieurs de sécurité comment effectuer la rotation des autorités de certification (CA) et des clés de signature de compte de service que vous avez configurées pour GKE control plane authority.

Vous devez connaître les concepts suivants :

Planifier les rotations d'identifiants

Ce document vous explique comment effectuer la rotation des composants d'identifiants suivants dans votre plan de contrôle :

  • L'autorité de certification racine du cluster, l'autorité de certification racine d'agrégation, l'autorité de certification racine de l'API etcd et l'autorité de certification racine du pair etcd.
  • Les clés de signature et de validation du ServiceAccount Kubernetes.

Vous pouvez également effectuer la rotation des clés de chiffrement gérées par le client que vous avez utilisées pour chiffrer les disques de démarrage de votre plan de contrôle, les disques etcd et la sauvegarde interne etcd utilisée par Google Cloud pour la reprise après sinistre. Pour en savoir plus, consultez Effectuer une rotation des clés de chiffrement du disque de démarrage etcd et du plan de contrôle.

Effectuez une rotation de vos identifiants pour éviter l'expiration de l'autorité de certification, limiter les compromissions de versions de clés et respecter les pratiques de sécurité de votre organisation. Pour planifier la fréquence de rotation de ressources GKE control plane authority spécifiques, tenez compte des points suivants :

  • Par défaut, les certificats GKE signés par les autorités de certification racines dans Certificate Authority Service (CA Service) expirent un an après leur date de création.
  • Les clés de Cloud Key Management Service (Cloud KMS) n'expirent pas. N'effectuez une rotation manuelle des clés que si votre organisation l'exige. Pour minimiser les perturbations des charges de travail en cours d'exécution, ne configurez pas la rotation automatique des clés pour ces clés.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Pour utiliser la Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Disposer d'un cluster existant qui utilise des clés de compte de service et des CA autogérées et qui exécute GKE 1.35.2-gke.1842000 ou une version ultérieure.

  • Identifiez les ID des projets Google Cloud suivants :

    • Projet de clé : projet contenant vos ressources Cloud KMS et CA Service.
    • Projet de cluster : projet contenant votre cluster GKE.

  • Pour effectuer les tâches de validation décrites dans ce document, vérifiez que les journaux d'audit des accès aux données suivants sont activés :

    • API Cloud Key Management Service (KMS) : DATA_READ
    • Certificate Authority Service : ADMIN_READ

    Pour activer ces types de journaux, consultez Activer les journaux d'audit des accès aux données.

Rôles et autorisations nécessaires

Pour obtenir les autorisations nécessaires pour effectuer la rotation de vos clés et de vos CA gérées par le client, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Limites

Les clés Cloud KMS asymétriques que vous utilisez pour la signature et la validation des comptes de service ne sont pas compatibles avec la rotation automatique des clés.

Effectuer une rotation des clés de signature et de validation du compte de service

Lorsque vous configurez GKE control plane authority, vous ajoutez une clé de signature de compte de service et des clés de validation de compte de service à votre cluster. GKE utilise ces clés pour signer et valider les jetons de support des ServiceAccounts Kubernetes. Lors d'une rotation, vous ajoutez votre nouvelle clé à la liste des clés de validation du compte de service, vous attendez que les modifications se propagent, puis vous remplacez la clé de signature du compte de service par la nouvelle clé.

Pour effectuer la rotation des clés de compte de service, procédez comme suit :

  1. Obtenez le nom complet de la ressource de la version de clé d'origine de la clé de signature du compte de service :

    gcloud container clusters describe CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • CONTROL_PLANE_LOCATION : emplacement du cluster.
    • CLUSTER_PROJECT_ID : ID du projet de cluster.

    Le résultat ressemble à ce qui suit :

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

    Dans ce résultat, SIGNING_KEY_NAME est le nom de la clé et ORIGINAL_SIGNING_KEY_VERSION est le numéro de la version de la clé de signature d'origine.

  2. Créez une version de clé pour la clé de signature du compte de service :

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

    Remplacez les éléments suivants :

    • SIGNING_KEY_NAME : nom de la clé de signature du compte de service.
    • KEYRING_NAME : nom du trousseau de clés qui contient la clé.
    • CONTROL_PLANE_LOCATION : emplacement Google Cloud du trousseau de clés.
    • KEY_PROJECT_ID : ID de votre projet de clé.

  3. Obtenez le nom complet de la ressource de la nouvelle version de clé :

    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

    Le résultat ressemble à ce qui suit :

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

    Dans ce résultat, SIGNING_KEY_NAME est le nom de la clé et NEW_SIGNING_KEY_VERSION est le numéro de la nouvelle version de la clé de signature.

  4. Ajoutez la nouvelle version de clé à l'ensemble de clés de validation du compte de service pour le 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

    Remplacez les éléments suivants :

    • ORIGINAL_KEY_VERSION_PATH : nom complet de la ressource de la version de la clé de signature d'origine, obtenu à partir du résultat de la première étape de cette section. Exemple : projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1.
    • NEW_KEY_VERSION_PATH : nom complet de la ressource de la nouvelle version de la clé de signature, issu du résultat de l'étape précédente. Par exemple, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.

    Une fois l'opération de mise à jour du cluster terminée, la propagation du nouveau chemin d'accès de la version de clé vers le serveur d'API Kubernetes et chaque point de terminaison de l'API GKE peut prendre jusqu'à 10 minutes.

  5. Pour vérifier que le chemin d'accès à la nouvelle version de la clé est entièrement propagé, procédez comme suit :

    1. Récupérez le composant public des clés de signature du cluster à partir de l'API GKE en tant que jeu de clés Web JSON (JWKS) :

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

      Le résultat ressemble à ce qui suit :

      {
  "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"
    }
  ]
}

      Ce résultat doit comporter deux entrées de clé, ce qui indique que les deux versions de clé sont disponibles dans l'API GKE. Si vous ne voyez qu'une seule entrée de clé, attendez 10 minutes, puis réessayez d'exécuter la commande.

    2. Connectez-vous au cluster pour pouvoir exécuter des commandes kubectl :

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

    3. Récupérez le composant public des clés de signature du cluster à partir du serveur d'API Kubernetes en tant que JWKS :

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

      Le résultat ressemble à ce qui suit :

      {
  "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"
    }
  ]
}

      Ce résultat doit comporter deux entrées de clé, ce qui indique que les deux versions de clé sont disponibles sur le serveur d'API Kubernetes. Si vous ne voyez qu'une seule entrée de clé, attendez 10 minutes, puis réessayez d'exécuter la commande.

  6. Mettez à jour le cluster pour qu'il utilise la nouvelle version de clé comme clé de signature du compte de service :

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

  7. Vérifiez que les nouveaux jetons de compte de service utilisent la nouvelle version de la clé :

    1. Créez un ServiceAccount :

      kubectl create serviceaccount test-sa-1

    2. Créez un jeton pour le ServiceAccount :

      kubectl create token test-sa-1

    3. Extrayez un condensé récemment signé de 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)")

    4. Vérifiez que la nouvelle version de la clé de signature est utilisée :

      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)"

      Le résultat est le chemin d'accès de la ressource de la nouvelle version de clé de signature.

  8. Attendez que tous les jetons du cluster qui utilisent la version d'origine de la clé de signature du compte de service expirent. Par défaut, la durée de vie du jeton est d'une heure, avec un maximum configurable de 24 heures. Pour vérifier la durée de vie du jeton configurée dans votre cluster, exécutez la commande suivante :

    kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1

  9. Attendez que la durée de vie du jeton configurée dans le résultat de l'étape précédente soit écoulée. Une fois ce délai écoulé, tous les jetons liés de votre cluster utilisent la nouvelle version de la clé de signature du compte de service.

  10. Supprimez la version de clé d'origine de la liste des clés de validation du cluster :

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

  11. Facultatif : désactivez la version de clé d'origine. Après avoir vérifié que la version de clé d'origine n'est pas utilisée et que le cluster est opérationnel, détruisez la version de clé.

    Sauf si vous effectuez une rotation des clés en réponse à un événement critique, nous vous recommandons d'attendre quelques jours avant de détruire la version de clé d'origine. Pour en savoir plus, consultez la page Détruire et restaurer des versions de clé.

Une fois ces étapes terminées, chaque jeton de compte de service nouveau et existant dans votre cluster est signé par la nouvelle version de la clé. Le serveur d'API rejette toutes les requêtes qui utilisent un jeton de support avec la version de clé d'origine, car celle-ci n'existe pas dans la configuration du cluster.

Effectuer une rotation des CA de GKE control plane authority

Les sections suivantes vous expliquent comment effectuer la rotation des CA racines utilisées par le cluster pour GKE control plane authority.

Créer des versions de clé pour les autorités de certification

  1. Créez une version de clé pour la clé d'autorité de certification racine du cluster :

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

    Remplacez les éléments suivants :

    • CLUSTER_CA_KEY_NAME : nom de la clé d'autorité de certification racine du cluster.
    • KEYRING_NAME : nom du trousseau de clés qui contient la clé.
    • CONTROL_PLANE_LOCATION : emplacement Google Cloud du trousseau de clés. Il s'agit de l'emplacement de votre cluster.
    • KEY_PROJECT_ID : ID de votre projet de clé.

  2. Créez une version de clé pour la clé d'autorité de certification racine d'agrégation :

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

    Remplacez AGGREGATION_CA_KEY_NAME par le nom de la clé d'autorité de certification racine d'agrégation pour le cluster.

  3. Créez une version de clé pour la clé de l'autorité de certification racine de l'API etcd :

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

    Remplacez ETCD_API_CA_KEY_NAME par le nom de la clé de l'autorité de certification racine de l'API etcd pour le cluster.

  4. Créez une version de clé pour la clé d'autorité de certification racine du pair etcd :

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

    Remplacez ETCD_PEER_CA_KEY_NAME par le nom de la clé de l'autorité de certification racine du pair etcd pour le cluster.

Créer des autorités de certification racines

  1. Obtenez le nom complet de la ressource de la nouvelle version de la clé de l'autorité de certification racine du 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

    Le résultat ressemble à ce qui suit :

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

    Dans ce résultat, VERSION correspond au numéro de la nouvelle version de la clé.

  2. Créez une autorité de certification racine de cluster dans le pool d'autorités de certification du 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

    Remplacez les éléments suivants :

    • CLUSTER_ROOT_CA_NAME : nom de votre nouvelle autorité de certification racine.
    • CLUSTER_CA_POOL_NAME : nom du pool d'autorités de certification du cluster.
    • CLUSTER_CA_KEY_PATH : nom complet de la ressource de la nouvelle version de clé, issu du résultat de l'étape précédente.
    • ORGANIZATION : nom de votre organisation.

  3. Obtenez le nom complet de la ressource de la nouvelle version de la clé de l'autorité de certification racine d'agrégation :

    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

    Le résultat ressemble à ce qui suit :

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

  4. Créez une autorité de certification racine d'agrégation dans le pool d'autorités de certification d'agrégation :

    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

    Remplacez les éléments suivants :

    • AGGREGATION_ROOT_CA_NAME : nom de votre nouvelle autorité de certification racine d'agrégation.
    • AGGREGATION_CA_POOL_NAME : nom du pool d'autorités de certification d'agrégation.
    • AGGREGATION_CA_KEY_PATH : nom complet de la ressource de la nouvelle version de clé, issu du résultat de l'étape précédente.

  5. Obtenez le nom complet de la ressource de la nouvelle version de la clé de l'autorité de certification racine de l'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

    Le résultat ressemble à ce qui suit :

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

  6. Créez une autorité de certification racine de l'API etcd dans le pool d'autorités de certification de l'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

    Remplacez les éléments suivants :

    • ETCD_API_ROOT_CA_NAME : nom de votre nouvelle autorité de certification racine de l'API etcd.
    • ETCD_API_CA_POOL_NAME : nom du pool d'autorités de certification de l'API etcd.
    • ETCD_API_CA_KEY_PATH : nom complet de la ressource de la nouvelle version de clé, issu du résultat de l'étape précédente.

  7. Obtenez le nom complet de la ressource de la nouvelle version de la clé de l'autorité de certification racine du pair 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

    Le résultat ressemble à ce qui suit :

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

  8. Créez une autorité de certification racine de pairs etcd dans le pool d'autorités de certification de pairs 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

    Remplacez les éléments suivants :

    • ETCD_PEER_ROOT_CA_NAME : nom de votre nouvelle autorité de certification racine de pairs etcd.
    • ETCD_PEER_CA_POOL_NAME : nom du pool d'autorités de certification de pairs etcd.
    • ETCD_PEER_CA_KEY_PATH : nom complet de la ressource de la nouvelle version de clé, issu du résultat de l'étape précédente.

  9. Avant de continuer, propagez les modifications de l'autorité de certification racine au bundle de confiance du cluster en suivant les instructions de la section Redémarrer le plan de contrôle et les nœuds.

Remplacer les autorités de certification racine d'origine par les nouvelles autorités de certification racine

Après avoir redémarré le plan de contrôle et les nœuds, procédez comme suit :

  1. Activez l'autorité de certification racine du nouveau cluster :

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

  2. Activez la nouvelle autorité de certification racine d'agrégation :

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

  3. Activez la nouvelle autorité de certification racine de l'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. Activez la nouvelle autorité de certification racine du pair 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. Désactivez l'autorité de certification racine du cluster d'origine :

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

    Remplacez ORIGINAL_CLUSTER_ROOT_CA par le nom de l'autorité de certification racine du cluster d'origine que vous souhaitez remplacer.

  6. Désactivez l'autorité de certification racine d'agrégation d'origine :

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

    Remplacez ORIGINAL_AGGREGATION_ROOT_CA par le nom de l'autorité de certification racine d'agrégation d'origine que vous souhaitez remplacer.

  7. Désactivez l'autorité de certification racine de l'API etcd d'origine :

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

    Remplacez ORIGINAL_ETCD_API_ROOT_CA par le nom de l'autorité de certification racine de l'API etcd d'origine que vous souhaitez remplacer.

  8. Désactivez l'autorité de certification racine d'origine du pair etcd :

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

    Remplacez ORIGINAL_ETCD_PEER_ROOT_CA par le nom de l'autorité de certification racine d'homologue etcd d'origine que vous souhaitez remplacer.

  9. À ce stade, les nouvelles autorités de certification racine émettent tous les nouveaux certificats dans le cluster. Pour émettre de nouveaux certificats pour kubelet sur chaque nœud, redémarrez le plan de contrôle et les nœuds. Cette étape est requise, car les certificats kubelet ont une longue durée de vie.

Après plusieurs jours pendant lesquels le cluster reste opérationnel, vous pouvez supprimer les autorités de certification racine d'origine, comme décrit dans la section suivante.

Supprimer les autorités de certification racine d'origine

Cette section explique comment supprimer vos CA racines d'origine. Avant de suivre ces étapes, vérifiez les points suivants :

  • Le cluster est resté opérationnel pendant plusieurs jours après le remplacement des autorités de certification racine d'origine par les nouvelles autorités de certification racine.
  • Vous avez remplacé tous les certificats émis par les autorités de certification racine d'origine par de nouveaux certificats.

Pour supprimer les autorités de certification racine d'origine, utilisez la commande gcloud privateca roots delete, comme décrit dans les étapes suivantes. Dans ces commandes, l'option --ignore-active-certificates supprime l'autorité de certification après un délai de grâce, même si elle possède des certificats non révoqués ou non arrivés à expiration.

  1. Supprimez l'autorité de certification racine du cluster d'origine :

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

    Remplacez ORIGINAL_CLUSTER_ROOT_CA par le nom de l'autorité de certification racine du cluster d'origine que vous souhaitez remplacer.

  2. Supprimez l'autorité de certification racine d'agrégation d'origine :

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

    Remplacez ORIGINAL_AGGREGATION_ROOT_CA par le nom de l'autorité de certification racine d'agrégation d'origine que vous souhaitez remplacer.

  3. Supprimez l'autorité de certification racine de l'API etcd d'origine :

    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

    Remplacez ORIGINAL_ETCD_API_ROOT_CA par le nom de l'autorité de certification racine de l'API etcd d'origine que vous souhaitez remplacer.

  4. Supprimez l'autorité de certification racine du pair etcd d'origine :

    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

    Remplacez ORIGINAL_ETCD_PEER_ROOT_CA par le nom de l'autorité de certification racine d'homologue etcd d'origine que vous souhaitez remplacer.

  5. Facultatif : Propager les modifications apportées aux CA racines au bundle de confiance du cluster. Pour obtenir des instructions, consultez la section Redémarrer le plan de contrôle et les nœuds. Si vous ignorez cette étape, les autorités de certification racine d'origine sont supprimées lors de la prochaine mise à niveau de la version du plan de contrôle et des nœuds.

Redémarrer le plan de contrôle et les nœuds

Lorsque vous modifiez la configuration de l'autorité de certification racine de votre cluster (par exemple, en activant ou en désactivant des autorités de certification racine, ou en révoquant des certificats), vous devez propager ces modifications au bundle de confiance du cluster. Pour propager les modifications apportées au bundle de confiance du cluster, vous devez redémarrer le plan de contrôle et (dans certains cas) les nœuds.

  1. Mettez à niveau le plan de contrôle du cluster vers la même version que celle qu'il utilise déjà.

    1. Recherchez la version de GKE que le plan de contrôle utilise déjà :

      gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"

      Remplacez les éléments suivants :

      • CLUSTER_NAME : nom de votre cluster GKE.
      • CLUSTER_VERSION : version de GKE que le cluster exécute déjà.
      • CLUSTER_PROJECT_ID : ID de votre projet de cluster.

    2. Mettez à niveau le plan de contrôle :

      gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID

  2. Pour la rotation de l'autorité de certification racine du cluster uniquement, déclenchez la recréation des nœuds en mettant à niveau chacun de vos pools de nœuds vers la version qu'ils utilisent déjà.

    1. Recherchez la version de GKE utilisée par le pool de nœuds :

      gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(version)"

      Remplacez NODE_POOL_NAME par le nom du pool de nœuds à mettre à niveau.

    2. Mettez à niveau le pool de nœuds :

      gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID

  3. Une fois la mise à niveau de votre plan de contrôle et de vos nœuds terminée, mettez à jour tous les clients API Kubernetes, tels que la CLI kubectl, pour qu'ils utilisent le bundle de confiance mis à jour. Si vous générez manuellement des certificats à l'aide de CertificateSigningRequests Kubernetes, émettez à nouveau tous ces certificats et fournissez les nouveaux certificats aux clients API.

Si vous avez suivi les étapes de cette section lors d'une rotation d'autorité de certification, passez à la phase suivante de la rotation, qui correspond à l'une des sections suivantes de ce document :

Étapes suivantes