Vous pouvez configurer mTLS pour le backend avec ou sans identité de charge de travail gérée. Pour en savoir plus sur mTLS pour le backend sans identité de charge de travail gérée, consultez Présentation de TLS authentifiée et de mTLS pour le backend.
Ce document présente l'utilisation d'une identité de charge de travail gérée pour établir le 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 de Certificate Authority Service.
Les informations de ce document s'appuient sur les 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 TLS authentifiée et de mTLS pour le 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 de mTLS pour le 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 mTLS pour le backend, la ressource de service de backend de l'équilibreur de charge agit comme une 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 l'équilibreur de charge (charge de travail source) et le backend (charge de travail de destination) qui s'authentifient mutuellement à l'aide d'une identité de charge de travail gérée.
Voici un exemple de X.509-SVID qui sert de wrapper pour l'ID SPIFFE. L'ID SPIFFE, représenté sous forme d'URI, est encodé dans le champ "Autre nom 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 travailPROJECT_NUMBER: numéro de votre Google Cloud projetNAMESPACE_ID: ID de l'espace de nomsMANAGED_IDENTITY_ID: ID de l'identité gérée
Avantages de l'utilisation d'une identité de charge de travail gérée
Voici quelques avantages de l'utilisation d'une identité de charge de travail gérée pour mTLS pour le backend :
Sécurité renforcée : en rejoignant un pool d'identités de charge de travail, un Google Cloud équilibreur de charge et ses backends font partie d'un domaine de confiance. Lorsqu'ils sont utilisés conjointement avec mTLS pour le 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 : après une attestation de charge de travail réussie, Google Cloud provisionne et fait pivoter 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 de 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. Les administrateurs peuvent définir des domaines de confiance et établir des règles d'attestation pour déterminer quelles charges de travail peuvent recevoir un certificat X.509 pour l'identité gérée.
Architecture de mTLS pour le backend à l'aide d'une identité de charge de travail gérée
Les composants suivants fonctionnent ensemble pour établir mTLS pour le backend à l'aide d'une 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 du gestionnaire de certificats (API Certificate Manager)
Le schéma suivant montre une identité gérée sur le service de backend de l'équilibreur de charge, ce qui permet à l'équilibreur de charge de s'authentifier auprès du backend. Dans le schéma, les étapes 1 à 3 représentent des ressources créées explicitement, tandis que les étapes 4 et 5 représentent des ressources créées automatiquement.
- 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.
- 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 de confiance intégrée.
- Configurez le service de backend de l'équilibreur de charge avec l'identité gérée.
L'identité de charge de travail gérée crée automatiquement le certificat d'identité gérée du gestionnaire de certificats et la configuration de confiance du gestionnaire de certificats.
Le certificat d'identité gérée du gestionnaire de certificats est créé en fonction de la configuration d'émission de certificat dans le pool d'identités de charge de travail. La configuration de confiance du gestionnaire de certificats est synchronisée avec la configuration de confiance intégrée du pool d'identités de charge de travail.
L'identité de charge de travail gérée crée automatiquement la configuration d'authentification de backend.
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 (X.509-SVID) est également associé à la configuration d'authentification de backend, qui est ensuite utilisée pour s'authentifier auprès du backend.
Pour en savoir plus sur la configuration de mTLS pour le backend à l’aide d’une identité gérée, consultez Configurer mTLS pour le backend à l’aide d’une identité de charge de travail gérée.
Ressources créées lors de mTLS pour le backend à l'aide d'une identité gérée
Comme illustré dans 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 de backend, la configuration de confiance du gestionnaire de certificats ni le certificat du gestionnaire de certificats. 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 de l'identité gérée, en se concentrant sur les ressources créées explicitement et celles créées automatiquement.
Ressources créées explicitement
Les ressources suivantes doivent être créées explicitement lors de la configuration de mTLS pour le backend à l'aide d'une 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'autorités de certification.
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 certificat intégrée.
Pool d'identités de charge de travail
Les identités de charge de travail gérées sont définies dans un pool d'identités de charge de travail, qui sert de domaine de confiance.
Le domaine de confiance représente une limite de sécurité logique au sein de laquelle les charges de travail peuvent s'authentifier et s'autoriser mutuellement à l'aide de leurs ID SPIFFE. Toutes les charges de travail d'un même domaine de confiance partagent une racine de confiance commune, ce qui leur permet de vérifier leurs identités respectives.
Pour utiliser des identités gérées, vous devez configurer le pool d'identités de charge de travail en mode TRUST_DOMAIN. Toutes les identités d'un pool se composent d'un seul espace de noms et d'un identifiant de charge de travail individuel.
Espace de noms
Dans un pool d'identités de charge de travail, les identités de charge de travail gérées sont organisées en limites administratives appelées espaces de noms. Les espaces de noms vous aident à organiser et à accorder l'accès aux identités de charge de travail associées.
Identité de charge de travail gérée
L'identité de charge de travail gérée est basée sur la norme SPIFFE, qui fournit un framework permettant d'identifier, d'authentifier et de sécuriser les communications entre les charges de travail à l'aide d'un ID SPIFFE unique.
Une identité de charge de travail gérée, ou identité gérée, est un identifiant de charge de travail configuré dans un pool d'identités de charge de travail. Elle est associée à une Google Cloud ressource. Chaque identité gérée est identifiée de manière unique par un espace de noms et un identifiant de charge de travail individuel.
Dans le contexte de mTLS pour le backend, l'identité gérée est associée à la ressource de service de backend de l'équilibreur de charge.
La valeur d'une identité gérée est un ID SPIFFE entièrement spécifié qui doit respecter le format suivant :
spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
Un TRUST_DOMAIN_NAME est développé comme suit :
WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog
Pour résumer, les charges de travail Compute Engine, telles que la ressource de service de backend d'un équilibreur de charge, peuvent avoir une identité gérée comme suit :
spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
Règle d'attestation
Une règle d'attestation contient des règles permettant à Google Cloud IAM de vérifier si le service de backend est éligible pour recevoir un certificat X.509 pour l'identité gérée.
Si la validation de la règle d'attestation réussit, IAM demande un certificat X.509 pour l'identité gérée à Certificate Authority Service. Le certificat X.509 est créé dans le pool d'autorités de certification lié à l'identité gérée. CA Service provisionne le certificat par réflexion d'identité, où l'ID SPIFFE configuré est reflété sur un certificat X.509.
Configuration d'émission de certificat 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 fenêtre 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 l'application de la règle d'attestation réussie.
Configuration de confiance intégrée du pool d'identités de charge de travail
Par défaut, vos charges de travail au sein du 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 qui se trouvent dans des domaines de confiance différents 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 une configuration de confiance intégrée qui reconnaît et accepte les certificats d'autres domaines de confiance. Ces certificats sont utilisés pour créer une chaîne de confiance et vérifier 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 du gestionnaire de certificats 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 racines de ce même pool d'autorités de certification. Vous n'avez pas besoin d'ajouter les racines d'autorités de certification du pool à la configuration de confiance intégrée, car cette confiance est déjà intégrée.
Dans le schéma suivant, l'équilibreur de charge et le backend font partie du même domaine de confiance et partagent le même certificat racine. Le certificat racine est utilisé pour créer une chaîne de confiance et vérifier l'identité des charges de travail au sein du domaine de confiance.
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
tlsSettings attribut pointe vers la nouvelle identity propriété
(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'attributtlsSettings:tlsSettings.snitlsSettings.subjectAltNamestlsSettings.authenticationConfig
Le champ
identityne peut être attribué que lors de la création du service de backend.Le champ
identityn'est pas modifiable. Une fois attribué au service de backend de l'équilibreur de charge, il ne peut pas être mis à jour ni supprimé.
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 de l'
API Certificate Manager et de l'API Network Security sont créées
automatiquement par l'identité de charge de travail gérée.
Les ressources créées automatiquement sont créées 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 additionalTrustBundles champ
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 du gestionnaire de certificats 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 mappage où la paire clé/valeur est la suivante :
- La clé peut être à la fois 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 racines de confiance (appelée bundle de confiance) utilisée pour valider les certificats SPIFFE de ce domaine de confiance spécifique.
Ce mappage permet essentiellement de configurer l'équilibreur de charge pour qu'il approuve les magasins de confiance 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 du gestionnaire de certificats (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 du gestionnaire de certificats 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 du gestionnaire de certificats est basé sur la configuration d'émission de certificat 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 du gestionnaire de certificats stocke le X.509-SVID au format encodé en PEM. Ce X.509-SVID contient l'ID SPIFFE encodé sous forme d'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ée du gestionnaire de certificats est CLIENT_AUTH, ce qui indique que ce certificat est utilisé comme certificat client dans mTLS pour le 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 pour le backend entre l'équilibreur de charge et les charges de travail de destination.
Limites
mTLS pour le backend avec une identité de charge de travail gérée ne peut être configuré que pour les équilibreurs de charge d'application externes mondiaux. Les équilibreurs de charge d'application classiques ne sont pas compatibles avec mTLS pour le backend.
mTLS pour le 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 latlsSettingspropriété du service de backend :backendService.tlsSettings.snibackendService.tlsSettings.subjectAltNamesbackendService.tlsSettings.authenticationConfig
L'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 n'est pas modifiable. Une fois attribuée au service de backend de l'équilibreur de charge, elle ne peut pas être mise à jour ni supprimée.