Configura la 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 proporcionan instrucciones para crear tu propia cadena de confianza configurando tus propios certificados raíz e intermedios con la biblioteca de 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 TrustConfig del Administrador de certificados. Luego, 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 cargas.

Antes de comenzar

  • Revisa la descripción general de la TLS mutua.
  • Revisa la guía para administrar las configuraciones de confianza.

  • Instala Google Cloud CLI. Para obtener una descripción general completa de la herramienta, consulta la descripción general de gcloud CLI. Encontrarás comandos relacionados con el balanceo de cargas en la referencia de la API y la gcloud CLI.

    Si no ejecutaste gcloud CLI antes, ejecuta primero el comando gcloud init para autenticarte.

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

  • Si usas el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, asegúrate de haber configurado un balanceador de cargas con cualquiera de los siguientes backends compatibles:

    • Backends de grupos de instancias de VM
    • Buckets de Cloud Storage (compatibles solo si hay al menos un servicio de backend conectado al balanceador de cargas, además del bucket de backend)
    • Backend de Cloud Run, App Engine o Cloud Run Functions
    • Conectividad híbrida
    • Backends de Private Service Connect

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

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

  • Configura tu proyecto.

    gcloud 

    gcloud config set project PROJECT_ID

Permisos

Para obtener los permisos que necesitas a fin de completar esta guía, pídele a tu administrador que te otorgue los siguientes roles de IAM en el proyecto:

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

Crea los certificados raíz e intermedio

En esta sección, se usa la biblioteca de 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 se remonta al certificado raíz. El certificado intermedio está firmado criptográficamente por el certificado raíz. Cuando el balanceador de cargas 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 y los intermedios, consulta 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. Genera una clave privada RSA nueva (root.key) y úsala para crear un certificado de la AC raíz X.509 autofirmado (root.cert), que funciona como la autoridad de certificación raíz (CA).

    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 una solicitud de firma de certificado (CSR) (int.req) para el 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. Crea el certificado intermedio X.509 (int.cert) a partir de la CSR. La CA raíz usa su clave privada (root.key) y su certificado (root.cert) para emitir y firmar el certificado intermedio X.509.

    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 agregar a una lista de entidades permitidas

Puedes crear un certificado autofirmado y agregarlo a una lista de entidades permitidas 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

Luego, este certificado se agrega a un campo allowlistedCertificates en la configuración de confianza.

Da formato a los certificados

Para incluir certificados nuevos o existentes en un TrustStore, debes dar formato a los certificados en una sola línea y almacenarlos 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 certificados nuevos o existentes que se agregan a una lista de entidades permitidas en una configuración de confianza, debes dar formato a los certificados en una sola línea y almacenarlos en variables de entorno para que se puedan leer en el archivo YAML. Para los certificados que están en una lista de entidades permitidas, 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')

Crea un recurso de configuración de confianza

Una configuración de confianza es un recurso que representa la configuración de tu infraestructura de clave pública (PKI) en el Administrador de certificados.

Para crear un recurso de configuración de confianza, completa los siguientes pasos:

Console

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

    Ir al Administrador de certificados

  2. En la pestaña Parámetros de configuración de confianza, haz clic en Agregar parámetro de configuración de confianza.

  3. Ingresa 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. Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, crea un recurso de configuración de confianza global. Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, crea un recurso de configuración de confianza regional.

    Si seleccionaste Regional, selecciona la región.

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

  6. Haz clic en Agregar.

  7. En la sección Almacén de confianza, haz clic en Agregar CA intermedia y sube el archivo de certificado con codificación PEM o copia el contenido del certificado.

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

  8. Haz clic en Agregar para agregar la AC intermediaria.

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

  10. Haz clic en Agregar para agregar el certificado incluido en la lista de entidades permitidas.

  11. Haz clic en Crear.

Verifica 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 recurso de configuración de confianza de ejemplo 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 Da formato a 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, agrega filas pemCertificate en la sección adecuada.

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

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

    Un certificado que se agrega a una lista de entidades permitidas representa cualquier certificado que se pueda encapsular dentro de la configuración de confianza para que siempre se considere válido. Puedes especificar varios certificados en una lista de entidades permitidas; para ello, usa 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:

    global

    Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones 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

    Reemplaza lo siguiente:

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

    regional

    Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas 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

    Reemplaza lo siguiente:

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

Crea un recurso de autenticación de clientes

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

  • Cuando clientValidationMode se establece como ALLOW_INVALID_OR_MISSING_CLIENT_CERT, todas las solicitudes se pasan al backend, incluso si la validación falla o si falta el certificado de cliente.
  • Cuando clientValidationMode se establece en REJECT_INVALID, solo las solicitudes que proporcionan un certificado de cliente que se puede validar en un recurso TrustConfig se pasan al backend.
  • Cuando clientValidationMode se establece en ALLOW_VALIDATION_RELAXATIONS, solo las solicitudes que proporcionan un certificado de cliente que se puede validar en un recurso TrustConfig, con las flexibilizaciones de validación especificadas (clientValidationRelaxations) aplicadas, se pasan al backend.

Para crear un recurso de autenticación de cliente (ServerTlsPolicy), completa los siguientes pasos:

Console

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

    Ir a Configuración de autenticación

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

  3. Ingresa un nombre para el recurso de autenticación de cliente.

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

    Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, establece la ubicación en global. Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, establece la ubicación en la región en la que está configurado el balanceador de cargas.

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

  6. En Modo de validación del cliente, selecciona una de las siguientes opciones:

    • Rechazar un certificado de cliente no válido
    • Permite un certificado de cliente no válido o faltante
    • Permitir flexibilizaciones de validación

    Para obtener más información, consulta Modos de validación del cliente.

    Si seleccionas Permitir flexibilizaciones de validación, elige una o más de las siguientes flexibilizaciones de validación:

    • Permitir EKU faltante
    • Permitir el hash SHA-1
    • Permitir certificado de hoja vencido

  7. Selecciona el recurso de configuración de confianza que creaste antes.

  8. Opcional: Haz clic en Código equivalente para ver la configuración de Terraform de este recurso.

  9. Haz clic en Crear.

Verifica que se muestre la autenticación de cliente (ServerTlsPolicy).

gcloud

  1. Según cómo desees manejar 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 se establece en ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

      global

      Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, crea un archivo YAML que especifique de forma declarativa el modo de validación del 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

      Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, crea un archivo YAML que especifique de forma declarativa el modo de validación del cliente 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 se establece en REJECT_INVALID.

      global

      Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, crea un archivo YAML que especifique de forma declarativa el modo de validación del 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

      Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, crea un archivo YAML que especifique de forma declarativa el modo de validación del cliente 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

    • Opción 3: clientValidationMode se establece en ALLOW_VALIDATION_RELAXATIONS.

      global

      Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, crea un archivo YAML que especifique de forma declarativa el modo de validación del cliente, una o más flexibilizaciones de validación y un recurso de configuración de confianza global:

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

      regional

      Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, crea un archivo YAML que especifique de forma declarativa el modo de validación del cliente, una o más relajaciones de validación y un recurso de configuración de confianza regional:

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

    Reemplaza lo siguiente:

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

    • VALIDATION_RELAXATION: uno o más de los siguientes valores: ALLOW_MISSING_EKU, ALLOW_SHA1_HASHING o ALLOW_EXPIRED_LEAF_CERTIFICATE.

    • PROJECT_ID: Es el ID de tu proyecto de Google Cloud .

    • REGION: Para el balanceador de cargas de aplicaciones externo regional o el balanceador de cargas de aplicaciones interno regional, usa la región en la que configuraste el balanceador de cargas.

    • TRUST_CONFIG_NAME: Es el nombre del recurso de configuración de confianza que creaste antes.

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

    global

    Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, establece la marca --location en global.

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

    Reemplaza lo siguiente:

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

    regional

    Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, establece la marca --location en la región en la que está configurado el balanceador de cargas.

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

    Reemplaza lo siguiente:

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

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

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

    Reemplaza lo siguiente:

    LOCATION: Para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos entre regiones, usa global. Para el balanceador de cargas de aplicaciones externo regional o el balanceador de cargas de aplicaciones interno regional, usa la región en la que configuraste el balanceador de cargas.

Conecta el recurso de autenticación de clientes al balanceador de cargas

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

Console

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

    Ir a Balanceo de cargas

  2. En la lista de balanceadores de cargas, selecciona el balanceador de cargas al que necesitas 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 de HTTPS, expande la sección Mostrar funciones avanzadas.

  5. En la lista Autenticación del cliente, selecciona el recurso de autenticación del cliente.

  6. Haz clic en Listo.

  7. Haz clic en Actualizar.

gcloud

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

    gcloud compute target-https-proxies list

    Toma nota del nombre del proxy HTTPS de destino al que se conectará el recurso ServerTLSPolicy. Este nombre se denomina TARGET_HTTPS_PROXY_NAME en los siguientes pasos.

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

    global

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

    Reemplaza lo siguiente:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: Es 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

    Reemplaza lo siguiente:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: Es 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 configuraste el balanceador de cargas.

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

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

    Reemplaza lo siguiente:

    LOCATION: Para el balanceador de cargas de aplicaciones interno entre regiones, el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, usa global. Para el balanceador de cargas de aplicaciones externo regional o el balanceador de cargas de aplicaciones interno regional, usa la región en la que configuraste el balanceador de cargas.

    Ten en cuenta el nombre del recurso de autenticación de cliente (ServerTLSPolicy) para configurar mTLS. Este nombre se denomina SERVER_TLS_POLICY_NAME en el paso siguiente.

  4. Agrega 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

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID de tu proyecto de Google Cloud .
    • LOCATION: Para los balanceadores de cargas de aplicaciones externos globales o los balanceadores de cargas de aplicaciones clásicos, y los balanceadores de cargas de aplicaciones internos entre regiones, usa global. Para el balanceador de cargas de aplicaciones externo regional o el balanceador de cargas de aplicaciones interno regional, usa la región en la que configuraste el balanceador de cargas.
    • SERVER_TLS_POLICY_NAME: Es el nombre del recurso de autenticación de cliente (ServerTLSPolicy).
    • TARGET_PROXY_FILENAME: Es 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.

    global

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

    Reemplaza lo siguiente:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: Es 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

    Reemplaza lo siguiente:

    • TARGET_HTTPS_PROXY_NAME: el nombre del proxy de destino.
    • TARGET_PROXY_FILENAME: Es 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 configuraste el balanceador de cargas.

Agrega encabezados personalizados mTLS

Cuando habilitas mTLS, puedes pasar información sobre la conexión mTLS con encabezados personalizados. También puedes habilitar el registro para que se capturen los errores de conexión mTLS en tus registros. Para obtener más información sobre cómo configurar el registro, consulta uno de los siguientes vínculos:

Agrega encabezados personalizados mTLS a los servicios de backend

Para los balanceadores de cargas de aplicaciones externos globales o los balanceadores de cargas de aplicaciones clásicos, puedes usar encabezados personalizados para pasar 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

    Toma nota del nombre del servicio de backend para habilitar los encabezados personalizados. Este nombre se denomina BACKEND_SERVICE en el siguiente paso.

  2. Para actualizar el servicio de backend, usa el comando gcloud compute backend-services update:

    gcloud compute backend-services update BACKEND_SERVICE \
  --global \
  --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}'

Agrega encabezados personalizados mTLS al mapa de URL

Para los balanceadores de cargas de aplicaciones internos entre regiones, los balanceadores de cargas de aplicaciones externos regionales o los balanceadores de cargas de aplicaciones internos regionales, puedes usar encabezados personalizados para pasar información sobre la conexión mTLS al mapa de URL.

Para enumerar todos los mapas de URL en el proyecto, usa el comando gcloud compute url-maps list:

   gcloud compute url-maps list

Toma nota del nombre del mapa de URLs para habilitar los encabezados personalizados. Este nombre se denomina URL_MAP_NAME en el siguiente paso.

global

Para editar el mapa de URL de un balanceador de cargas de aplicaciones 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 muestra que indica 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 URL de un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones 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 indica 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}"

Firma el certificado de cliente con el certificado intermedio

En esta sección, se proporciona una opción de configuración adicional para generar un certificado de cliente (hoja). Si ya creaste 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 incluirán 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 deseas adjuntar una identidad de SPIFFE al archivo de configuración, haz lo siguiente:

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

      subjectAltName            = @sans_list

    • Agrega una sección nueva ([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 una CSR (client.csr) para el certificado de cliente.

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

  3. Crea un certificado de cliente (client.cert) a partir de la CSR. La CA intermedia usa su clave privada (int.key) y su certificado (int.cert) para emitir y firmar el certificado de cliente X.509.

    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 cargas con el certificado SSL del cliente. El cliente presenta su certificado (client.cert) para autenticarse en el balanceador de cargas.

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

    Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas.

¿Qué sigue?