Configurar mTLS de frontend con certificados proporcionados por el usuario

Un certificado de cliente válido debe mostrar una cadena de confianza que se remonte al ancla de confianza (certificado raíz) en el almacén de confianza. En esta página se explica cómo crear tu propia cadena de confianza configurando tus propios certificados raíz e intermedios con la biblioteca OpenSSL.

Después de crear las raíces de confianza, en este documento se describe el proceso para subirlas al almacén de confianza del recurso TrustConfigCertificate Manager. A continuación, se vincula la configuración de confianza al recurso de autenticación de cliente (ServerTLSPolicy) y, después, se adjunta el recurso de autenticación de cliente al recurso de proxy HTTPS de destino del balanceador de carga.

Antes de empezar

  • Consulta la descripción general de TLS mutuo.
  • Consulta la guía para gestionar las configuraciones de confianza.

  • Instala Google Cloud CLI. Para obtener una descripción general completa de la herramienta, consulta la información general sobre la CLI de gcloud. Puedes encontrar comandos relacionados con el balanceo de carga en la referencia de la API y de la CLI de gcloud.

    Si no has ejecutado la CLI de gcloud anteriormente, ejecuta primero el comando gcloud init para autenticarte.

  • Habilita las siguientes APIs: API de Compute Engine, API de Certificate Manager, Network Security y API de Network Services. Para obtener más información, consulta Habilitar APIs.

  • Si usas un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico, asegúrate de haber configurado un balanceador de carga con alguno de los siguientes backends admitidos:

    • Backends de grupos de instancias de VM
    • Segmentos de Cloud Storage (Solo se admite si hay al menos un servicio de backend asociado al balanceador de carga, además del segmento de backend)
    • Cloud Run, App Engine o Cloud Run Functions
    • Conectividad híbrida
    • Back-ends de Private Service Connect

  • Si usas un balanceador de carga de aplicaciones externo regional, un balanceador de carga de aplicaciones interno entre regiones o un balanceador de carga de aplicaciones interno regional, asegúrate de haber configurado un balanceador de carga con cualquiera de los siguientes backends admitidos:

    • Backends de grupos de instancias de VM
    • Cloud Run
    • Conectividad híbrida
    • Back-ends de Private Service Connect

  • Configura el proyecto.

    gcloud

    gcloud config set project PROJECT_ID

Permisos

Para obtener los permisos que necesitas para completar esta guía, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en el proyecto:

  • Para crear recursos de balanceador de carga, como TargetHTTPSProxy, haz lo siguiente: Administrador de balanceadores de carga de Compute (roles/compute.loadBalancerAdmin)
  • Para usar los recursos de Certificate Manager, debes tener uno de los siguientes roles: Propietario de Certificate Manager (roles/certificatemanager.owner)
  • Para crear componentes de seguridad y de red, sigue estos pasos: Administrador de red de Compute (roles/compute.networkAdmin) y administrador de seguridad de Compute (roles/compute.securityAdmin)
  • Para crear un proyecto (opcional): Creador de proyectos (roles/resourcemanager.projectCreator)

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Crear los certificados raíz e intermedio

En esta sección se usa la biblioteca OpenSSL para crear el certificado raíz (ancla de confianza) y el certificado intermedio.

Un certificado raíz se encuentra en la parte superior de la cadena de certificados. Un certificado intermedio forma parte de la cadena de confianza que lleva al certificado raíz. El certificado intermedio está firmado criptográficamente por el certificado raíz. Cuando el balanceador de carga recibe un certificado de cliente, lo valida estableciendo una cadena de confianza desde el certificado de cliente hasta el ancla de confianza configurada.

Usa los siguientes comandos para crear los certificados raíz e intermedio. La creación del certificado intermedio es opcional. Sin embargo, en esta configuración, usamos el certificado intermedio para firmar el certificado de cliente.

  1. Crea un archivo de configuración de OpenSSL.

    En el siguiente ejemplo, el archivo de configuración (example.cnf) contiene la sección [ca_exts], que especifica las extensiones X.509 que marcan el certificado como adecuado para una AC. Para obtener más información sobre los requisitos de los certificados raíz e intermedios, consulta los requisitos de los certificados.

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

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

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

EOF

  2. Crea un certificado raíz X.509 con firma automática (root.cert). El certificado raíz se firma automáticamente con su propia clave privada (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. Crea la solicitud de firma de certificado (int.req) del certificado intermedio.

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

  4. Firma la CSR para crear el certificado intermedio X.509 (int.cert). La CSR se firma con el certificado raíz.

    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

Crear un certificado autofirmado que se pueda añadir a una lista de permitidos

Puedes crear un certificado autofirmado y añadirlo a una lista de permitidos en la configuración de confianza.

Usa el siguiente comando de OpenSSL para crear un certificado X.509 autofirmado.

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

A continuación, este certificado se añade a un campo allowlistedCertificates en la configuración de confianza.

Dar formato a los certificados

Para incluir certificados nuevos o ya creados en un TrustStore, formatea los certificados en una sola línea y guárdalos en variables de entorno para que se pueda hacer referencia a ellos en el archivo YAML de configuración de confianza.

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')

Para incluir en una configuración de confianza certificados nuevos o ya disponibles que se hayan añadido a una lista de permitidos, formatea los certificados en una sola línea y guárdalos en variables de entorno para que se puedan leer en el archivo YAML. En el caso de los certificados que estén en una lista de permitidos, usa el siguiente comando para dar formato a los certificados en una sola línea y almacenarlos en la variable de entorno ALLOWLISTED_CERT.

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

Crear un recurso de configuración de confianza

Una configuración de confianza es un recurso que representa tu configuración de infraestructura de clave pública (PKI) en Certificate Manager.

Para crear un recurso de configuración de confianza, sigue estos pasos:

Consola

  1. En la Google Cloud consola, ve a la página Gestor de certificados.

    Ir a Certificate Manager

  2. En la pestaña Configuraciones de confianza, haz clic en Añadir configuración de confianza.

  3. Introduce un nombre para la configuración.

  4. En Ubicación, selecciona Global o Regional.

    La ubicación indica dónde se almacena el recurso de configuración de confianza. En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, crea un recurso global trust config. En el caso de los balanceadores de carga de aplicación externos regionales y los balanceadores de carga de aplicación internos regionales, crea un recurso de configuración de confianza regional.

    Si has seleccionado Regional, selecciona la región.

  5. En la sección Almacén de confianza, haz clic en Añadir ancla de confianza y sube el archivo de certificado codificado en PEM o copia el contenido del certificado.

  6. Haz clic en Añadir.

  7. En la sección Almacén de confianza, haz clic en Añadir AC intermedia y sube el archivo de certificado codificado en PEM o copia el contenido del certificado.

    Este paso te permite añadir otro nivel de confianza entre el certificado raíz y el certificado de tu servidor.

  8. Haz clic en Añadir para añadir la CA intermedia.

  9. Opcional: En la sección Certificados incluidos en la lista de permitidos, haz clic en Añadir certificado y sube el archivo de certificado codificado en PEM o copia el contenido del certificado.

  10. Haz clic en Añadir para añadir el certificado a la lista de permitidos.

  11. Haz clic en Crear.

Comprueba que el nuevo recurso de configuración de confianza aparezca en la lista de configuraciones.

gcloud

  1. Crea un archivo YAML de configuración de confianza (trust_config.yaml) que especifique los parámetros de configuración de confianza. Este ejemplo de configuración de confianza resource contiene un almacén de confianza con un ancla de confianza y un certificado intermedio. Lee el contenido del certificado de las variables de entorno creadas en el paso anterior Formatear los certificados.

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

    Para crear un almacén de confianza con anclas de confianza o certificados intermedios adicionales, añada filas pemCertificate en la sección correspondiente.

  2. Opcional: Especifica el certificado que se añade al archivo YAML de configuración de confianza en el campo allowlistedCertificates. No necesitas un almacén de confianza para añadir un certificado a una lista de permitidas.

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

    Un certificado que se añade a una lista de permitidos representa cualquier certificado que se pueda encapsular en la configuración de confianza para que siempre se considere válido. Puedes especificar varios certificados en una lista de permitidos usando varias instancias del campo pemCertificate.

  3. Para importar el archivo YAML de configuración de confianza, usa el comando gcloud certificate-manager trust-configs import:

    Mundial

    En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, especifica global como la ubicación en la que se almacena el recurso de configuración de confianza.

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

    Haz los cambios siguientes:

    • TRUST_CONFIG_NAME: el nombre del recurso de configuración de confianza.

    regional

    En el caso de los balanceadores de carga de aplicaciones externos regionales y los balanceadores de carga de aplicaciones internos regionales, especifica la región en la que se almacena el recurso de configuración de confianza.

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

    Haz los cambios siguientes:

    • TRUST_CONFIG_NAME: el nombre del recurso de configuración de confianza.
    • LOCATION: la región en la que se almacena el recurso de configuración de confianza. La ubicación predeterminada es global.

Crear un recurso ClientAuthentication

Un recurso de autenticación de cliente (también llamado ServerTLSPolicy) te permite especificar el modo TLS del lado del servidor y el recurso de configuración de confianza que se debe usar al validar los certificados de cliente. Cuando el cliente presenta un certificado no válido o ningún certificado al balanceador de carga, clientValidationMode especifica cómo se gestiona la conexión del cliente. Para obtener más información, consulta Modos de validación de clientes de mTLS.

  • Si clientValidationMode tiene el valor ALLOW_INVALID_OR_MISSING_CLIENT_CERT, todas las solicitudes se envían al backend aunque la validación falle o falte el certificado de cliente.
  • Cuando clientValidationMode se define como REJECT_INVALID, solo se envían al backend las solicitudes que proporcionan un certificado de cliente que se puede validar con un recurso TrustConfig.

Para crear un recurso de autenticación de cliente (ServerTlsPolicy), sigue estos pasos:

Consola

  1. En la consola, ve a la página Configuración de autenticación. Google Cloud

    Ir a Configuración de autenticación

  2. En la pestaña Autenticación de cliente, haz clic en Crear.

  3. Introduce un nombre para el recurso Client Authentication.

  4. En Ubicación, selecciona Global o Regional.

    En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, define la ubicación como global. En el caso de los balanceadores de carga de aplicación externos regionales y los balanceadores de carga de aplicación internos regionales, define la ubicación como la región en la que se ha configurado el balanceador de carga.

  5. En Modo de autenticación de cliente, selecciona Balanceo de carga.

  6. Selecciona un modo de validación de cliente.

  7. Selecciona el recurso de configuración de confianza que has creado anteriormente.

  8. Haz clic en Crear.

Comprueba que se muestre Autenticación de cliente (ServerTlsPolicy).

gcloud

  1. En función de cómo quieras gestionar la conexión, selecciona una de las siguientes opciones para definir el recurso de autenticación de cliente (ServerTlsPolicy) en formato YAML.

    • Opción 1: clientValidationMode está configurado como ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

      Mundial

      En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, crea un archivo YAML que especifique de forma declarativa el modo de validación de cliente y un recurso de configuración de confianza global:

      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

      regional

      En el caso de los balanceadores de carga de aplicaciones externos regionales y los balanceadores de carga de aplicaciones internos regionales, crea un archivo YAML que especifique de forma declarativa el modo de validación de clientes y un recurso de configuración de confianza regional:

      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

    • Opción 2: clientValidationMode está configurado como REJECT_INVALID.

      Mundial

      En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, crea un archivo YAML que especifique de forma declarativa el modo de validación de cliente y un recurso de configuración de confianza global:

      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

      regional

      En el caso de los balanceadores de carga de aplicaciones externos regionales y los balanceadores de carga de aplicaciones internos regionales, crea un archivo YAML que especifique de forma declarativa el modo de validación de clientes y un recurso de configuración de confianza regional:

      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

      Haz los cambios siguientes:

      SERVER_TLS_POLICY_NAME: el nombre del recurso de autenticación de cliente (ServerTlsPolicy).

      PROJECT_ID: el ID de tu proyecto de Google Cloud .

      LOCATION: en el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, usa global. En el caso de los balanceadores de carga de aplicación externos regionales o los balanceadores de carga de aplicación internos regionales, usa la región en la que hayas configurado el balanceador de carga.

      TRUST_CONFIG_NAME: el nombre del recurso de configuración de confianza que has creado anteriormente.

  2. Para importar el recurso ServerTlsPolicy de autenticación de cliente, usa el comando gcloud network-security server-tls-policies import:

    Mundial

    En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, asigna el valor global a la marca --location.

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

    Haz los cambios siguientes:

    SERVER_TLS_POLICY_NAME: el nombre del recurso de autenticación de cliente (ServerTlsPolicy).

    regional

    En el caso de los balanceadores de carga de aplicación externos regionales y los balanceadores de carga de aplicación internos regionales, define la marca --location en la región en la que esté configurado el balanceador de carga.

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

    Haz los cambios siguientes:

    SERVER_TLS_POLICY_NAME: el nombre del recurso de autenticación de cliente (ServerTlsPolicy).

  3. Opcional: Para enumerar todos los recursos de autenticación de cliente (ServerTlsPolicies), usa el comando gcloud network-security server-tls-policies list:

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

    Haz los cambios siguientes:

    LOCATION: En el caso de los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación internos entre regiones, usa global. En el caso de los balanceadores de carga de aplicación externos regionales o los balanceadores de carga de aplicación internos regionales, usa la región en la que hayas configurado el balanceador de carga.

Asocia el recurso ClientAuthentication al balanceador de carga

Para que la autenticación TLS mutua funcione, después de configurar el balanceador de carga, debes asociar el recurso de autenticación de cliente (ServerTLSPolicy) al recurso de proxy HTTPS de destino del balanceador de carga.

Consola

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ir a Balanceo de carga

  2. En la lista de balanceadores de carga, selecciona el balanceador de carga al que quieras adjuntar el recurso de autenticación de cliente (ServerTLSPolicy).

  3. Haz clic en Editar.

  4. En la sección Configuración de frontend de un frontend HTTPS, despliega la sección Mostrar funciones avanzadas.

  5. En la lista Client Authentication (Autenticación de cliente), selecciona el recurso Client Authentication (Autenticación de cliente).

  6. Haz clic en Listo.

  7. Haz clic en Actualizar.

gcloud

  1. Para enumerar todos los recursos de proxy HTTPS de destino de tu proyecto, usa el comando gcloud compute target-https-proxies list:

    gcloud compute target-https-proxies list

    Anota el nombre del proxy HTTPS de destino al que quieras adjuntar el recurso ServerTLSPolicy. En los pasos siguientes, nos referiremos a este nombre como TARGET_HTTPS_PROXY_NAME.

  2. Para exportar la configuración de un proxy HTTPS de destino a un archivo, usa el comando gcloud compute target-https-proxies export.

    Mundial

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

    Haz los cambios siguientes:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: el nombre del archivo de configuración del proxy de destino en formato YAML. Por ejemplo, mtls_target_proxy.yaml.

    regional

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

    Haz los cambios siguientes:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: el nombre del archivo de configuración del proxy de destino en formato YAML. Por ejemplo, mtls_target_proxy.yaml
    • REGION: la región en la que ha configurado el balanceador de carga.

  3. Para obtener una lista de todos los recursos de autenticación de cliente (ServerTlsPolicy), usa el comando gcloud network-security server-tls-policies list:

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

    Haz los cambios siguientes:

    LOCATION: para el balanceador de carga de aplicación interno entre regiones, el balanceador de carga de aplicación externo global o el balanceador de carga de aplicación clásico, usa global. En el caso de los balanceadores de carga de aplicación externos regionales o los balanceadores de carga de aplicación internos regionales, usa la región en la que hayas configurado el balanceador de carga.

    Anota el nombre del recurso de autenticación de cliente (ServerTLSPolicy) para configurar mTLS. En el siguiente paso, se hará referencia a este nombre como SERVER_TLS_POLICY_NAME.

  4. Añade la autenticación de cliente (ServerTlsPolicy) al proxy HTTPS de destino.

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

    Haz los cambios siguientes:

    • PROJECT_ID: el ID de tu proyecto de Google Cloud .
    • LOCATION: para los balanceadores de carga de aplicación externos globales o los balanceadores de carga de aplicación clásicos, y los balanceadores de carga de aplicación internos multirregión, usa global. En el caso de los balanceadores de carga de aplicación externos regionales o los balanceadores de carga de aplicación internos regionales, usa la región en la que hayas configurado el balanceador de carga.
    • SERVER_TLS_POLICY_NAME: el nombre del recurso de autenticación de cliente (ServerTLSPolicy).
    • TARGET_PROXY_FILENAME: el nombre del archivo de configuración del proxy de destino en formato YAML.

  5. Para importar la configuración de un proxy HTTPS de destino desde un archivo, usa el comando gcloud compute target-https-proxies import.

    Mundial

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

    Haz los cambios siguientes:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: el nombre del archivo de configuración del proxy de destino en formato YAML. Por ejemplo, mtls_target_proxy.yaml.

    regional

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

    Haz los cambios siguientes:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: el nombre del archivo de configuración del proxy de destino en formato YAML. Por ejemplo, mtls_target_proxy.yaml
    • REGION: la región en la que ha configurado el balanceador de carga.

Añadir encabezados personalizados de mTLS

Cuando habilitas mTLS, puedes transferir información sobre la conexión mTLS mediante encabezados personalizados. También puedes habilitar el registro para que los errores de conexión mTLS se registren.

Añadir encabezados personalizados de mTLS a servicios de backend

En el caso de los balanceadores de carga de aplicación externos globales o los balanceadores de carga de aplicación clásicos, puedes usar encabezados personalizados para transferir información sobre la conexión mTLS a los servicios de backend.

  1. Para enumerar todos los servicios de backend del proyecto, usa el comando gcloud compute backend-services list:

    gcloud compute backend-services list

    Anota el nombre del servicio de backend para habilitar los encabezados personalizados y el registro. En el siguiente paso, se hará referencia a este nombre como BACKEND_SERVICE.

  2. Para actualizar el servicio de backend, usa el comando 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}'

Añadir encabezados personalizados de mTLS al mapa de URLs

En el caso de los balanceadores de carga de aplicación internos entre regiones, los balanceadores de carga de aplicación externos regionales o los balanceadores de carga de aplicación internos regionales, puedes usar encabezados personalizados para transferir información sobre la conexión mTLS al mapa de URLs.

Para ver una lista con todos los mapas de URLs del proyecto, usa el comando gcloud compute url-maps list:

   gcloud compute url-maps list

Anota el nombre del mapa de URLs para habilitar los encabezados personalizados y el registro. En el siguiente paso, se hará referencia a este nombre como URL_MAP_NAME.

Mundial

Para editar el mapa de URLs de un balanceador de carga de aplicación interno entre regiones, usa el comando gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --global

A continuación, se muestra un archivo YAML de ejemplo que explica cómo usar variables en encabezados de solicitud personalizados (requestHeadersToAdd). Puedes usar las mismas variables para enviar encabezados de respuesta personalizados (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}"

regional

Para editar el mapa de URLs de un balanceador de carga de aplicación externo regional o de un balanceador de carga de aplicación interno regional, usa el comando gcloud compute url-maps edit:

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

A continuación, se muestra un archivo YAML de ejemplo que explica cómo usar variables en encabezados de solicitud personalizados (requestHeadersToAdd). Puedes usar las mismas variables para enviar encabezados de respuesta personalizados (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}"

Firmar el certificado de cliente con el certificado intermedio

En esta sección se ofrece una opción de configuración adicional para generar un certificado de cliente (hoja). Si ya has creado un recurso TrustConfig que contiene un certificado intermedio, haz lo siguiente:

  1. Crea un archivo de configuración para generar la CSR del certificado de cliente.

    El siguiente archivo de configuración (client.config) contiene la sección [extension_requirements], que especifica las extensiones X.509 que se deben incluir en la CSR. Para obtener más información sobre los requisitos de los certificados de cliente, consulta Requisitos de los certificados.

    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 quieres adjuntar una identidad SPIFFE al archivo de configuración, haz lo siguiente:

    • Añade un campo subjectAltName a la sección [extension_requirements] de la siguiente manera:

      subjectAltName            = @sans_list

    • Añade una nueva sección ([sans_list]) en la parte inferior del archivo client.config de la siguiente manera:

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

  2. Crea la CSR (client.csr) del certificado de cliente.

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

  3. Firma la CSR para emitir el certificado de cliente X.509 (client.cert). El certificado intermedio firma la CSR.

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

  4. Envía una solicitud HTTPS segura a la dirección IP del balanceador de carga mediante el certificado SSL del lado del cliente. El cliente presenta su certificado (client.cert) para autenticarse en el balanceador de carga.

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

    Sustituye IP_ADDRESS por la dirección IP del balanceador de carga.

Siguientes pasos