Configurer un protocole TLS mutuel avec des certificats fournis par l'utilisateur

Un certificat client valide doit afficher une chaîne de confiance remontant à l'ancre de confiance (certificat racine) dans le magasin de confiance. Cette page explique comment créer votre propre chaîne de confiance en configurant vos propres certificats racine et intermédiaires à l'aide de la bibliothèque OpenSSL.

Après avoir créé les racines de confiance, ce document décrit la procédure d'importation dans le magasin de confiance de la ressource TrustConfig du gestionnaire de certificats. Associez ensuite la configuration de confiance à la ressource d'authentification du client (ServerTLSPolicy), puis associez la ressource d'authentification du client à la ressource de proxy HTTPS cible de l'équilibreur de charge.

Avant de commencer

  • Consultez la page Présentation du protocole TLS mutuel.
  • Consultez le guide Gérer les configurations de confiance.

  • Installez Google Cloud CLI. Pour une présentation complète de l'outil, consultez la présentation de gcloud CLI. Vous trouverez des commandes liées à l'équilibrage de charge dans la documentation de référence de l'API et de gcloud CLI.

    Si vous n'avez pas encore utilisé gcloud CLI, exécutez d'abord la commande gcloud init pour vous authentifier.

  • Activez les API suivantes: l'API Compute Engine, l'API Certificate Manager, la sécurité réseau et l'API Network Services. Pour en savoir plus, consultez Activer des API.

  • Si vous utilisez un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique, assurez-vous d'avoir configuré un équilibreur de charge avec l'un des backends compatibles suivants :

    • Backends de groupe d'instances de VM
    • Buckets Cloud Storage (compatibles uniquement si au moins un service de backend est également associé à l'équilibreur de charge, en plus du bucket backend)
    • Cloud Run, App Engine ou Cloud Run Functions
    • Connectivité hybride

  • Si vous utilisez un équilibreur de charge d'application externe régional, un équilibreur de charge d'application interne interrégional ou un équilibreur de charge d'application interne régional, assurez-vous d'avoir configuré un équilibreur de charge avec l'un des backends compatibles suivants :

    • Backends de groupe d'instances de VM
    • Cloud Run
    • Connectivité hybride

  • Définissez votre projet.

    gcloud

    gcloud config set project PROJECT_ID

Autorisations

Pour obtenir les autorisations nécessaires pour suivre ce guide, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le projet :

  • Pour créer des ressources d'équilibreur de charge telles que TargetHTTPSProxy : Administrateur de l'équilibreur de charge Compute (roles/compute.loadBalancerAdmin)
  • Pour utiliser les ressources du gestionnaire de certificats : Propriétaire du gestionnaire de certificats (roles/certificatemanager.owner)
  • Pour créer des composants de sécurité et de mise en réseau, procédez comme suit : Administrateur de réseau Compute (roles/compute.networkAdmin) et Administrateur de sécurité Compute (roles/compute.securityAdmin)
  • Pour créer un projet (facultatif) : Créateur de projet (roles/resourcemanager.projectCreator)

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.

Créer les certificats racine et intermédiaires

Cette section utilise la bibliothèque OpenSSL pour créer le certificat racine (ancre de confiance) et le certificat intermédiaire.

Un certificat racine se trouve au sommet de la chaîne de certificats. Un certificat intermédiaire fait partie de la chaîne de confiance qui remonte au certificat racine. Le certificat intermédiaire est signé de manière cryptographique par le certificat racine. Lorsque l'équilibreur de charge reçoit un certificat client, il le valide en établissant une chaîne de confiance à partir du certificat client jusqu'à l'ancre de confiance configurée.

Utilisez les commandes suivantes pour créer les certificats racine et intermédiaires. La création du certificat intermédiaire est facultative. Toutefois, dans cette configuration, nous utilisons le certificat intermédiaire pour signer le certificat client.

  1. Créez un fichier de configuration OpenSSL.

    Dans l'exemple suivant, le fichier de configuration (example.cnf) contient la section [ca_exts], qui spécifie les extensions X.509 qui marquent le certificat comme adapté à une autorité de certification. Pour en savoir plus sur les exigences concernant les certificats racine et intermédiaires, consultez la section Exigences concernant les certificats.

    cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command line arg.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth

EOF

  2. Créez un certificat racine X.509 autosigné (root.cert). Le certificat racine est autosigné avec sa propre clé privée (root.key).

    openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

  3. Créez la requête de signature de certificat (int.req) pour le certificat intermédiaire.

    openssl req -new \
    -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

  4. Signez la requête de signature de certificat pour créer le certificat intermédiaire X.509 (int.cert). La requête de signature de certificat est signée à l'aide du certificat racine.

    openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

Créer un certificat autosigné pouvant être ajouté à une liste d'autorisation

Vous pouvez créer un certificat autosigné et l'ajouter à une liste d'autorisation dans la configuration de confiance.

Utilisez la commande OpenSSL suivante pour créer un certificat X.509 autosigné.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=localhost' \
       -keyout allowlisted.key -out allowlisted.cert

Ce certificat est ensuite ajouté à un champ allowlistedCertificates dans la configuration de confiance.

Mettre en forme les certificats

Pour inclure de nouveaux certificats ou des certificats existants dans un TrustStore, définissez une mise en forme de ces certificats sur une seule ligne et stockez-les dans des variables d'environnement, afin qu'ils puissent être référencés par le fichier YAML de configuration de confiance.

export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Pour inclure de nouveaux certificats ou des certificats existants ajoutés à une liste d'autorisation dans une configuration de confiance, définissez une mise en forme de ces certificats sur une seule ligne et stockez-les dans des variables d'environnement, afin qu'ils puissent être lus dans le fichier YAML. Pour les certificats figurant sur une liste d'autorisation, utilisez la commande suivante pour les mettre en forme sur une seule ligne et les stocker dans la variable d'environnement ALLOWLISTED_CERT.

export ALLOWLISTED_CERT=$(cat allowlisted.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Créer une ressource de configuration de confiance

Une configuration de confiance est une ressource qui représente votre configuration d'infrastructure à clé publique (PKI) dans le gestionnaire de certificats.

Pour créer une ressource de configuration de confiance, procédez comme suit:

Console

  1. Dans la console Google Cloud , accédez à la page Gestionnaire de certificats.

    Accéder au Gestionnaire de certificats

  2. Dans l'onglet Configurations d'approbation, cliquez sur Ajouter une configuration d'approbation.

  3. Attribuez un nom à la configuration.

  4. Pour Emplacement, sélectionnez Mondial ou Régional.

    L'emplacement indique l'emplacement de stockage de la ressource de configuration de confiance. Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, créez une ressource de configuration de confiance globale. Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, créez une ressource de configuration de confiance régionale.

    Si vous avez sélectionné Régional, sélectionnez la région.

  5. Dans la section Truststore (Truststore), cliquez sur Add trust anchor (Ajouter une ancre de confiance) et importez le fichier de certificat encodé au format PEM ou copiez le contenu du certificat.

  6. Cliquez sur Ajouter.

  7. Dans la section Truststore (Truststore), cliquez sur Add intermediate CA (Ajouter une autorité de certification intermédiaire) et importez le fichier de certificat encodé au format PEM ou copiez le contenu du certificat.

    Cette étape vous permet d'ajouter un autre niveau de confiance entre le certificat racine et votre certificat de serveur.

  8. Cliquez sur Add (Ajouter) pour ajouter l'autorité de certification intermédiaire.

  9. Facultatif: dans la section Certificats de la liste d'autorisation, cliquez sur Ajouter un certificat et importez le fichier de certificat encodé au format PEM ou copiez le contenu du certificat.

  10. Cliquez sur Ajouter pour ajouter le certificat à la liste d'autorisation.

  11. Cliquez sur Créer.

Vérifiez que la nouvelle ressource de configuration de confiance apparaît dans la liste des configurations.

gcloud

  1. Créez un fichier YAML de configuration de confiance (trust_config.yaml) qui spécifie les paramètres de configuration de confiance. Cet exemple de ressource de configuration de confiance contient un truststore avec une ancre de confiance et un certificat intermédiaire. Il lit le contenu du certificat à partir des variables d'environnement créées à l'étape précédente, Mettre en forme les certificats.

    cat << EOF > trust_config.yaml
trustStores:
- trustAnchors:
  - pemCertificate: "${ROOT_CERT?}"
  intermediateCas:
  - pemCertificate: "${INTERMEDIATE_CERT?}"
EOF

    Pour créer un truststore avec d'autres ancres de confiance ou d'autres certificats CA intermédiaires, ajoutez des lignes pemCertificate dans la section appropriée.

  2. Facultatif: spécifiez le certificat ajouté au fichier YAML de configuration de confiance dans le champ allowlistedCertificates. Vous n'avez pas besoin d'un magasin de confiance pour ajouter un certificat à une liste d'autorisation.

    cat << EOF >> trust_config.yaml
allowlistedCertificates:
- pemCertificate: "${ALLOWLISTED_CERT?}"
EOF

    Un certificat ajouté à une liste d'autorisation représente tout certificat pouvant être encapsulé dans la configuration de confiance afin qu'il soit toujours considéré comme valide. Vous pouvez spécifier plusieurs certificats dans une liste d'autorisation à l'aide de plusieurs instances du champ pemCertificate.

  3. Pour importer le fichier YAML de configuration de confiance, utilisez la commande gcloud certificate-manager trust-configs import:

    global

    Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, spécifiez global comme emplacement où la ressource de configuration de confiance est stockée.

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
    --source=trust_config.yaml \
    --location=global

    Remplacez les éléments suivants :

    • TRUST_CONFIG_NAME: nom de la ressource de configuration de confiance.

    régional

    Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, spécifiez la région dans laquelle la ressource de configuration de confiance est stockée.

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
    --source=trust_config.yaml \
    --location=LOCATION

    Remplacez les éléments suivants :

    • TRUST_CONFIG_NAME: nom de la ressource de configuration de confiance.
    • LOCATION: région où la ressource de configuration de confiance est stockée. L'emplacement par défaut est global.

Créer une ressource d'authentification client

Une ressource d'authentification client (également appelée ServerTLSPolicy) vous permet de spécifier le mode TLS côté serveur et la ressource de configuration de confiance à utiliser lors de la validation des certificats clients. Lorsque le client présente un certificat non valide ou aucun certificat à l'équilibreur de charge, clientValidationMode spécifie la manière dont la connexion client est gérée. Pour en savoir plus, consultez la section Modes de validation des clients mTLS.

  • Lorsque clientValidationMode est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT, toutes les requêtes sont transmises au backend même si la validation échoue ou si le certificat client est manquant.
  • Lorsque clientValidationMode est défini sur REJECT_INVALID, seules les requêtes fournissant un certificat client pouvant être validé sur une ressource TrustConfig sont transmises au backend.

Pour créer une ressource Authentification client (ServerTlsPolicy), procédez comme suit:

Console

  1. Dans la console Google Cloud , accédez à la page Authentification client.

    Accéder à "Authentification client"

  2. Cliquez sur Créer une authentification client.

  3. Saisissez un nom pour la ressource d'authentification client.

  4. Pour Emplacement, sélectionnez Mondial ou Régional.

    Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, définissez l'emplacement sur "global". Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, définissez l'emplacement sur la région dans laquelle l'équilibreur de charge est configuré.

  5. Pour Mode d'authentification client, sélectionnez Équilibrage de charge.

  6. Sélectionnez un mode de validation client.

  7. Sélectionnez la ressource de configuration de confiance que vous avez créée précédemment.

  8. Cliquez sur Créer.

Vérifiez que l'authentification client (ServerTlsPolicy) s'affiche.

gcloud

  1. Selon la manière dont vous souhaitez gérer la connexion, sélectionnez l'une des options suivantes pour définir la ressource d'authentification du client (ServerTlsPolicy) au format YAML.

    • Option 1 : clientValidationMode est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

      global

      Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, créez un fichier YAML qui spécifie de manière déclarative le mode de validation du client et une ressource de configuration de confiance globale:

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
EOF

      régional

      Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, créez un fichier YAML qui spécifie de manière déclarative le mode de validation du client et une ressource de configuration de confiance régionale:

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

    • Option 2 : clientValidationMode est défini sur REJECT_INVALID.

      global

      Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, créez un fichier YAML qui spécifie de manière déclarative le mode de validation du client et une ressource de configuration de confiance globale:

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: REJECT_INVALID
    clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
EOF

      régional

      Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, créez un fichier YAML qui spécifie de manière déclarative le mode de validation du client et une ressource de configuration de confiance régionale:

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
      clientValidationMode: REJECT_INVALID
      clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

      Remplacez les éléments suivants :

      SERVER_TLS_POLICY_NAME: nom de la ressource d'authentification client (ServerTlsPolicy).

      PROJECT_ID: ID de votre projet Google Cloud .

      LOCATION: pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, utilisez global. Pour l'équilibreur charge d'application externe régional ou l'équilibreur de charge d'application interne régional, utilisez la région dans laquelle vous avez configuré l'équilibreur de charge.

      TRUST_CONFIG_NAME: nom de la ressource de configuration de confiance que vous avez créée précédemment.

  2. Pour importer la ressource ServerTlsPolicy d'authentification client, utilisez la commande gcloud network-security server-tls-policies import:

    global

    Pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, définissez l'indicateur --location sur global.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
  --source=server_tls_policy.yaml \
  --location=global

    Remplacez les éléments suivants :

    SERVER_TLS_POLICY_NAME: nom de la ressource d'authentification client (ServerTlsPolicy).

    régional

    Pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, définissez l'indicateur --location sur la région dans laquelle l'équilibreur de charge est configuré.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
  --source=server_tls_policy.yaml \
  --location=LOCATION

    Remplacez les éléments suivants :

    SERVER_TLS_POLICY_NAME: nom de la ressource d'authentification client (ServerTlsPolicy).

  3. Facultatif: Pour répertorier toutes les ressources Authentification client (ServerTlsPolicies), utilisez la commande gcloud network-security server-tls-policies list:

    gcloud network-security server-tls-policies list \
  --location=LOCATION

    Remplacez les éléments suivants :

    LOCATION: pour les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application internes interrégionaux, utilisez global. Pour l'équilibreur de charge d'application externe régional ou l'équilibreur de charge d'application interne régional, utilisez la région dans laquelle vous avez configuré l'équilibreur de charge.

Associer la ressource d'authentification client à l'équilibreur de charge

Pour que l'authentification TLS mutuelle fonctionne, une fois que vous avez configuré votre équilibreur de charge, vous devez associer la ressource d'authentification du client (ServerTLSPolicy) à la ressource de proxy HTTPS cible de l'équilibreur de charge.

Console

  1. Dans la console Google Cloud , accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Dans la liste des équilibreurs de charge, sélectionnez celui auquel vous devez associer la ressource d'authentification client (ServerTLSPolicy).

  3. Cliquez sur Modifier ().

  4. Dans la section Configuration du frontend d'un frontend HTTPS, développez la section Afficher les fonctionnalités avancées.

  5. Dans la liste Authentification client, sélectionnez la ressource d'authentification client.

  6. Cliquez sur OK.

  7. Cliquez sur Update (Mettre à jour).

gcloud

  1. Pour répertorier toutes les ressources de proxy HTTPS cibles de votre projet, utilisez la commande gcloud compute target-https-proxies list:

    gcloud compute target-https-proxies list

    Notez le nom du proxy HTTPS cible auquel associer la ressource ServerTLSPolicy. Ce nom sera appelé TARGET_HTTPS_PROXY_NAME dans les étapes suivantes.

  2. Pour exporter la configuration d'un proxy HTTPS cible vers un fichier, utilisez la commande gcloud compute target-https-proxies export.

    global

      gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
      --destination=TARGET_PROXY_FILENAME \
      --global

    Remplacez les éléments suivants :

    • TARGET_HTTPS_PROXY_NAME : nom du proxy cible.
    • TARGET_PROXY_FILENAME: nom du fichier de configuration du proxy cible au format YAML. Exemple :mtls_target_proxy.yaml

    régional

    gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
    --destination=TARGET_PROXY_FILENAME \
    --region=REGION

    Remplacez les éléments suivants :

    • TARGET_HTTPS_PROXY_NAME : nom du proxy cible.
    • TARGET_PROXY_FILENAME: nom du fichier de configuration du proxy cible au format YAML. Par exemple, mtls_target_proxy.yaml.
    • REGION : région dans laquelle vous avez configuré l'équilibreur de charge.

  3. Pour répertorier toutes les ressources Authentification client (ServerTlsPolicy), utilisez la commande gcloud network-security server-tls-policies list :

    gcloud network-security server-tls-policies list \
    --location=LOCATION

    Remplacez les éléments suivants :

    LOCATION: pour l'équilibreur de charge d'application interne interrégional, l'équilibreur de charge d'application externe global ou l'équilibreur de charge d'application classique, utilisez global. Pour l'équilibreur de charge d'application externe régional ou l'équilibreur de charge d'application interne régional, utilisez la région dans laquelle vous avez configuré l'équilibreur de charge.

    Notez le nom de la ressource d'authentification client (ServerTLSPolicy) pour configurer l'authentification mTLS. Ce nom sera appelé SERVER_TLS_POLICY_NAME à l'étape suivante.

  4. Ajoutez l'authentification client (ServerTlsPolicy) au proxy HTTPS cible.

    echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME

    Remplacez les éléments suivants :

    • PROJECT_ID: ID de votre projet Google Cloud .
    • LOCATION: pour les équilibreurs de charge d'application externes globaux ou les équilibreurs de charge d'application classiques, et les équilibreurs de charge d'application internes interrégionaux, utilisez global. Pour l'équilibreur de charge d'application externe régional ou l'équilibreur de charge d'application interne régional, utilisez la région dans laquelle vous avez configuré l'équilibreur de charge.
    • SERVER_TLS_POLICY_NAME: nom de la ressource d'authentification client (ServerTLSPolicy).
    • TARGET_PROXY_FILENAME: nom du fichier de configuration du proxy cible au format YAML.

  5. Pour importer la configuration d'un proxy HTTPS cible à partir d'un fichier, utilisez la commande gcloud compute target-https-proxies import :

    global

      gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
      --source=TARGET_PROXY_FILENAME \
      --global

    Remplacez les éléments suivants :

    • TARGET_HTTPS_PROXY_NAME : nom du proxy cible.
    • TARGET_PROXY_FILENAME: nom du fichier de configuration du proxy cible au format YAML. Exemple :mtls_target_proxy.yaml

    régional

      gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
      --source=TARGET_PROXY_FILENAME \
      --region=REGION

    Remplacez les éléments suivants :

    • TARGET_HTTPS_PROXY_NAME : nom du proxy cible.
    • TARGET_PROXY_FILENAME: nom du fichier de configuration du proxy cible au format YAML. Par exemple, mtls_target_proxy.yaml.
    • REGION : région dans laquelle vous avez configuré l'équilibreur de charge.

Ajouter des en-têtes mTLS personnalisés

Lorsque vous activez mTLS, vous pouvez transmettre des informations sur la connexion mTLS à l'aide d'en-têtes personnalisés. Vous pouvez également activer la journalisation afin que les échecs de connexion mTLS soient capturés dans les journaux.

Ajouter des en-têtes mTLS personnalisés aux services de backend

Pour les équilibreurs de charge d'application externes globaux ou classiques, vous pouvez utiliser des en-têtes personnalisés pour transmettre des informations sur la connexion mTLS aux services de backend.

  1. Pour répertorier tous les services de backend du projet, exécutez la commande gcloud compute backend-services list :

    gcloud compute backend-services list

    Notez le nom du service de backend pour activer les en-têtes et la journalisation personnalisés. Ce nom est appelé BACKEND_SERVICE à l'étape suivante.

  2. Pour mettre à jour le service de backend, utilisez la commande gcloud compute backend-services update :

    gcloud compute backend-services update BACKEND_SERVICE \
  --global \
  --enable-logging \
  --logging-sample-rate=1 \
  --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
  --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
  --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
  --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
  --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
  --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
  --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
  --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
  --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
  --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'

Ajouter des en-têtes mTLS personnalisés au mappage d'URL

Pour les équilibreurs de charge d'application internes interrégionaux, les équilibreurs de charge d'application externes régionaux ou les équilibreurs de charge d'application internes régionaux, vous pouvez utiliser des en-têtes personnalisés pour transmettre des informations sur la connexion mTLS au mappage d'URL.

Pour répertorier tous les mappages d'URL du projet, exécutez la commande gcloud compute url-maps list :

   gcloud compute url-maps list

Notez le nom du mappage d'URL pour activer les en-têtes et la journalisation personnalisés. Ce nom est appelé URL_MAP_NAME à l'étape suivante.

global

Pour modifier le mappage d'URL d'un équilibreur de charge d'application interne interrégional, utilisez la commande gcloud compute url-maps edit :

   gcloud compute url-maps edit URL_MAP_NAME --global

Voici un exemple de fichier YAML qui montre comment utiliser des variables dans des en-têtes de requête personnalisés (requestHeadersToAdd). Vous pouvez utiliser les mêmes variables pour envoyer des en-têtes de réponse personnalisés (responseHeadersToAdd).

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"

régional

Pour modifier le mappage d'URL d'un équilibreur de charge d'application externe régional ou d'un équilibreur de charge d'application interne régional, utilisez la commande gcloud compute url-maps edit :

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION

Voici un exemple de fichier YAML qui montre comment utiliser des variables dans des en-têtes de requête personnalisés (requestHeadersToAdd). Vous pouvez utiliser les mêmes variables pour envoyer des en-têtes de réponse personnalisés (responseHeadersToAdd).

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"

Signer le certificat client avec le certificat intermédiaire

Cette section fournit une option de configuration supplémentaire pour générer un certificat client (d'entité finale). Si vous avez déjà créé une ressource TrustConfig contenant un certificat intermédiaire, procédez comme suit:

  1. Créez un fichier de configuration pour générer la CSR du certificat client.

    Le fichier de configuration suivant (client.config) contient la section [extension_requirements], qui spécifie les extensions X.509 à inclure dans la CSR. Pour en savoir plus sur les exigences concernant les certificats client, consultez Exigences concernant les certificats.

    cat > client.config << EOF
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical, CA:FALSE
keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage          = clientAuth

[dn_requirements]
countryName               = US
stateOrProvinceName       = California
localityName              = San Francisco
0.organizationName        = example
organizationalUnitName    = test
commonName                = test.example.com
emailAddress              = test@example.com

EOF

    Si vous souhaitez associer une identité SPIFFE au fichier de configuration, procédez comme suit:

    • Ajoutez un champ subjectAltName à la section [extension_requirements] comme suit:

      subjectAltName            = @sans_list

    • Ajoutez une section ([sans_list]) au bas du fichier client.config comme suit:

      [sans_list]
URI.1                     = spiffe://example.com/test-identity

  2. Créez la CSR (client.csr) pour le certificat client.

    openssl req -new \
    -config client.config \
    -keyout client.key -out client.csr

  3. Signez la CSR pour émettre le certificat client X.509 (client.cert). La CSR est signée par le certificat intermédiaire.

    openssl x509 -req \
    -CAkey int.key -CA int.cert \
    -days 365 \
    -extfile client.config \
    -extensions extension_requirements \
    -in client.csr -out client.cert

  4. Envoyez une requête HTTPS sécurisée à l'adresse IP de l'équilibreur de charge à l'aide du certificat SSL côté client. Le client présente son certificat (client.cert) pour s'authentifier auprès de l'équilibreur de charge.

    curl -v --key client.key --cert client.cert https://IP_ADDRESS

    Remplacez IP_ADDRESS par l'adresse IP de l'équilibreur de charge.

Étape suivante