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

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 de Certificate Authority Service.

Vous pouvez également implémenter l'authentification mTLS du backend 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.

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

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.

Authentification mTLS du backend à l'aide d'identités de charge de travail gérées.
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 l'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 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.

Exigences relatives aux certificats

Lorsque vous configurez des certificats, assurez-vous qu'ils respectent les exigences suivantes :

  • Les outils de cryptographie modernes constituent la base de l'authentification mTLS. Les certificats doivent utiliser des algorithmes RSA ou ECDSA pour l'échange de clés. Les algorithmes de hachage doivent utiliser SHA-256 ou une fonction de hachage cryptographique plus sécurisée. Les algorithmes de hachage tels que MD4, MD5 et SHA-1 ne sont pas acceptés.

  • Les certificats de serveur feuille fournis par le backend doivent répondre aux exigences suivantes :

  • Les certificats clients de feuille (équilibreur de charge) utilisés dans le mTLS de backend sont les certificats d'identité gérés par Certificate Manager créés automatiquement. Ils doivent répondre automatiquement aux exigences suivantes :

  • Pour authentifier les certificats de serveur que votre backend présente à l'équilibreur de charge, les certificats racine et intermédiaires situés dans la configuration de confiance doivent répondre aux exigences suivantes :

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 un 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é par 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 diagramme, 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 certificats intégrée et une ressource de configuration de confiance 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 de Certificate Manager et la configuration de confiance de 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 Certificate Manager est associée à la configuration d'authentification de backend. Le certificat d'identité gérée 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.

Authentification 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 de l'authentification mTLS du backend à l'aide d'une identité gérée

Comme le montre le diagramme de l'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.

Pool d'identité 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 dans 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 valider mutuellement leurs identités.

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 les identités de charge de travail associées et à leur accorder l'accès.

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 une 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 ressourceGoogle Cloud . 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 l'obtention du mTLS de 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

spiffe

Règles d'attestation

Une stratégie d'attestation contient des règles permettant à Google Cloud IAM de vérifier si le service de backend est éligible à la réception d'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 au Certificate Authority Service. 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 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 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, vous devez créer 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.

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 permet de créer une chaîne de confiance et de valider l'identité des charges de travail dans le domaine de confiance.

Hiérarchie des ressources d'identité de charge de travail gérée.
Hiérarchie des ressources d'identité de charge de travail gérée (cliquez pour agrandir)

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 attribuée au service de backend de l'équilibreur de charge, elle ne peut plus être modifiée ni supprimée.

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 Certificate Manager 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 en savoir plus, consultez Vérifier que la configuration de confiance du Certificate Manager contient le champ spiffeTrustStores.

Pour en savoir plus sur la façon dont le champ spiffeTrustStores de la configuration de confiance de Certificate Manager permet de valider les certificats SPIFFE, consultez Étapes de validation du certificat de serveur.

Certificat d'identité gérée du gestionnaire de certificats (API Certificate Manager)

Le certificat d'identité gérée du Certificate Manager 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 Certificate Manager 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 Certificate Manager 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 Certificate Manager est associée à la configuration d'authentification de backend.

Le certificat d'identité gérée du Certificate Manager 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.

Étapes de validation du certificat de serveur

Lors de la validation du certificat de serveur pendant l'authentification mTLS du backend, l'équilibreur de charge effectue les opérations suivantes :

  1. Vérifiez que le serveur possède la clé privée du certificat.

    Le serveur prouve qu'il possède la clé privée associée au certificat qu'il présente à l'équilibreur de charge en signant une information à l'aide de sa clé privée et en l'envoyant à l'équilibreur de charge dans le message CertificateVerify. L'équilibreur de charge valide ensuite cette signature à l'aide de la clé publique du certificat du serveur. Si la validation de la signature échoue, cela indique que le serveur backend ne possède pas la clé privée correspondant au certificat. Dans ce cas, l'équilibreur de charge met fin au handshake TLS sans enregistrer d'erreur.

  2. Vérifiez la chaîne de confiance.

    Le champ spiffeTrustStores de la configuration de confiance Certificate Manager permet de 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 approuvé associé à un pool d'identités de charge de travail (au format se terminant par .workload.id.goog) ou un domaine approuvé 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 avec des magasins de confiance provenant de plusieurs domaines de sécurité distincts. Lorsqu'un backend présente son certificat SPIFFE, l'équilibreur de charge extrait l'ID SPIFFE, identifie le domaine de confiance et utilise la carte spiffeTrustStores pour rechercher le magasin de confiance approprié afin de vérifier la chaîne de confiance et de valider le certificat.

    Les vérifications incluent les éléments suivants :

    • Le certificat de serveur du backend, les certificats intermédiaires (le cas échéant) et le certificat racine configuré sont conformes aux exigences relatives aux certificats.
    • Pour tous les certificats de la chaîne de confiance, le champ "Objet" du certificat parent correspond au champ "Émetteur" du certificat enfant. Cette vérification permet de s'assurer que l'identité (sujet) du certificat parent est identique à celle indiquée comme émetteur dans le certificat enfant.
    • Pour tous les certificats de la chaîne de confiance, l'identifiant de la clé de l'objet (SKID) du certificat parent correspond à l'identifiant de la clé d'autorité (AKID) dans le certificat enfant. Cette correspondance confirme que le certificat enfant a été émis par la bonne autorité racine et qu'il peut être considéré comme fiable, car la clé publique de la racine est référencée dans l'AKID pour vérifier la validité du certificat.

  3. Établissez une connexion avec le backend.

    Si la validation du certificat réussit, l'équilibreur de charge poursuit la connexion au backend.

    Toutefois, si la validation du certificat échoue, l'équilibreur de charge met fin à la connexion au backend, envoie un code d'état HTTP 502 au client et enregistre la raison de l'arrêt dans Cloud Logging. En cas d'erreur de validation du certificat, les requêtes entrantes ultérieures déclenchent la réinitialisation de la connexion au backend par l'équilibreur de charge.

    La connexion au backend peut également échouer si le serveur backend refuse la connexion. Avec l'authentification mTLS du backend, cela peut se produire si le certificat client est considéré comme non valide. Lorsque la connexion au backend échoue, l'équilibreur de charge répond aux requêtes proxy avec un code d'état HTTP 502 et enregistre une raison d'erreur générique dans Cloud Logging.

Gestion des erreurs et journalisation

Les équilibreurs de charge d'application fournissent des fonctionnalités de journalisation détaillées qui vous permettent de surveiller la validation des certificats de serveur, d'identifier les problèmes potentiels et de résoudre les problèmes de connexion. Cette section décrit les différents types d'erreurs pouvant survenir lors de la validation mTLS et la façon dont elles sont consignées.

Si la validation du certificat du serveur échoue, la connexion est interrompue et les erreurs sont consignées dans Cloud Logging. Ces erreurs sont décrites dans le tableau suivant.

État du certificat de serveur Erreur consignée
La chaîne de certificats de serveur est trop longue (plus de 10 certificats intermédiaires inclus dans le certificat de serveur). server_cert_chain_exceeded_limit

La taille d'une clé RSA d'un certificat intermédiaire ou de serveur n'est pas valide.

Aucune validation n'est effectuée.

Les clés RSA peuvent aller de 2 048 à 4 096 bits.

 server_cert_invalid_rsa_key_size

Un certificat intermédiaire ou de serveur utilise une courbe elliptique non compatible.

Aucune validation n'est effectuée.

Les courbes valides sont P-256 et P-384.

 server_cert_unsupported_elliptic_curve_key

Un certificat intermédiaire ou de serveur utilise un algorithme non RSA ou ECDSA.

Aucune validation n'est effectuée.

 server_cert_unsupported_key_algorithm

L'infrastructure PKI à utiliser pour la validation dispose de plus de 10 certificats intermédiaires qui partagent les mêmes informations "Subject" et "Subject Public Key Info".

Aucune validation n'est effectuée.

 server_cert_pki_too_large

Un certificat intermédiaire fourni pour la validation comportait plus de 10 contraintes de nom.

server_cert_chain_max_name_constraints_exceeded

Le certificat de serveur comporte un champ d'extension Extended Key Usage (EKU), mais ce champ n'inclut pas serverAuth.

server_cert_chain_invalid_eku
Le délai avant expiration est dépassé lors de la tentative de validation de la chaîne de certificats. server_cert_validation_timed_out

La limite de profondeur ou d'itération est atteinte lors de la tentative de validation de la chaîne de certificats.

La profondeur maximale pour une chaîne de certificats est de 10, y compris les certificats racine et de serveur. Le nombre maximal d'itérations est de 100 (certificats examinés pour valider la chaîne de certificats de serveur).

 server_cert_validation_search_limit_exceeded

Vous avez configuré mTLS sans configurer de ressource TrustConfig.

 server_cert_validation_not_performed

Le serveur n'a pas fourni le certificat demandé lors du handshake.

 server_cert_not_provided

La validation du certificat serveur a échoué avec la ressource TrustConfig.

 ssl_certificate_verification_failed

Le service ne peut pas effectuer la validation de la chaîne de certificats.

 server_cert_validation_unavailable
Erreur interne de validation de la chaîne de certificats. server_cert_validation_internal_error

Correspondance TrustConfig introuvable.

 server_cert_trust_config_not_found
La charge utile du certificat de serveur (y compris les certificats intermédiaires) est trop volumineuse (plus de 16 Ko). server_cert_exceeded_size_limit

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.

Étapes suivantes