Présentation de l'authentification mTLS du backend avec une identité de charge de travail gérée

Preview

Cette fonctionnalité est soumise(s) aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Vous pouvez implémenter l'authentification mTLS du backend avec ou sans identité de charge de travail gérée. Pour en savoir plus sur le mTLS de backend sans identité de charge de travail gérée, consultez Présentation du TLS authentifié par le backend et du mTLS de backend.

Ce document présente l'utilisation de l'identité de charge de travail gérée pour établir un protocole TLS mutuel (mTLS) entre un équilibreur de charge d'application et ses backends. L'identité de charge de travail gérée provisionne et gère automatiquement les certificats X.509 du service d'autorité de certification.

Remarque : Pour la preview, l'identité de charge de travail gérée ne peut être attribuée qu'au service de backend d'un équilibreur de charge d'application externe global.

Les informations de ce document s'appuient sur des concepts présentés dans les documents suivants :

• Présentation des identités de charge de travail gérées
• Secure Production Identity Framework For Everyone (SPIFFE)
• Certificate Authority Service
• Présentation de la TLS authentifiée par le backend et du mTLS de backend

Présentation de l'identité de charge de travail gérée pour les équilibreurs de charge

Sans identité de charge de travail gérée, la configuration du mTLS de backend nécessite la configuration de plusieurs ressources. Lorsque vous attribuez une identité gérée au service de backend d'un équilibreur de charge, l'identité de charge de travail gérée crée automatiquement les ressources nécessaires pour mTLS, telles que le certificat client, la configuration de confiance et la configuration d'authentification de backend.

Pour le mTLS de backend, la ressource de service de backend de l'équilibreur de charge sert de charge de travail source qui s'authentifie auprès du backend, qui est la charge de travail de destination.

Vous pouvez attribuer une identité gérée (représentée par un ID SPIFFE) au service de backend d'un équilibreur de charge. Google Cloud Certificate Authority Service provisionne automatiquement un certificat X.509 pour l'ID SPIFFE. Ce certificat X.509 pour l'ID SPIFFE est également appelé document d'identité vérifiable SPIFFE (SVID). Le service de backend de l'équilibreur de charge et ses backends utilisent les SVID pour s'authentifier mutuellement via l'authentification mTLS.

Le schéma suivant montre comment l'équilibreur de charge (charge de travail source) et le backend (charge de travail de destination) s'authentifient mutuellement à l'aide de l'identité de charge de travail gérée.

mTLS de backend utilisant l'identité de charge de travail gérée (cliquez pour agrandir).

Voici un exemple de X.509-SVID qui sert de wrapper pour l'ID SPIFFE. L'ID SPIFFE, représenté sous la forme d'un URI, est encodé dans le nom alternatif de l'objet (SAN) d'un certificat X.509.

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Ce résultat inclut les valeurs suivantes :

• WORKLOAD_IDENTITY_POOL_ID : ID du pool d'identités de charge de travail
• PROJECT_NUMBER : numéro de votre projetGoogle Cloud
• NAMESPACE_ID : ID de l'espace de noms
• MANAGED_IDENTITY_ID : ID de l'identité gérée

Avantages de l'utilisation de l'identité de charge de travail gérée

Voici quelques avantages de l'utilisation de l'identité de charge de travail gérée pour l'authentification mTLS du backend :

• Sécurité renforcée : en rejoignant un pool d'identités de charge de travail, un équilibreur de charge Google Cloud et ses backends font partie d'un domaine de confiance. Lorsqu'il est utilisé conjointement avec mTLS de backend, l'équilibreur de charge et les charges de travail de backend s'authentifient mutuellement. Cette authentification mutuelle empêche les charges de travail non autorisées d'accéder à vos services et chiffre les données en transit.

• Gestion automatisée des certificats : une fois l'attestation de charge de travail réussie,Google Cloud provisionne et fait tourner automatiquement les certificats X.509 pour les charges de travail participant au domaine de confiance du pool d'identités de charge de travail. Cette gestion automatique des certificats X.509 élimine le processus complexe et sujet aux erreurs de gestion manuelle des certificats.

• Identité interopérable : les pools d'identités de charge de travail utilisent le framework SPIFFE, une norme pour la gestion des identités dans les systèmes distribués, qui permet l'authentification et l'autorisation dans les architectures modernes basées sur les microservices.

• Gouvernance centralisée : les pools d'identités de charge de travail fournissent un point de contrôle central. Les administrateurs peuvent définir des domaines de confiance et établir des règles d'attestation pour déterminer les charges de travail pouvant recevoir un certificat X.509 pour l'identité gérée.

Architecture de l'authentification mTLS du backend à l'aide d'une identité de charge de travail gérée

Les composants suivants fonctionnent ensemble pour obtenir mTLS de backend à l'aide de l'identité de charge de travail gérée :

• Service de backend de l'équilibreur de charge (API Compute Engine)
• Domaine de confiance Identity and Access Management (API Identity and Access Management)
• Pool d'autorités de certification (API Certificate Authority Service)
• Configuration d'authentification de backend (API Network Security)
• Configuration de confiance du gestionnaire de certificats (API Certificate Manager)
• Certificat d'identité gérée Certificate Manager (API Certificate Manager)

Le schéma suivant illustre une identité gérée sur le service de backend de l'équilibreur de charge, qui permet à l'équilibreur de charge de s'authentifier auprès du backend. Dans le schéma, les étapes 1 à 3 représentent les ressources créées de manière explicite, tandis que les étapes 4 et 5 représentent les ressources créées automatiquement.

1. Configurez un pool d'autorités de certification Certificate Authority Service pour émettre des certificats pour les identités de charge de travail gérées.
2. Configurez un domaine de confiance en créant un pool d'identités de charge de travail. Ce pool nécessite un espace de noms, une identité gérée, une règle d'attestation, une ressource de configuration d'émission de certificat intégrée et une ressource de configuration d'approbation intégrée.
3. Configurez le service de backend de l'équilibreur de charge avec l'identité gérée.

4. L'identité de charge de travail gérée crée automatiquement le certificat d'identité gérée Certificate Manager et la configuration de confiance Certificate Manager.

   Le certificat d'identité gérée Certificate Manager est créé en fonction de la configuration d'émission de certificats dans le pool d'identités de charge de travail. La configuration de confiance de Certificate Manager est synchronisée avec la configuration de confiance intégrée du pool d'identités de charge de travail.

5. L'identité de charge de travail gérée crée automatiquement la configuration d'authentification du backend.

   La configuration de confiance du gestionnaire de certificats est associée à la configuration d'authentification de backend. Le certificat d'identité géré par Certificate Manager (X.509-SVID) est également associé à la configuration d'authentification du backend, qui est ensuite utilisée pour l'authentification auprès du backend.

Pour en savoir plus sur la configuration mTLS du backend à l'aide de l'identité gérée, consultez Configurer mTLS du backend à l'aide de l'identité de charge de travail gérée.

Architecture de mTLS de backend utilisant l'identité de charge de travail gérée (cliquez pour agrandir).

Ressources créées lors du mTLS de backend à l'aide d'une identité gérée

Comme le montre le schéma d'architecture précédent, lorsque vous attribuez une identité gérée au service de backend, vous n'avez pas besoin de configurer la configuration d'authentification du backend, la configuration d'approbation Certificate Manager ni le certificat Certificate Manager. Ces ressources sont créées automatiquement par l'identité de charge de travail gérée.

Cette section examine de plus près les différentes parties du processus de configuration des identités gérées, en se concentrant sur les ressources créées de manière explicite et celles créées automatiquement.

Ressources créées de manière explicite

Les ressources suivantes doivent être créées de manière explicite lors de la configuration de mTLS de backend à l'aide de l'identité de charge de travail gérée.

Pool d'autorités de certification

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

Vous pouvez utiliser des pools CA Service pour configurer cette hiérarchie.

Le pool d'identités de charge de travail est lié au pool d'autorités de certification en mettant à jour le pool d'identités de charge de travail avec la configuration d'émission de certificats intégrée.

Identité de charge de travail gérée

Vous devez créer une identité de charge de travail gérée dans l'espace de noms du pool d'identités de charge de travail. L'identité gérée est un ID SPIFFE entièrement spécifié utilisé dans le SVID présenté par la charge de travail de l'équilibreur de charge.

Règles d'attestation

Une règle d'attestation contient des règles pour Google Cloud IAM afin de vérifier si le service de backend est éligible à la réception d'un certificat X.509 pour l'identité gérée qui lui est attribuée.

Si la validation de la stratégie d'attestation réussit, IAM demande un certificat X.509 pour l'identité gérée au service d'autorité de certification. Le certificat X.509 est créé dans le pool d'autorités de certification lié à l'identité gérée. Le service CA provisionne le certificat via la réflexion d'identité, où l'ID SPIFFE configuré est reflété sur un certificat X.509.

Configuration d'émission de certificats intégrée

Lorsque vous configurez un pool d'identités de charge de travail, vous configurez une configuration d'émission de certificat intégrée. Cette configuration spécifie le pool d'autorités de certification de votre instance Certificate Authority Service qui est utilisé pour générer des certificats X.509 pour les identités du pool d'identités de charge de travail. Le fichier de configuration spécifie également la durée de vie du certificat, le pourcentage de la période de rotation et l'algorithme de clé.

Le pool d'autorités de certification émet des certificats X.509 pour les identités de charge de travail gérées une fois que l'application de la règle d'attestation a réussi.

Configuration de confiance intégrée du pool d'identités de charge de travail

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 se trouvant dans différents domaines de confiance s'authentifient mutuellement, vous devez déclarer explicitement la relation d'approbation dans le pool d'identités de charge de travail. Pour ce faire, créez une configuration de confiance intégrée qui reconnaît et accepte les certificats provenant d'autres domaines de confiance. Ces certificats permettent de créer une chaîne de confiance et de valider l'identité des charges de travail provenant d'autres domaines.

La configuration de confiance intégrée contient un ensemble d'ancres de confiance que l'identité de charge de travail gérée utilise pour valider les certificats de pairs. La configuration de confiance Certificate Manager encapsule un magasin de confiance SPIFFE, qui reste synchronisé avec la configuration de confiance intégrée du pool d'identités de charge de travail.

Étant donné que le pool d'identités de charge de travail est lié au pool d'autorités de certification, il approuve automatiquement les certificats racine de ce même pool d'autorités de certification. Vous n'avez pas besoin d'ajouter les racines d'autorité de certification du pool à la configuration de confiance intégrée, car cette confiance est déjà intégrée.

Service de backend (API Compute Engine)

Pour attribuer une identité gérée à l'équilibreur de charge, vous devez configurer le service de backend de l'équilibreur de charge de sorte que son attribut tlsSettings pointe vers la nouvelle propriété identity (backendService.tlsSettings.identity).

Notez les restrictions suivantes qui s'appliquent lorsque vous utilisez le champ identity sur le service de backend de l'équilibreur de charge :

• Si vous définissez la propriété identity, vous ne pouvez pas définir manuellement les champs suivants sur l'attribut tlsSettings :

  • tlsSettings.sni
  • tlsSettings.subjectAltNames
  • tlsSettings.authenticationConfig

• Le champ identity ne peut être attribué que lors de la création du service de backend.

• Le champ identity est immuable. Une fois que vous en avez attribué un au service de backend de l'équilibreur de charge, vous ne pouvez plus le modifier ni le supprimer.

Ressources créées automatiquement

Une fois que vous avez défini la propriété identity (backendService.tlsSettings.identity) sur le service de backend de l'équilibreur de charge, les ressources suivantes des API Certificate Manager et Network Security sont créées automatiquement par l'identité de charge de travail gérée.

Les ressources créées automatiquement le sont dans le même projet que le service de backend et utilisent les quotas standards de ce projet.

Configuration de confiance du gestionnaire de certificats (API Certificate Manager)

La configuration de confiance du gestionnaire de certificats est créée automatiquement et ne peut pas être modifiée ni supprimée directement.

La configuration de confiance du gestionnaire de certificats contient un champ appelé spiffeTrustStores. Le champ spiffeTrustStores contient le bundle de confiance associé au domaine de confiance du pool d'identités de charge de travail et tous les bundles de confiance supplémentaires spécifiés par le champ additionalTrustBundles dans la configuration de confiance intégrée du pool d'identités de charge de travail.

Pour valider les certificats SPIFFE, le champ spiffeTrustStores de la configuration de confiance Certificate Manager est automatiquement activé lorsque vous utilisez une identité de charge de travail gérée. Lorsque le champ spiffeTrustStores est activé, le champ trustStores reste vide.

Le champ spiffeTrustStores est une structure de données de type map où la paire clé/valeur est la suivante :

• La clé peut être un domaine de confiance associé à un pool d'identités de charge de travail (au format se terminant par .workload.id.goog) ou un domaine de confiance supplémentaire.
• La valeur est un objet TrustStore. Cet objet contient une collection de certificats racine de confiance (appelée groupe d'approbations) utilisée pour valider les certificats SPIFFE de ce domaine de confiance spécifique.

En substance, cette carte permet de configurer l'équilibreur de charge pour qu'il approuve les magasins de plusieurs domaines de sécurité distincts. Lorsqu'un backend présente son certificat, l'équilibreur de charge extrait l'ID SPIFFE, identifie le domaine de confiance et utilise le mappage pour rechercher le magasin de confiance approprié nécessaire à la validation de ce certificat.

Certificat d'identité gérée Certificate Manager (API Certificate Manager)

Le certificat d'identité gérée du gestionnaire de certificats est créé automatiquement par l'identité de charge de travail gérée. Le certificat d'identité gérée Certificate Manager est en lecture seule et ne peut pas être modifié ni supprimé directement à l'aide de l'API Certificate Manager. Le certificat d'identité gérée par le gestionnaire de certificats est basé sur la configuration d'émission de certificats intégrée, qui est définie dans le pool d'identités de charge de travail.

Le certificat d'identité gérée du gestionnaire de certificats possède une propriété managedIdentity, qui l'identifie comme un certificat d'identité gérée. La ressource de certificat d'identité gérée par Certificate Manager stocke le certificat X.509-SVID au format PEM. Ce SVID X.509 contient l'ID SPIFFE encodé en tant qu'URI dans le champ SAN. Cet ID SPIFFE correspond à l'identité gérée dans le pool d'identités de charge de travail.

Le champ d'application du certificat d'identité géré par le gestionnaire de certificats est CLIENT_AUTH, ce qui indique que ce certificat est utilisé comme certificat client dans le mTLS de backend.

Configuration d'authentification de backend (API Network Security)

La configuration d'authentification de backend est créée automatiquement par l'identité de charge de travail gérée. La configuration d'authentification de backend est en lecture seule et ne peut pas être modifiée ni supprimée directement à l'aide de l'API Network Security.

La configuration de confiance du gestionnaire de certificats est associée à la configuration d'authentification de backend.

Le certificat d'identité gérée du gestionnaire de certificats est également associé à la configuration d'authentification de backend et est utilisé comme X.509-SVID dans les requêtes mTLS de backend entre l'équilibreur de charge et les charges de travail de destination.

Limites

• La mTLS de backend avec identité de charge de travail gérée ne peut être configurée que pour les équilibreurs de charge d'application externes globaux. Les équilibreurs de charge d'application classiques ne sont pas compatibles avec le mTLS de backend.

• La mTLS de backend n'est pas compatible avec les backends NEG Internet mondiaux.

• Si vous attribuez une identité gérée au service de backend (backendService.tlsSettings.identity), vous ne pouvez pas définir manuellement les champs suivants sur la propriété tlsSettings du service de backend :

  • backendService.tlsSettings.sni
  • backendService.tlsSettings.subjectAltNames
  • backendService.tlsSettings.authenticationConfig

• Une identité gérée ne peut être attribuée qu'au moment de la création du service de backend.

• L'identité gérée est immuable. Une fois qu'une identité gérée a été attribuée au service de backend de l'équilibreur de charge, elle ne peut plus être mise à jour ni supprimée.

Étape suivante

• Configurer mTLS de backend à l'aide de l'identité de charge de travail gérée