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

Cette page explique aux administrateurs de cluster et aux ingénieurs en sécurité comment alterner les autorités de certification (CA) et les clés de signature de compte de service que vous avez configurées pour l'autorité du plan de contrôle GKE.

Vous devez connaître les concepts suivants :

Planifier les rotations d'identifiants

Cette page vous explique comment faire pivoter les composants d'identifiants suivants dans votre plan de contrôle :

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

Vous pouvez également faire pivoter les clés de chiffrement gérées par le client que vous avez utilisées pour chiffrer vos disques de démarrage du plan de contrôle, vos disques etcd, ainsi que la sauvegarde interne etcd que Google Cloud utilise pour la reprise après sinistre. Pour en savoir plus, consultez Faire pivoter les 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, pour limiter les risques de compromission des versions de clé et dans le cadre des pratiques de sécurité de votre organisation. Pour planifier la fréquence de rotation de ressources spécifiques de l'autorité du plan de contrôle GKE, tenez compte des points suivants :

  • Par défaut, les certificats GKE signés par les CA 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 a des exigences en la matière. 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
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

  • Vous disposez d'un cluster existant qui utilise des CA autogérées et des clés de compte de service.

  • Identifiez les ID de projet des projets suivants : Google Cloud

    • 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 sur cette page, 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 requis

Pour obtenir les autorisations nécessaires pour faire pivoter vos clés et CA gérés 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.

Alterner les clés de signature et de validation du compte de service

Lorsque vous configurez l'autorité du plan de contrôle GKE, 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 pour les comptes de service Kubernetes. Lors d'une rotation, vous ajoutez votre nouvelle clé à la liste des clés de validation du compte de service, attendez que les modifications se propagent, puis 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 de ressource complet de la version 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 du 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 d'origine de la clé de signature.

  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 projet 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 des 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 à partir de la sortie 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 à partir de la sortie 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 à la version de la clé au serveur d'API Kubernetes et à chaque point de terminaison de l'API GKE peut prendre jusqu'à 10 minutes.

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

    1. Obtenez 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 et réessayez la commande.

    2. Connectez-vous au cluster pour pouvoir exécuter les 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 dans le serveur d'API Kubernetes. Si vous ne voyez qu'une seule entrée de clé, attendez 10 minutes et réessayez 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-key=NEW_KEY_VERSION_PATH

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

    1. Créez un compte de service :

      kubectl create serviceaccount test-sa-1

    2. Créez un jeton pour le ServiceAccount :

      kubectl create token test-sa-1

    3. Extrayez un résumé signé récemment à partir 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)")
      1. 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)"
  ```
The output is the resource path of the new signing key version.

  8. Attendez que tous les jetons du cluster qui utilisent la version de clé de signature du compte de service d'origine expirent. Par défaut, la durée de vie du jeton est d'une heure, avec une durée maximale 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 la sortie de l'étape précédente soit écoulée. Une fois ce délai écoulé, tous les jetons liés de votre cluster utiliseront 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 sain, 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 d'origine de la clé. Pour en savoir plus, consultez Détruire et restaurer des versions de clé.

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

Faire tourner les CA de l'autorité du plan de contrôle GKE

Les sections suivantes vous montrent comment faire pivoter les CA racines que le cluster utilise pour l'autorité du plan de contrôle GKE.

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é de l'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 projet de votre projet de clé.

  2. Créez une version de clé pour la clé de l'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é de l'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 la 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 racine

  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é de certification du cluster.
    • CLUSTER_CA_KEY_PATH : nom complet de la ressource de la nouvelle version de clé à partir de la sortie de l'étape précédente.
    • ORGANIZATION : nom de votre organisation.

  3. Obtenez le nom complet de la ressource de la nouvelle version de 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é à partir de la sortie 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é à partir de la sortie de l'étape précédente.

  7. Obtenez le nom complet de la ressource de la nouvelle version de 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 homologue etcd dans le pool d'autorités de certification homologues 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 homologue etcd.
    • ETCD_PEER_CA_POOL_NAME : nom du pool d'autorités de certification homologues etcd.
    • ETCD_PEER_CA_KEY_PATH : nom complet de la ressource de la nouvelle version de clé à partir de la sortie de l'étape précédente.

  9. Avant de continuer, propagez les modifications apportées à 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.

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

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

  1. Activez la nouvelle autorité de certification racine du 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 faites pivoter.

  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 faites pivoter.

  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 faites pivoter.

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

    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 des pairs etcd d'origine que vous faites pivoter.

  9. À ce stade, les nouvelles autorités de certification racine émettent tous les nouveaux certificats du 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 obligatoire, car les certificats kubelet ont une longue durée de vie.

Si le cluster reste sain pendant plusieurs jours, vous pouvez supprimer les autorités de certification racine d'origine, comme décrit dans la section suivante.

Supprimer les CA racines d'origine

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

  • Le cluster est resté en bon état pendant plusieurs jours après que vous avez remplacé les CA racine d'origine par les nouveaux CA racine.
  • Vous avez remplacé tous les certificats émis par les autorités de certification racine d'origine par de nouveaux certificats.

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

  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 faites pivoter.

  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 faites pivoter.

  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 faites pivoter.

  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 des pairs etcd d'origine que vous faites pivoter.

  5. Facultatif : Propagez les modifications apportées aux CA racine 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 CA racines d'origine seront 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 déjà utilisée par le plan de contrôle :

      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 déjà exécutée par le cluster.
      • CLUSTER_PROJECT_ID : ID de projet 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. Si vous générez manuellement des certificats à l'aide de Kubernetes CertificateSigningRequests, réémettez tous ces certificats et fournissez les nouveaux certificats aux clients de l'API.

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

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

Étapes suivantes