Configurer le protocole TLS mutuel avec une autorité de certification privée

Un certificat client valide doit afficher une chaîne de confiance remontant à l'ancre de confiance dans le magasin de confiance. Cette page explique comment créer votre propre chaîne de confiance à l'aide du certificat racine d'une autorité de certification privée, que vous contrôlez. Dans cette configuration, l'autorité de certification privée est créée à l'aide du service d'autorité de certification.

Après avoir obtenu le certificat racine de l'autorité de certification privée, ce document décrit la procédure d'importation du certificat dans le trust store de la ressource TrustConfig du gestionnaire de certificats. Ensuite, associez 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 gcloud init pour vous authentifier.

  • Consultez le guide pour créer un pool d'autorités de certification.

  • 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

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 TargetHTTPProxy : 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.

Obtenir le certificat de l'autorité de certification racine

L'autorité de certification racine dispose d'un certificat autosigné que vous devez ajouter au magasin de confiance. Le certificat de l'autorité de certification racine se trouve en haut de la chaîne de certificats.

Pour obtenir le certificat de l'autorité de certification racine, vous devez d'abord créer un pool d'autorités de certification, qui est vide lors de la création. Vous devez ensuite créer une autorité de certification racine et l'ajouter au pool d'autorités de certification. L'autorité de certification racine et le pool d'autorités de certification sont créés à l'aide de Certificate Authority Service, comme indiqué dans les étapes suivantes.

  1. Pour créer un pool d'autorités de certification, exécutez la commande gcloud privateca pools create :

    gcloud privateca pools create CA_POOL \
   --location=us-central1

    Remplacez CA_POOL par l'ID ou le nom du pool d'autorités de certification parente.

  2. Pour créer une autorité de certification racine et l'ajouter au pool d'autorités de certification, exécutez la commande gcloud privateca roots create:

    gcloud privateca roots create CA_ROOT \
   --pool=CA_POOL \
   --subject="CN=my-ca, O=Test LLC" \
   --location=us-central1

    Remplacez les éléments suivants :

    • CA_ROOT: ID ou nom de l'autorité de certification racine.
    • CA_POOL: ID ou nom du pool d'autorités de certification parent.

  3. Extrayez le certificat encodé en PEM qui identifie l'autorité de certification racine.

    gcloud privateca roots describe CA_ROOT \
   --pool=CA_POOL \
   --location=us-central1 \
   --format='value(pemCaCertificates)' > root.cert

    Remplacez les éléments suivants :

    • CA_ROOT: ID ou nom de l'autorité de certification privée.
    • CA_POOL: ID ou nom du pool d'autorités de certification parent.

    Le certificat racine (root.cert) doit être importé dans le truststore. Cette étape sera effectuée dans la section suivante.

Pour en savoir plus sur l'utilisation de Certificate Authority Service pour créer un pool d'autorités de certification et une autorité de certification racine, consultez les ressources suivantes:

Mettre en forme le certificat de l'autorité de certification racine

Pour inclure le certificat racine dans un truststore, définissez une mise en forme de ce certificat sur une seule ligne et stockez-le dans une variable d'environnement, afin qu'il puisse être référencé par le fichier YAML de configuration de confiance.

   export ROOT=$(cat root.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. 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. Dans cet exemple, la ressource de configuration de confiance est un truststore avec une seule ancre de confiance qui représente un certificat racine. Ce certificat racine est généré à l'aide de l'autorité de certification privée.

    cat << EOF > trust_config.yaml
name: TRUST_CONFIG_NAME
trustStores:
- trustAnchors:
    - pemCertificate: "${ROOT?}"
EOF

  2. 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}"

Obtenir un certificat client à l'aide d'une requête de signature de certificat

Cette section fournit une option de configuration supplémentaire pour générer un certificat client (d'entité finale) signé par le certificat de l'autorité de certification racine.

Pour obtenir un certificat client, générez une requête de signature de certificat (CSR), puis envoyez-la au pool d'autorités de certification.

  1. Créez un fichier de configuration OpenSSL 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

  2. Exécutez la commande openssl suivante pour générer une CSR (csr.pem) et une clé privée correspondante (key.pem).

    openssl req -newkey \
    -rsa:2048 \
    -config client.config \
    -keyout key.pem \
    -out csr.pem

  3. Exécutez la commande gcloud privateca certificates create suivante pour envoyer la CSR et demander le certificat client X.509 à l'autorité de certification du pool d'autorités de certification.

    gcloud privateca certificates create \
     --issuer-pool CA_POOL \
     --issuer-location=us-central1 \
     --csr csr.pem \
     --cert-output-file CERT_FILENAME

    Remplacez les éléments suivants :

    • CA_POOL: ID ou nom du pool d'autorités de certification.
    • CERT_FILENAME: fichier de chaîne de certificats au format PEM trié de la feuille à la racine.

  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 pour s'authentifier auprès de l'équilibreur de charge.

    curl -v --key key.pem --cert CERT_FILENAME https://IP_ADDRESS

    Remplacez les éléments suivants :

    • CERT_FILENAME: fichier de chaîne de certificats encodé au format PEM trié de la feuille à la racine.
    • IP_ADDRESS: adresse IP de l'équilibreur de charge.

Étape suivante