Authentifier des charges de travail auprès d'autres charges de travail via mTLS

Ce document explique comment configurer le provisionnement automatique et la gestion du cycle de vie des identités de charge de travail gérées pour Compute Engine. Vous configurez des pools d'autorités de certification pour émettre des certificats à l'aide de Certificate Authority Service (CA), un service Google Cloud hautement disponible et évolutif, qui simplifie et automatise le déploiement, la gestion et la sécurité des services CA. Chaque VM est provisionnée avec des identifiants X.509 provenant du pool d'autorités de certification configuré. Ces identifiants peuvent ensuite être utilisés pour établir des connexions mTLS.

Avec les identités de charge de travail gérées pour Compute Engine, vous pouvez mettre en œuvre des communications chiffrées et mutuellement authentifiées entre deux VM Compute Engine. Les applications de charge de travail exécutées sur les VM configurées peuvent utiliser les identifiants X.509 pour le protocole mTLS par VM. Ces certificats mTLS sont automatiquement alternés et gérés pour vous par Certificate Authority Service.

Avant de commencer

  • Demandez l'accès à la version bêta de l'identité de charge de travail gérée.

  • Configurez Google Cloud CLI

    Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante : 

    gcloud init

  • Configurez la Google Cloud CLI afin d'utiliser le projet ajouté à la liste d'autorisation pour la facturation et les quotas.

      gcloud config set billing/quota_project PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet qui a été ajouté à la liste d'autorisation pour l'identité de charge de travail gérée en preview.

  • Consultez la documentation Présentation des identités de charge de travail gérées.

  • Activer l'API Compute Engine : 

    gcloud services enable compute.googleapis.com

Rôles requis

Pour obtenir les autorisations nécessaires pour créer des VM qui utilisent des certificats d'identités de charge de travail gérées pour s'authentifier auprès d'autres charges de travail, 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 section Gérer les accès.

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

Présentation

Pour utiliser des identités de charge de travail gérées pour vos applications, vous devez effectuer les tâches suivantes:

  1. Administrateur de la sécurité

  2. Administrateur de Compute:

Configurer des identités de charge de travail gérées dans Identity and Access Management

  • Suivez les instructions de la section Configurer l'authentification des identités de charge de travail gérées.

    Ces instructions expliquent comment effectuer les opérations suivantes:

    • Créez un pool d'identités de charge de travail.
    • Créez des espaces de noms dans le pool d'identités de charge de travail. Vous utilisez les espaces de noms pour créer des limites administratives pour vos identités de charge de travail gérées, par exemple un espace de noms pour chacune des applications appartenant à votre organisation.
    • Créez une identité de charge de travail gérée dans un espace de noms du pool d'identités de charge de travail. Par exemple, vous pouvez créer un espace de noms pour une application et créer des identités gérées dans cet espace de noms pour les microservices compatibles avec cette application.
    • créent un compte de service ; Les VM Compute Engine peuvent être autorisées à recevoir une identité de charge de travail gérée en fonction du compte de service Google Cloud associé à la VM.
    • Créez une règle d'attestation de charge de travail qui permet à votre charge de travail d'obtenir des identifiants pour l'identité de charge de travail gérée. Pour générer des identifiants pour l'identité de charge de travail gérée, la charge de travail doit se trouver dans un projet spécifié et être associé au compte de service.
    • Configurez Certificate Authority Service afin d'émettre des certificats pour les identités de charge de travail gérées :
      • Configurer le pool d'autorités de certification racine
      • Configurer les autorités de certification subordonnées
      • Autoriser les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification

Obtenez le fichier de configuration pour importer les métadonnées du partenaire

Votre administrateur de sécurité crée un fichier JSON contenant les informations suivantes:

Ce fichier doit être nommé CONFIGS.json. Vous utiliserez ce fichier lors de la création d'un modèle d'instance pour des MIG ou lors de la création d'une VM individuelle.

Le fichier CONFIGS.json doit ressembler à ce qui suit :

  {
  "wc.compute.googleapis.com": {
     "entries": {
        "certificate-issuance-config": {
           "primary_certificate_authority_config": {
              "certificate_authority_config": {
                 "ca_pool": "projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_REGION/caPools/SUBORDINATE_CA_POOL_ID"
              }
           },
           "key_algorithm": "rsa-2048"
        },
        "trust-config": {
           "POOL_ID.global.PROJECT_NUMBER.workload.id.goog": {
               "trust_anchors": [{
                  "ca_pool": "projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_REGION/caPools/SUBORDINATE_CA_POOL_ID"
                }]
           }
     }
  }
  },
  "iam.googleapis.com": {
     "entries": {
        "workload-identity": "spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID"
     }
  }
  }

Activer les identités de charge de travail gérées pour un groupe d'instances géré (MIG)

Un groupe d'instances géré (MIG, Managed Instance Group) est un groupe d'instances de machines virtuelles (VM) qui sont traitées comme une seule entité. Chaque VM d'un MIG est créée à l'aide d'un modèle d'instance. Pour permettre aux VM du MIG d'utiliser des identités de charge de travail gérées, spécifiez la configuration dans le modèle d'instance.

Créer un modèle d'instance

Créez un modèle d'instance avec la fonctionnalité d'identités de charge de travail gérées activée. Créez ensuite un groupe d'instances géré (MIG) à l'aide de ce modèle.

gcloud

Exécutez la commande gcloud beta compute instance-templates create pour créer un modèle d'instance qui active les identités de charge de travail gérées.

gcloud beta compute instance-templates create INSTANCE_TEMPLATE_NAME \
    --service-account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --metadata enable-workload-certificate=true \
    --partner-metadata-from-file CONFIGS.json

Vous pouvez ajouter des options supplémentaires lors de la création du modèle d'instance pour personnaliser les VM qu'il crée, telles que le type de machine et l'image, au lieu d'utiliser les valeurs par défaut.

Remplacez les éléments suivants :

  • INSTANCE_TEMPLATE_NAME : nom du nouveau modèle.
  • SERVICE_ACCOUNT_NAME: nom du compte de service autorisé à recevoir l'identité gérée.
  • PROJECT_ID: ID du projet dans lequel le compte de service a été créé.
  • CONFIGS.json: fichier de configuration contenant la configuration d'émission du certificat, la configuration de confiance et l'identité de charge de travail gérée.

Pour en savoir plus, consultez la page Créer des modèles d'instance.

Créer un groupe d'instances géré à partir du modèle

Créez un groupe d'instances géré qui utilise un modèle d'instance qui active les identités de charge de travail gérées. Pour en savoir plus sur la création du modèle d'instance, consultez la section Créer un modèle d'instance.

gcloud

Créez un MIG à l'aide du modèle d'instance et de la commande gcloud compute instance-groups managed create.

gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
    --size=SIZE \
    --template=INSTANCE_TEMPLATE_NAME \
    --zone=ZONE

Remplacez les éléments suivants :

  • INSTANCE_GROUP_NAME: ID unique pour le groupe d'instances géré. Pour en savoir plus sur les noms valides, consultez la section Nommer les ressources.
  • SIZE: taille du groupe d'instances géré.
  • INSTANCE_TEMPLATE_NAME: nom du modèle d'instance à utiliser lors de la création de VM dans le MIG.
  • ZONE : zone dans laquelle créer les VM.

Pour en savoir plus sur la création de MIG, consultez la section Scénarios de base pour la création de groupes d'instances gérés (MIG).

Activer les identités de charge de travail gérées pour des VM individuelles

Vous pouvez activer les identités de charge de travail gérées pour une VM lors de sa création ou en mettant à jour les métadonnées du partenaire pour une VM existante.

Créer des VM avec des identités de charge de travail gérées activées

Lors de la création d'une VM, pour activer la fonctionnalité d'identité de charge de travail gérée pour la VM, vous devez procéder comme suit:

  • Spécifier un compte de service à utiliser par la VM
  • Définissez l'attribut de métadonnées enable-workload-certificate sur true.

  • Spécifiez les informations de configuration d'émission de certificat et de confiance en tant que métadonnées partenaires.

gcloud

Exécutez la commande gcloud beta compute instances create pour créer une VM. Utilisez le fichier CONFIGS.json fourni par votre administrateur de sécurité ou créé en suivant les instructions de la section Créer un fichier de configuration pour importer les métadonnées du partenaire.

  1. Créez une VM avec la fonctionnalité d'identités de charge de travail gérées activée.

    gcloud beta compute instances create INSTANCE_NAME \
   --zone=INSTANCE_ZONE \
   --service-account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --metadata enable-workload-certificate=true \
   --partner-metadata-from-file CONFIGS.json

    Vous pouvez ajouter des lignes supplémentaires à la commande pour configurer la VM, telles que le type de machine et l'image, au lieu d'utiliser les valeurs par défaut. Pour en savoir plus, consultez la page Créer et démarrer une instance de VM.

    Remplacez les éléments suivants :

    • INSTANCE_NAME: nom unique de la VM. Pour en savoir plus sur les noms d'instance valides, consultez la section Noms des ressources.
    • INSTANCE_ZONE : zone dans laquelle créer la VM.
    • SERVICE_ACCOUNT_NAME: nom du compte de service autorisé à recevoir l'identité gérée.
    • PROJECT_ID: ID du projet dans lequel le compte de service a été créé.
    • CONFIGS.json: nom du fichier de configuration contenant la configuration d'émission de certificat, la configuration de confiance et la configuration d'identité de charge de travail gérée.

Activer les identités de charge de travail gérées sur les VM existantes

Pour activer les identités de charge de travail gérées pour une VM existante, mettez à jour la VM pour configurer les éléments suivants:

  • Définissez l'attribut de métadonnées enable-workload-certificate sur true.

  • Spécifiez la configuration d'émission de certificat et les informations de configuration de confiance en tant que métadonnées partenaires.

gcloud

Cette tâche utilise le fichier CONFIGS.json fourni par votre administrateur de sécurité ou créé en suivant les instructions de la section Créer un fichier de configuration pour importer les métadonnées du partenaire.

  1. Mettez à jour la configuration d'une VM existante pour activer les identités de charge de travail gérées.

    gcloud beta compute instances update VM_NAME \
   --zone=ZONE \
   --metadata enable-workload-certificate=true \
   --partner-metadata-from-file CONFIGS.json

    Remplacez les éléments suivants :

    • VM_NAME : nom de la VM
    • ZONE : zone où se trouve la VM
    • CONFIGS.json: fichier de configuration contenant la configuration d'émission du certificat, la configuration de confiance et l'identité de charge de travail gérée.

Accéder aux identifiants de charge de travail sur une VM Linux

Après avoir configuré avec succès l'authentification de la charge de travail à la charge de travail à l'aide de mTLS, vous pouvez accéder aux identifiants émis sur votre VM.

Il existe deux façons d'accéder aux identifiants d'identité de charge de travail gérés Compute Engine et au groupe d'approbation associé:

  • Le système de fichiers de la VM
  • Serveur de métadonnées Compute Engine

Accéder aux identifiants de la charge de travail et au groupe de confiance à l'aide du système de fichiers de la VM

Cette méthode place les identifiants X.509 et le groupe d'approbations dans un chemin spécifique dans le système de fichiers de la VM. Les applications peuvent lire directement les identifiants et le groupe d'approbation à partir du système de fichiers. Pour obtenir des exemples de récupération des identifiants, consultez les exemples suivants sur GitHub:

La VM doit exécuter l'agent invité Compute Engine version 20231103.01 ou ultérieure. Exécutez la commande suivante pour vérifier la version de l'agent invité Compute Engine sur votre VM:

gcloud compute instances get-serial-port-output INSTANCE_NAME | grep "GCE Agent Started"

Si la version de l'agent invité est antérieure à la version 20231103.01, vous pouvez la mettre à jour en suivant les instructions de la section Mettre à jour l'environnement invité.

Pour rendre les identifiants de charge de travail et le groupe de confiance disponibles dans le système de fichiers d'une VM, procédez comme suit:

  1. Installez ou mettez à jour l'agent invité Compute Engine vers la version 20231103.01 ou ultérieure. L'agent invité effectue les opérations suivantes:

    • Il récupère automatiquement les identifiants et le groupe d'approbation à partir du serveur de métadonnées Compute Engine.
    • Garantit des écritures atomiques sur le système de fichiers lors de la mise à jour du certificat X.509 et de la clé privée correspondante.
    • Actualise automatiquement les identifiants et le groupe d'approbation, par exemple lors de la rotation des certificats mTLS.

  2. Une fois que vous avez installé ou mis à jour l'agent invité Compute Engine sur le système d'exploitation invité, la tâche d'actualisation de la charge de travail crée le répertoire /var/run/secrets/workload-spiffe-credentials et définit les autorisations du répertoire sur 0755 (rwxr-xr-x).

    Le répertoire contient les fichiers suivants créés avec les autorisations 0644 (rw-r--r--):

    • private_key.pem: clé privée au format PEM.
    • certificates.pem: bundle de certificats X.509 au format PEM qui peuvent être présentés à d'autres VM sous la forme d'une chaîne de certificats client, ou utilisés comme chaîne de certificats de serveur.

    • ca_certificates.pem: bundle de certificats X.509 au format PEM à utiliser comme ancres de confiance lors de la validation des certificats de pairs.

      spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog

    • config_status: fichier journal contenant des messages d'erreur.

  3. Les applications peuvent lire directement les certificats, la clé privée et le bundle d'approbations à partir du système de fichiers pour établir des connexions mTLS.

Accéder aux identifiants de la charge de travail et au groupe d'approbation à l'aide du serveur de métadonnées

Une application exécutée sur une VM Compute Engine peut interroger directement les points de terminaison du serveur de métadonnées et récupérer les identifiants et le groupe d'approbation. L'application est chargée de vérifier régulièrement les points de terminaison du serveur de métadonnées pour détecter de nouveaux identifiants et les mises à jour du groupe d'approbation.

Le serveur de métadonnées Compute Engine expose trois points de terminaison HTTP pour permettre aux applications exécutées dans la VM d'utiliser la fonctionnalité d'identité de charge de travail gérée.

  • gce-workload-certificates/config-status: point de terminaison contenant les erreurs dans les valeurs de configuration fournies via les métadonnées de la VM.
  • gce-workload-certificates/workload-identities: point de terminaison des identités gérées par le plan de contrôle Compute Engine. Ce point de terminaison contient le certificat X.509 et la clé privée du domaine de confiance de la VM.
  • gce-workload-certificates/trust-anchors: point de terminaison contenant un ensemble de certificats de confiance pour la validation de la chaîne de certificats X.509 pairs.

Pour en savoir plus sur l'interrogation des métadonnées d'une instance de VM, consultez la page À propos des métadonnées de VM.

Pour accéder aux identifiants de la charge de travail et au groupe d'approbation à l'aide du serveur de métadonnées, votre application doit procéder comme suit:

  1. Interrogez le point de terminaison gce-workload-certificates/config-status. Assurez-vous que le code de réponse HTTP est 200 et que la réponse ne contient aucune erreur partnerMetadataConfigsErrors. Si de telles erreurs existent, mettez à jour la configuration appropriée avec des valeurs valides en suivant les étapes décrites dans la section Mettre à jour l'émission de certificats et la configuration de confiance.

    Pour vérifier la valeur, vous pouvez exécuter la commande suivante sur la VM:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status" -H "Metadata-Flavor: Google"

    Le point de terminaison config-status renvoie une réponse JSON avec la structure suivante:

    {
    "partnerMetadataConfigsErrors": {
        "errors": {  // A map of errors keyed by attribute name.
            "ATTRIBUTE_NAME" : "ERROR_DETAILS",
            ...
        }
    }
}

  2. Interrogez le point de terminaison gce-workload-certificates/workload-identities. Assurez-vous que le code de réponse HTTP est 200. Le point de terminaison renvoie une réponse JSON avec la structure suivante:

    {
 "workloadCredentials": {  // Credentials for the VM's trust domains
   "spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID": {
      "certificatePem" : "X.509 certificate or certificate chain",
      "privateKeyPem" : "Private for X.509 leaf certificate"
   }
 }
}

    Extrayez certificatePem et privateKeyPem. Il est essentiel que les deux valeurs soient lues à partir de la même réponse afin d'éviter une incohérence entre la clé privée et la clé publique au cas où les identités de charge de travail gérées auraient été actualisées par l'infrastructure Compute Engine.

  3. Interrogez le point de terminaison gce-workload-certificates/trust-anchors. Assurez-vous que le code de réponse HTTP est 200. La réponse ne contient que les ancres d'approbation du domaine de confiance SPIFFE, si spécifié. Sinon, la requête renvoie une erreur. Le point de terminaison trust-anchors renvoie une réponse JSON avec la structure suivante:

    {
    "trustAnchors": {  // Trust bundle for the VM's trust domains
        "POOL_ID.global.PROJECT_NUMBER.workload.id.goog": {
            "trustAnchorsPem" : "Trust bundle containing the X.509
            roots certificates"
        }
    }
}

    Le contenu de trustAnchorsPem contient le groupe d'approbations qui peut ensuite être utilisé pour authentifier les identifiants du pair X.509 lors de l'établissement d'une connexion mTLS.

Actualiser les identifiants et le groupe d'approbation

Le plan de contrôle Compute Engine effectue périodiquement une rotation automatique des identifiants de l'identité de charge de travail gérée et des ancres de confiance.

Si vos applications utilisent le système de fichiers pour accéder aux identifiants de la charge de travail et au groupe de confiance, l'agent invité Compute Engine actualise automatiquement les identifiants et le groupe d'approbation, par exemple lors de la rotation des certificats mTLS.

Si vos applications interrogent le serveur de métadonnées, alors les applications s'exécutant sur une VM doivent interroger régulièrement les points de terminaison du serveur de métadonnées pour obtenir le dernier ensemble d'identifiants d'identité de charge de travail géré et du bundle d'approbation. À défaut, les applications peuvent être interrompues en raison de l'expiration des certificats ou de modifications apportées au groupe de confiance, ce qui peut entraîner l'échec de l'établissement de la connexion mTLS. Google recommande aux applications d'interroger le serveur de métadonnées pour obtenir les identifiants d'identité de la charge de travail gérée et le groupe d'approbation toutes les cinq minutes.

Mettre à jour la configuration d'émission et de confiance de certificats

Vous pouvez modifier la configuration d'émission de certificat et la configuration de confiance pour une VM qui utilise des identités de charge de travail gérées.

Mettre à jour le modèle d'instance d'un groupe d'instances géré

Pour mettre à jour les valeurs de configuration d'émission de certificat et de confiance dans un modèle d'instance, vous devez créer un modèle avec les nouvelles valeurs. Par conséquent, la mise à jour de la configuration d'émission de certificat et de la configuration de confiance pour les groupes d'instances gérés (MIG) existants n'est pas acceptée.

Mettre à jour des VM Compute Engine individuelles

Pour mettre à jour la configuration d'émission de certificats et la configuration de confiance, mettez à jour le contenu du fichier CONFIGS.json et utilisez la commande gcloud beta compute instances update pour appliquer les mises à jour:

gcloud beta compute instances update INSTANCE_NAME \
    --partner-metadata-from-file FILENAME.json

Remplacez les éléments suivants :

  • INSTANCE_NAME: nom de la VM pour laquelle vous mettez à jour les valeurs de configuration
  • FILENAME: nom du fichier de configuration modifié, par exemple CONFIGS.json

Résoudre les problèmes

Pour connaître les méthodes de diagnostic et de résolution des erreurs courantes liées à la récupération des identifiants de charge de travail, consultez la documentation Résoudre les problèmes d'authentification de charge de travail à charge à travail.

Étapes suivantes