Configurer l'authentification des identités de charge de travail gérées pour GKE

Ce document explique comment configurer les identités de charge de travail gérées pour Google Kubernetes Engine (GKE) dans vos clusters gérés par une flotte GKE. Il explique également comment déployer une charge de travail et vérifier son identité et son certificat.

Pour configurer et utiliser des identités de charge de travail gérées pour GKE, procédez comme suit :

  1. Choisissez une option d'autorité de certification (CA).

  2. Configurer votre autorité de certification

  3. Déployer des charges de travail avec des identités de charge de travail gérées

  4. Facultatif : Activer la fédération d'approbation entre les pools d'identités de charge de travail

Pool d'identités de charge de travail géré par Google

Lorsque vous ajoutez des clusters à des flottes GKE, GKE crée automatiquement un pool d'identités de charge de travail géré par Google, qui sert de racine de confiance, également appelée domaine de confiance SPIFFE pour vos charges de travail. Toutes les charges de travail du domaine de confiance reçoivent des certificats et des ancres de confiance qui permettent l'authentification par défaut au sein du domaine de confiance. Si vous avez plusieurs domaines approuvés, vous pouvez activer la fédération d'approbation entre eux pour permettre la communication entre les domaines approuvés.

Le pool d'identités de charge de travail géré par Google présente les caractéristiques suivantes :

  • Gestion des identités : Google gère entièrement le pool. Vous ne pouvez pas créer de sous-ressources, telles que des espaces de noms, des identités ou des fournisseurs d'identité.

  • Compatibilité avec les charges de travail : vous ne pouvez utiliser le pool que pour les charges de travail GKE. Vous ne pouvez pas ajouter d'autres types de charges de travail au pool, comme des VM Compute Engine.

  • Intégration du parc : tous les clusters du pool sont soumis au modèle standard d'uniformité des espaces de noms Kubernetes. Cela signifie que tous les clusters du pool disposent des mêmes droits d'accès et que les charges de travail de n'importe quel cluster du pool peuvent utiliser n'importe quelle identité de ce pool.

Pool d'identités de charge de travail autogéré

Dans les environnements à confiance mixte, tels que les parcs multilocataires, vous pouvez configurer un pool d'identités de charge de travail autogéré distinct pour un sous-ensemble de vos charges de travail et clusters. Un pool d'identités de charge de travail autogéré présente les caractéristiques suivantes :

  • Gestion des identités : en définissant votre propre pool d'identités de charge de travail, vous contrôlez entièrement la gestion des identités dans le pool. Sous le pool, vous pouvez définir votre propre hiérarchie d'identités, comme les espaces de noms et les identités. Vous pouvez définir des règles d'attestation pour spécifier les charges de travail qui peuvent attester des identités sous le pool ou les espaces de noms.

  • Charges de travail compatibles : toutes les charges de travail (par exemple, les VM, les conteneurs et les charges de travail sans serveur) peuvent être placées dans le pool.

  • Intégration des parcs : pour les charges de travail gérées par les parcs GKE, les parcs fournissent une interface intégrée pour gérer les identités. Vous pouvez configurer votre pool d'identités de charge de travail en tant que pool de locataires à portée du parc. Les parcs créent automatiquement des espaces de noms de pool d'identités de charge de travail correspondant aux espaces de noms de parc et attribuent des identités aux charges de travail.

Pour utiliser un pool d'identités de charge de travail autogéré, vous devez configurer les fonctionnalités de gestion des équipes de parc, telles que les champs d'application d'équipe et les espaces de noms de parc, et définir le pool autogéré comme pool de location de champ d'application. Pour savoir comment créer et configurer un pool autogéré, consultez S'authentifier auprès des API Google Cloud à partir de charges de travail de parc à confiance mixte.

Configuration multiprojets

Les ressourcesGoogle Cloud que vous utilisez dans ce document, telles que les clusters GKE, l'autorité de certification racine et les autorités de certification subordonnées, peuvent exister dans des projets distincts. Lorsque vous faites référence à ces ressources, utilisez le flag --project pour spécifier le projet approprié pour chaque ressource.

Avant de commencer

  1. Créez ou sélectionnez un projet Google Cloud .

    Rôles requis pour sélectionner ou créer un projet

    • Sélectionnez un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique. Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
    • Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.

    • Créez un projet Google Cloud  :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

    • Sélectionnez le projet Google Cloud que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre projet Google Cloud .

  2. Comprendre les identités de charge de travail gérées

  3. Assurez-vous que vos clusters exécutent la version 1.33.0-gke.2248000 ou ultérieure.

  4. Ajoutez vos clusters aux parcs GKE. Si votre cluster est un cluster Autopilot, omettez l'option --enable-workload-identity. Les parcs créent automatiquement un pool d'identités de charge de travail géré par Google, qui sert de domaine de confiance.

    Activez les parcs GKE en exécutant la commande suivante :

    gcloud container clusters update CLUSTER_NAME \
--workload-pool=PROJECT_ID.svc.id.goog \
--enable-fleet \
--fleet-project=PROJECT_ID

    Remplacez ces valeurs :

    • CLUSTER_NAME : nom du cluster GKE à enregistrer auprès du parc GKE
    • PROJECT_ID : ID du projet hôte du parc GKE

  5. Activez les API IAM et Certificate Authority Service.

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles.

    Activer les API

  6. Configurez Google Cloud CLI pour utiliser votre projet de facturation et de quota.

    gcloud config set billing/quota_project PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet de parc.

Rôles requis

Pour obtenir les autorisations nécessaires pour créer des identités de charge de travail gérées et provisionner des certificats d'identité de charge de travail gérés, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le projet :

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 avec des rôles personnalisés ou d'autres rôles prédéfinis.

Choisir une option d'autorité de certification

Pour signer vos certificats de charge de travail, choisissez l'option d'autorité de certification (CA) qui correspond le mieux à votre cas d'utilisation :

  • Autorité de certification par défaut gérée par Google : utilisez cette option pour une solution entièrement gérée et sans frais. L'autorité de certification par défaut fournit une racine de confiance partagée pour tous les utilisateursGoogle Cloud .

  • Autorité de certification personnalisée : utilisez cette option pour configurer votre propre infrastructure à clé publique (PKI) via Certificate Authority Service. Cette option est appropriée si vous avez besoin d'une racine de confiance personnalisée ou si vous devez stocker les clés de signature dans un module de sécurité matérielle (HSM) pour répondre aux exigences de conformité. Certificate Authority Service est facturé séparément de l'identité de charge de travail gérée. Pour en savoir plus, consultez la section Tarifs du service d'autorité de certification.

Configurer une autorité de certification

AC par défaut

Pour associer l'autorité de certification par défaut au pool d'identités de charge de travail, mettez à jour le pool d'identités de charge de travail avec l'indicateur use-default-shared-ca.

  gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
      --location="global" \
      --use-default-shared-ca \
      --project=PROJECT_ID

Remplacez les éléments suivants :

  • TRUST_DOMAIN_NAME :

    Nom du domaine d'approbation. Selon le type de pool, mettez en forme le nom comme suit :

    • Pool géré par Google : PROJECT_ID.svc.id.goog
    • Pool autogéré : POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
  • PROJECT_ID : ID du projet hôte de votre parc.

CA personnalisée

  1. Configurez le service d'autorité de certification pour émettre des certificats pour les identités de charge de travail gérées.
  2. Associez les CA au pool d'identités de charge de travail.
  3. Autorisez les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification.

Configurer le service d'autorité de certification pour émettre des certificats pour les identités de charge de travail gérées

Pour configurer des identités de charge de travail gérées pour GKE, vous devez d'abord configurer une autorité de certification (AC) et une ou plusieurs AC subordonnées. Cette configuration est appelée hiérarchie d'AC.

Vous pouvez utiliser des pools CA Service pour configurer cette hiérarchie. Avec cette hiérarchie, le pool d'autorités de certification subordonnées émet les certificats d'identité de charge de travail X.509 pour vos charges de travail.

Les pools d'autorités de certification configurés pour émettre des certificats pour les charges de travail à l'aide d'identités de charge de travail gérées doivent se trouver dans la même région que la charge de travail. Si vous souhaitez concevoir une architecture multirégionale pour la résilience aux pannes régionales, nous vous recommandons de configurer un pool d'AC Certificate Authority Service subordonné pour chaque région dans laquelle vous exécutez des charges de travail. Chacune de vos charges de travail peut ainsi référencer un pool d'autorités de certification Certificate Authority Service subordonné dans la région.

Configurer votre pool d'autorités de certification racine

Pour créer le pool de CA racine, procédez comme suit :

Créez le pool d'autorités de certification racine au niveau Enterprise à l'aide de gcloud privateca pools create. Ce niveau est conçu pour l'émission de certificats de longue durée, à faible volume.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

Remplacez les éléments suivants :

  • ROOT_CA_POOL_ID : ID unique pour le pool d'autorités de certification racine. L'ID peut comporter jusqu'à 64 caractères et ne doit contenir que des caractères alphanumériques minuscules et majuscules, des traits de soulignement ou des traits d'union. L'ID de pool doit être unique dans la région.

  • REGION : région où se trouve le pool d'autorités de certification racine.

  • CA_PROJECT_ID : ID du projet dans lequel vous souhaitez créer l'autorité de certification racine.

Pour en savoir plus sur les pools, les niveaux et les régions d'autorités de certification, consultez Créer des pools d'autorités de certification.

Configurer votre autorité de certification racine

Créez une autorité de certification racine dans le pool d'autorités de certification racine à l'aide de gcloud privateca roots create. Vous serez peut-être invité à activer l'autorité de certification racine s'il s'agit de la seule autorité de certification du pool d'autorités de certification racine.

Pour créer une autorité de certification racine, exécutez la commande suivante :

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

Remplacez les éléments suivants :

  • ROOT_CA_ID : nom unique de l'autorité de certification racine. Ce nom peut comporter jusqu'à 64 caractères et ne doit contenir que des caractères alphanumériques minuscules et majuscules, des traits de soulignement ou des traits d'union. Le nom de l'autorité de certification doit être unique dans la région.
  • ROOT_CA_POOL_ID : ID du pool d'autorités de certification racine.
  • ROOT_CA_CN : nom commun de l'autorité de certification racine.
  • ROOT_CA_ORGANIZATION : organisation de l'autorité de certification racine.
  • KEY_ALGORITHM : algorithme de la clé (par exemple, ec-p256-sha256).
  • REGION : région où se trouve le pool d'autorités de certification racine.
  • CA_PROJECT_ID : ID du projet dans lequel vous avez créé l'autorité de certification racine.

Pour en savoir plus sur les champs subject de l'autorité de certification, consultez la section Objet.

Vous pouvez également créer des autorités de certification racine supplémentaires dans votre pool d'autorités de certification racine. Cela peut être utile pour la rotation de l'autorité de certification racine.

Configurer les autorités de certification subordonnées

Vous pouvez également configurer des autorités de certification subordonnées. La configuration des autorités de certification subordonnées peut vous aider dans les cas suivants :

  • Plusieurs scénarios d'émission de certificats : si vous disposez de plusieurs scénarios d'émission de certificats, vous pouvez créer une autorité de certification subordonnée pour chacun d'entre eux.

  • Meilleur équilibrage de charge : l'ajout de plusieurs autorités de certification subordonnées dans un pool d'autorités de certification vous permet d'améliorer l'équilibrage de charge des requêtes de certificat.

Pour créer un pool d'autorités de certification subordonnées et une autorité de certification subordonnée, procédez comme suit :

  1. Créez le pool d'autorités de certification subordonnées au niveau DevOps, conçu pour l'émission de certificats de courte durée et à volume élevé.

    gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops

    Remplacez les éléments suivants :

    • SUBORDINATE_CA_POOL_ID : ID unique pour le pool d'autorités de certification subordonnée. L'ID peut comporter jusqu'à 64 caractères et ne doit contenir que des caractères alphanumériques minuscules et majuscules, des traits de soulignement ou des traits d'union. L'ID de pool doit être unique dans la région.
    • REGION : région dans laquelle créer le pool d'autorités de certification subordonné.
    • CA_PROJECT_ID : ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.

    Pour en savoir plus, consultez la section Créer des pools d'autorités de certification.

  2. Créez une autorité de certification subordonnée dans le pool d'autorités de certification subordonnées. Ne modifiez pas le mode d'émission basé sur la configuration par défaut.

    gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --issuer-pool=ROOT_CA_POOL_ID \
    --issuer-location=REGION \
    --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --use-preset-profile=subordinate_mtls_pathlen_0 \
    --project=CA_PROJECT_ID \
    --auto-enable

    Remplacez les éléments suivants :

    • SUBORDINATE_CA_ID : nom unique de l'autorité de certification subordonnée. Ce nom peut comporter jusqu'à 64 caractères et ne doit contenir que des minuscules et majuscules, des traits de soulignement ou des traits d'union. Le nom du pool doit être unique dans la région.
    • SUBORDINATE_CA_POOL_ID : nom du pool d'autorités de certification subordonnées.
    • REGION : région où se trouve le pool d'autorités de certification subordonné.
    • ROOT_CA_POOL_ID : ID du pool d'autorités de certification racine.
    • REGION : région du pool d'autorités de certification racine.
    • SUBORDINATE_CA_CN : nom commun de l'autorité de certification subordonnée.
    • SUBORDINATE_CA_ORGANIZATION : nom de l'organisation émettrice de l'autorité de certification subordonnée.
    • KEY_ALGORITHM : algorithme de la clé (par exemple, ec-p256-sha256).
    • CA_PROJECT_ID : ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.

    Pour en savoir plus sur les champs subject de l'autorité de certification, consultez la section Objet.

Créer un fichier de configuration d'émission de certificats

Pour associer des autorités de certification à des pools d'identités de charge de travail, vous devez disposer d'une configuration d'émission de certificats. Si vous avez besoin que vos charges de travail s'authentifient dans plusieurs domaines de confiance, consultez Activer la fédération d'approbation entre les pools d'identités de charge de travail (facultatif).

Pour configurer la configuration d'émission de certificats, vous devez créer un fichier de configuration d'émission de certificats nommé cic.json. Le format du fichier est semblable à ce qui suit :

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

Remplacez les éléments suivants :

  • REGION : régions où se trouvent les autorités de certification.

  • CA_PROJECT_NUMBER : numéro du projet dans lequel vous avez créé le pool d'autorités de certification subordonné. Pour obtenir le numéro de projet du projet CA_PROJECT_ID, exécutez la commande suivante :

    gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"

  • SUBORDINATE_CA_POOL_ID : nom du pool d'autorités de certification subordonnées.

  • ALGORITHM : facultatif. Algorithme de chiffrement utilisé pour générer la clé privée. Les valeurs valides sont ECDSA_P256, ECDSA_P384, RSA_2048, RSA_3072 et RSA_4096. Si aucune valeur n'est spécifiée, ECDSA_P256 est utilisé comme algorithme par défaut.

  • DURATION : facultatif. Durée de validité du certificat feuille, en secondes. La valeur doit être comprise entre 86 400 (1 jour) et 2 592 000 (30 jours). Si aucune valeur n'est spécifiée, la valeur par défaut de 86400 (1 jour) est utilisée. La validité réelle du certificat émis dépend également de l'autorité de certification émettrice, car elle peut restreindre la durée de vie de ce certificat.

  • ROTATION_WINDOW_PERCENTAGE : (facultatif) pourcentage de la durée de vie du certificat au cours duquel un renouvellement est déclenché. La valeur doit être comprise entre 50 et 80. Si aucune valeur n'est spécifiée, la valeur par défaut est 50.

Associer les CA au pool d'identités de charge de travail

Après avoir créé votre hiérarchie d'autorités de certification et des configurations d'émission de certificats pour chaque autorité de certification, vous associez les autorités de certification au pool d'identités de charge de travail. Pour associer une autorité de certification au pool d'identités de charge de travail, mettez à jour le pool d'identités de charge de travail avec la configuration d'émission de certificats de l'autorité de certification. Vous pouvez ensuite vérifier que le pool a été mis à jour.

Mettre à jour le pool d'identités de charge de travail

Pour mettre à jour le pool, exécutez la commande suivante :

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • TRUST_DOMAIN_NAME : nom du domaine approuvé. Selon le type de pool, mettez en forme le nom comme suit :

    • Pool géré par Google : PROJECT_ID.svc.id.goog
    • Pool autogéré : POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  • CIC_JSON_FILE_PATH : chemin d'accès au fichier de configuration de l'émission de certificats au format JSON (cic.json) que vous avez créé précédemment.

Vérifier que le pool d'identités de charge de travail a été mis à jour

Pour vérifier que votre pool d'identités de charge de travail a été mis à jour avec la configuration d'émission de certificats, exécutez la commande suivante :

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

Remplacez TRUST_DOMAIN_NAME par le nom de domaine approuvé que vous avez utilisé pour mettre à jour le pool d'identités de charge de travail plus haut dans ce document.

Le résultat ressemble à ce qui suit :

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
mode: TRUST_DOMAIN
name: TRUST_DOMAIN_NAME
state: ACTIVE

Si inlineCertificateIssuanceConfig ne figure pas dans le résultat de la commande, vérifiez que vous avez correctement configuré votre gcloud CLI afin d'utiliser le projet approprié pour la facturation et les quotas. Vous devrez peut-être passer à une version plus récente de gcloud CLI.

Autoriser les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification

Après avoir associé les autorités de certification au pool d'identités de charge de travail, autorisez les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification. Pour autoriser ces identités :

  1. Accordez le rôle IAM Demandeur de certificat de charge de travail du service CA (roles/privateca.workloadCertificateRequester) sur chaque pool d'autorités de certification subordonnées au domaine de confiance. La commande gcloud privateca pools add-iam-policy-binding suivante autorise le domaine de confiance à demander des certificats à partir des chaînes de certificats de CA Service.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.workloadCertificateRequester \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
    --project=CA_PROJECT_ID

    Remplacez les éléments suivants :

    • SUBORDINATE_CA_POOL_ID : ID du pool d'autorités de certification subordonnées.
    • REGION : région du pool d'autorités de certification subordonnées.

    • PROJECT_NUMBER : numéro du projet contenant le pool d'identités de charge de travail GKE

      Pour obtenir PROJECT_NUMBER à partir de votre projet de pool d'identités de charge de travail, exécutez la commande suivante.

      gcloud projects describe WORKLOAD_IDENTITY_POOL_PROJECT_ID --format="value(projectNumber)"

    • WORKLOAD_IDENTITY_POOL_PROJECT_ID : ID du projet contenant le pool d'identités de charge de travail.

    • TRUST_DOMAIN_NAME : nom du domaine approuvé. Selon le type de pool, mettez en forme le nom comme suit :

      • Pool géré par Google : PROJECT_ID.svc.id.goog
      • Pool autogéré : POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

    • CA_PROJECT_ID : ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.

  2. Accordez le rôle IAM Lecteur de pool du service d'autorités de certification (roles/privateca.poolReader) sur les pools d'autorités de certification subordonnés à l'identité de charge de travail gérée. Cela permet à l'identité de charge de travail gérée d'obtenir les certificats X.509 signés à partir des chaînes de certificats de l'autorité de certification.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.poolReader \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
    --project=CA_PROJECT_ID

    Remplacez les éléments suivants :

    • SUBORDINATE_CA_POOL_ID : ID du pool d'autorités de certification subordonnées.
    • REGION : région du pool d'autorités de certification subordonnées.
    • PROJECT_NUMBER : numéro de projet du projet contenant le pool d'identités de charge de travail GKE
    • TRUST_DOMAIN_NAME : nom du domaine approuvé. En fonction du type de pool, formatez le nom comme suit :
      • Pool géré par Google : PROJECT_ID.svc.id.goog
      • Pool autogéré : POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
    • CA_PROJECT_ID : ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.

Déployer des charges de travail avec des identités de charge de travail gérées

Une fois que vous avez configuré vos pools d'autorités de certification pour émettre des certificats pour les identités de charge de travail gérées, vous pouvez déployer des charges de travail qui possèdent des identités de charge de travail gérées.

Cette section explique comment déployer une charge de travail de test dotée d'une identité de charge de travail gérée. Pour ce faire, vous déployez un pod, vérifiez que des identifiants ont été générés, puis affichez le certificat et l'ID SPIFFE.

Déployer un pod

Vous pouvez déployer un pod qui obtient son identité de charge de travail gérée à partir d'un pool d'identités de charge de travail géré par Google ou d'un pool d'identités de charge de travail autogéré.

Pool géré par Google

Pour déployer un pod de test dans votre cluster, procédez comme suit :

  1. Obtenez les identifiants du cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  2. Créez l'espace de noms Kubernetes.

    kubectl create namespace KUBERNETES_NAMESPACE

  3. Déployez un PodSpec de test.

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/svc.id.goog
EOF

Pool autogéré

Pour déployer un pod de test dans votre cluster à l'aide d'un pool d'identités de charge de travail autogéré, procédez comme suit :

  1. Configurez un pool d'identités de charge de travail autogéré et configurez les clusters du parc pour qu'ils utilisent ce pool.

  2. Obtenez les identifiants du cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  3. Créez l'espace de noms Kubernetes.

    kubectl create namespace KUBERNETES_NAMESPACE

  4. Déployez un PodSpec de test.

    Le PodSpec suivant configure l'attribut de volume trustDomain pour un pool d'identités de charge de travail autogéré :

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/tenancy-scope
EOF

Lister les identifiants de charge de travail

Pour lister les identifiants de charge de travail, exécutez la commande suivante. La création des identifiants peut prendre quelques minutes.

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

Le résultat de la commande liste les fichiers suivants :

  • ca_certificates.pem : contient le certificat CA racine qui signe le certificat de charge de travail.
  • certificates.pem : contient le certificat X.509 de la charge de travail.
  • private_key.pem : contient la clé privée de la charge de travail.
  • trust_bundles.json : contient un mappage des domaines de confiance et des certificats d'autorité de certification à approuver pour la charge de travail donnée. Chaque entrée contient la chaîne du domaine de confiance en tant que clé, ainsi que les certificats CA correspondant à ce domaine de confiance.
  • credential-bundle.pem : contient la clé privée et le certificat concaténés, ce qui fournit un fichier unique pour les identifiants mTLS. Ce fichier n'est disponible que dans les versions de GKE ultérieures à 1.35.2-gke.1291000.

Afficher le certificat

Pour afficher le certificat, procédez comme suit :

  1. Exportez le certificat dans un fichier de certificat.

    kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile

  2. Affichez le fichier de certificat.

    cat certfile

    Dans le certificat, dans l'attribut X509v3 Subject Alternative Name, vous voyez l'ID SPIFFE, dont le format est semblable à ce qui suit selon le type de pool d'identités de charge de travail :

    • Pool géré par Google : spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default
    • Pool autogéré : spiffe://POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

    default fait référence au ServiceAccount Kubernetes par défaut.

Tester l'authentification de charge de travail à charge de travail

Pour tester l'authentification de charge de travail à charge de travail, consultez Tester l'authentification mTLS à l'aide de Go.

L'exemple de code du dépôt crée des charges de travail client et serveur. Vous pouvez tester l'authentification mutuelle entre les charges de travail à l'aide des certificats que vous avez générés précédemment dans ce document.

Activer la fédération d'approbation entre les pools d'identité de charge de travail (facultatif)

Pour activer l'authentification mutuelle pour les charges de travail dans différents domaines de confiance, vous devez configurer la fédération de confiance entre les pools d'identités de charge de travail. Cette étape n'est requise que si vos charges de travail doivent s'authentifier auprès de charges de travail dans un autre pool d'identités de charge de travail.

Pour activer la fédération d'identité, procédez comme suit :

  1. Créez le fichier de configuration de l'approbation.
  2. Mettez à jour le pool d'identités de charge de travail avec la configuration de confiance.

Créer le fichier de configuration de confiance

Créez le fichier de configuration de confiance avec une section inlineTrustConfig qui spécifie les certificats pour chaque domaine.

Le fichier de configuration de confiance contient un ensemble d'ancres de confiance que l'identité de charge de travail gérée utilise pour valider les certificats de pairs. Le fichier de configuration de confiance mappe le domaine de confiance SPIFFE aux certificats CA.

  1. Pour une CA personnalisée, téléchargez les certificats d'un domaine de confiance qui utilise une CA personnalisée.

    gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION

    Remplacez les éléments suivants :

    • ROOT_CA_POOL_ID : ID du pool d'autorités de certification racine.
    • CERTIFICATE_PATH : chemin d'accès au fichier de certificat encodé au format PEM.
    • REGION : région du pool d'autorités de certification racine.

  2. Créez un fichier nommé tc.json contenant votre configuration de confiance intégrée. Si un domaine utilise l'autorité de certification par défaut gérée par Google, utilisez le champ trustDefaultSharedCa. Si un domaine utilise une autorité de certification personnalisée, utilisez les certificats encodés au format PEM que vous avez téléchargés précédemment.

    Le fichier ressemble à ceci :

    Dans cet exemple, TRUST_DOMAIN_A utilise l'autorité de certification par défaut gérée par Google, et TRUSTED_DOMAIN_B utilise une autorité de certification personnalisée avec les certificats racines téléchargés.

    {
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_A": {
        "trustDefaultSharedCa": true
      },
      "TRUSTED_DOMAIN_B": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

    Remplacez les éléments suivants :

    • TRUST_DOMAIN_A : nom du domaine de confiance qui utilise l'autorité de certification par défaut gérée par Google.
    • TRUST_DOMAIN_B : nom du domaine de confiance qui utilise une AC personnalisée.
    • CERTIFICATE_MATERIAL : ensemble de certificats CA au format PEM autorisés à émettre des certificats dans le domaine de confiance.

Mettre à jour le pool d'identités de charge de travail avec la configuration de confiance

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • TRUST_DOMAIN_NAME : nom du domaine approuvé.
  • TC_JSON_FILE_PATH : chemin d'accès au fichier de configuration de l'approbation au format JSON (tc.json) que vous avez créé.
  • PROJECT_ID : ID du projet.

Étapes suivantes

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

Essai sans frais