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

Ce document explique comment configurer des identités de charge de travail gérées pour Google Kubernetes Engine (GKE) dans vos clusters gérés par des flottes 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. Configurez Certificate Authority Service pour émettre des certificats pour les identités de charge de travail gérées.

  2. Liez les autorités de certification 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.

  4. Déployez des charges de travail avec des identités de charge de travail gérées.

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

Lorsque vous ajoutez vos clusters à des parcs GKE, ils créent automatiquement un pool d'identités de charge de travail géré par Google qui sert de racine à votre domaine de confiance. Le pool d'identités de charge de travail géré par Google présente les contraintes suivantes:

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

  • Le pool ne peut être utilisé que pour les charges de travail GKE. Vous ne pouvez pas ajouter d'autres types de charges de travail, comme des VM Compute Engine, au pool.

  • Tous les clusters du pool sont soumis au modèle de similarité d'espace de noms Kubernetes standard. Cela signifie que tous les clusters du pool sont dotés des mêmes droits. Les charges de travail exécutées sur l'un des clusters du pool peuvent utiliser n'importe quelle identité du pool.

Configuration multiprojet

Google Cloud Les ressources 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 l'indicateur --project pour spécifier le projet approprié pour chaque ressource.

Avant de commencer

  1. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

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

  3. Assurez-vous d'avoir créé un cluster GKE.

  4. Ajoutez vos clusters à des parcs GKE. Si votre cluster est un cluster Autopilot, omettez --enable-workload-identity. Fleets crée 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 \
        --enable-workload-identity \
        --enable-fleet \
        --fleet-project=PROJECT_ID
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME: nom du cluster GKE que vous souhaitez enregistrer auprès du parc GKE
    • PROJECT_ID: ID du projet hôte du parc GKE
  5. Enable the IAM and Certificate Authority Service APIs:

    gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com

  6. Configurez la Google Cloud CLI pour qu'elle utilise le projet de facturation et de quotas.

    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ée, 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 la page 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.

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 (CA) et une ou plusieurs autorités de certification subordonnées. Cette configuration est appelée hiérarchie d'autorité de certification.

Vous pouvez utiliser des pools de services d'autorité de certification 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.

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 d'autorités de certification, les niveaux et les régions, 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 éventuellement configurer des autorités de certification subordonnées. La configuration d'autorités de certification subordonnées peut vous aider à:

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

  • Équilibre de charge amélioré: 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ées.
    • CA_PROJECT_ID: ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.

    Pour en savoir plus, consultez 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, elles doivent disposer d'une configuration d'émission de certificats. Si vous devez authentifier vos charges de travail sur plusieurs domaines de confiance, vous pouvez également mettre à jour le pool avec des configurations de configuration de confiance.

Pour configurer la configuration d'émission de certificats, vous devez créer un fichier de configuration d'émission de certificats. 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ées. 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 (par défaut), ECDSA_P384, RSA_2048, RSA_3072 et RSA_4096.

  • 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 86 400 (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. La valeur par défaut est 50.

Créer le fichier de configuration de confiance

Par défaut, vos charges de travail appartenant au même domaine de confiance peuvent s'authentifier mutuellement à l'aide d'identités de charge de travail gérées. Si vous souhaitez que les charges de travail situées dans des différents domaines de confiance s'authentifient mutuellement, vous devez déclarer explicitement la relation de confiance dans le pool d'identités de charge de travail. Pour ce faire, créez un fichier de configuration de confiance contenant un inlineTrustConfig qui fournit des 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 de l'autorité de certification.

Pour créer le fichier de configuration de l'approbation, procédez comme suit:

  1. Téléchargez les certificats.

    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 vers lequel générer le certificat au format PEM
    • REGION: région du pool d'autorités de certification racine

  2. Créez un fichier contenant votre configuration de confiance intégrée, avec des certificats au format PEM. Le fichier se présente comme suit:
    {
      "inlineTrustConfig": {
        "additionalTrustBundles": {
          "TRUST_DOMAIN_NAME1": {
            "trustAnchors": [
              {
                  "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
              },
              {
                  "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
              }
            ]
          },
          "TRUSTED_DOMAIN_NAME2": {
            "trustAnchors": [
              {
                  "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
              },
              {
                  "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
              }
            ]
          }
        }
      }
    }
    

    Remplacez les éléments suivants :

    • TRUST_DOMAIN_NAME: nom de domaine de confiance, au format suivant:
      PROJECT_ID.svc.id.goog
      
    • CERTIFICATE_MATERIAL: ensemble de certificats CA au format PEM approuvés pour émettre des certificats dans le domaine de confiance.

Lier les autorités de certification 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 liez 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, vous devez mettre à 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 \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • TRUST_DOMAIN_NAME: nom du domaine de confiance, au format suivant:

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

  • TC_JSON_FILE_PATH : facultatif. Chemin d'accès au fichier de configuration de confiance au format JSON (tc.json) que vous avez créé précédemment. Si vos charges de travail s'authentifient dans différents domaines de confiance, vous devez spécifier ce fichier. Sinon, vous pouvez omettre --inline-trust-config.

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 et la configuration de confiance, 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 de confiance que vous avez utilisé pour mettre à jour le pool d'identités de la charge de travail plus tôt dans ce document.

Le résultat de la commande ressemble à ceci :

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
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

Si inlineCertificateIssuanceConfig ou inlineTrustConfig 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, vous devez autoriser les identités de charge de travail gérées à demander des certificats au pool d'autorités de certification. Pour autoriser ces identités, procédez comme suit:

  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/PROJECT_ID.svc.id.goog" \
        --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.

      Pour obtenir PROJECT_NUMBER à partir de PROJECT_ID, exécutez la commande suivante:

      gcloud projects describe PROJECT_ID --format="value(projectNumber)"
      
    • PROJECT_ID: ID du projet hôte du parc GKE.

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

  2. Accordez le rôle 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/PROJECT_ID.svc.id.goog" \
        --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.
    • PROJECT_ID: ID du projet hôte du parc GKE.
    • 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 disposent d'identités de charge de travail gérées.

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

Déployer un pod

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 une 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
    

Lister les identifiants de la charge de travail

Pour lister les identifiants de la 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

Vous devriez obtenir le résultat suivant :

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

Afficher le certificat

Pour afficher le certificat, procédez comme suit:

  1. Exportez le certificat vers 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 pouvez voir l'ID SPIFFE, au format suivant: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

    default fait référence au compte de service 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.

Étape suivante

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 gratuits pour exécuter, tester et déployer des charges de travail.

Essai gratuit