Configura políticas de autorización para balanceadores de cargas de aplicaciones

En los balanceadores de cargas de aplicaciones, se llama a las políticas de autorización después de evaluar las extensiones de ruta, las políticas de seguridad de red (que evalúa Google Cloud Armor), las políticas de uso compartido de recursos entre dominios (CORS) y Identity-Aware Proxy (IAP), pero antes de ejecutar acciones de administración de tráfico.

En esta página, se muestra cómo configurar políticas de autorización para los balanceadores de cargas de aplicaciones.

Antes de comenzar

Configura el balanceador de cargas

Si no creaste un balanceador de cargas, consulta las siguientes páginas para configurar tu balanceador de cargas de aplicaciones preferido:

Crea y configura cuentas de servicio o etiquetas seguras

Con los balanceadores de cargas de aplicaciones internos, puedes aplicar, de manera opcional, políticas de autorización basadas en las etiquetas seguras y las cuentas de servicio adjuntas a las VMs del cliente. Si tienes previsto aplicar políticas de autorización basadas en etiquetas, usa Resource Manager para crearlas.

Si usas balanceadores de cargas de aplicaciones externos, no es necesario que crees ni configures etiquetas seguras.

Para obtener más información, consulta Usa etiquetas para firewalls y Cuentas de servicio.

Conecta cuentas de servicio a VMs de cliente

Para obtener información paso a paso sobre cómo conectar una cuenta de servicio a una instancia de VM, consulta los siguientes documentos:

Crea las claves y los valores de etiqueta segura

Antes de vincular una etiqueta segura con la plantilla de grupo de instancias, debes crear las claves y los valores de la etiqueta. Cuando crees una etiqueta, designala con un propósito GCE_FIREWALL. Las funciones de redes de Google Cloud, incluido el proxy web seguro y las políticas de autorización, requieren el propósito GCE_FIREWALL para aplicar la etiqueta.

Para crear etiquetas seguras, necesitas el rol de administrador de etiquetas (roles/resourcemanager.tagAdmin).

Console

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

    Ir a Etiquetas

  2. Haga clic en Crear.

  3. En el campo Descripción de la clave de la etiqueta, ingresa una descripción.

  4. Selecciona la casilla de verificación Para uso con firewall de red.

  5. En la lista Proyecto, selecciona el proyecto de Google Cloud en el que deseas crear la etiqueta.

  6. En el campo Red, selecciona LB_NETWORK.

  7. Haz clic en Agregar valor.

  8. En el campo Valor de la etiqueta, ingresa TAG_VALUE. El valor debe ser numérico.

  9. En el campo Descripción del valor de la etiqueta, ingresa una descripción.

  10. Cuando termines de agregar valores de etiqueta, haz clic en Crear clave de etiqueta.

gcloud

  1. Crea la clave de etiqueta segura.

    gcloud resource-manager tags keys create TAG_KEY \
        --parent=organizations/ORG_ID \
        --purpose=GCE_FIREWALL \
        --purpose-data=network=LB_NETWORK
    

    Reemplaza lo siguiente:

    • TAG_KEY: Es el nombre de tu clave de etiqueta segura.
    • ORG_ID: el ID de tu organización.
    • LB_NETWORK: El nombre de tu red de VPC
  2. Agrega el valor de la etiqueta segura a la clave de etiqueta numérica.

    gcloud resource-manager tags values create TAG_VALUE \
        --parent=ORG_ID/TAG_KEY
    

    Reemplaza TAG_VALUE por un valor de etiqueta numérica.

Vincula la etiqueta segura a la plantilla de grupo de instancias

Los administradores de etiquetas pueden vincular etiquetas seguras a instancias de VM individuales o a la plantilla de grupo de instancias, y adjuntar el valor de la etiqueta a los backends de las VMs o de la plantilla.

Para vincular etiquetas seguras, necesitas el rol de usuario de etiquetas (roles/resourcemanager.tagUser).

  1. Define el prefijo de nombre completo para tu proyecto y zona:

    FULL_NAME_PREFIX=//compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/instances/
    

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID de tu proyecto.
    • ZONE: Es la zona en la que se encuentra el grupo de instancias administrado.
  2. Obtén el ID de la plantilla de grupo de instancias:

    TEMPLATE_ID=$(gcloud compute instance-templates describe TEMPLATE_NAME --region=LOCATION --format='value(id)')
    

    Reemplaza lo siguiente:

    • TEMPLATE_NAME: Es el nombre de la plantilla de grupo de instancias.
    • LOCATION: Es tu región de Google Cloud.
  3. Concatena los valores de FULL_NAME_PREFIX y TEMPLATE_ID:

    PARENT="$FULL_NAME_PREFIX$TEMPLATE_ID"
    echo $PARENT
    
  4. Crea las vinculaciones.

    gcloud resource-manager tags bindings create \
        --location LOCATION \
        --tag-value ORG_ID/TAG_KEY/TAG_VALUE \
        --parent PARENT
    

    Reemplaza lo siguiente:

    • ORG_ID: el ID de tu organización.
    • LOCATION: Es tu región de Google Cloud.
    • TAG_KEY: Es el nombre de la clave de etiqueta segura.
    • TAG_VALUE: Es el valor numérico de la etiqueta.

Crea la política de autorización

Para crear una política de autorización, crea un archivo YAML que defina el objetivo y las reglas, y, luego, impórtalo con el comando gcloud beta network-security authz-policies.

En esta sección, se proporcionan instrucciones para crear diferentes tipos de políticas de autorización adjuntas a la regla de reenvío de un balanceador de cargas.

Política de autorización para rechazar solicitudes

Global y entre regiones

Si usas un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones interno entre regiones, sigue estos pasos para crear e importar la política de autorización:

  1. Crea el archivo de política de autorización para rechazar ciertas solicitudes.

    En el siguiente ejemplo, se crea un archivo authz-policy-deny.yaml para la regla de reenvío LB_FORWARDING_RULE en la ubicación global. La política niega a los clientes de *.hello.com el acceso a la ruta de URL /api/payments.

    $ cat >authz-policy-deny.yaml <<EOF
    name: my-authz-policy-deny
    target:
      loadBalancingScheme: LB_SCHEME
      resources:
      - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/LB_FORWARDING_RULE"
    httpRules:
    - from:
        sources:
        - principals:
          - suffix: ".hello.com"
      to:
        operations:
        - paths:
          - prefix: "/api/payments"
    action: DENY
    EOF
    

    Reemplaza lo siguiente:

    • LB_SCHEME: Es tu esquema de balanceo de cargas. Para el balanceador de cargas de aplicaciones externo global, establece el esquema en EXTERNAL_MANAGED. Para el balanceador de cargas de aplicaciones interno entre regiones, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID del proyecto de Google Cloud.
    • LB_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas.
  2. Crea la política de autorización y, luego, importa el archivo YAML.

    En el siguiente comando de ejemplo, se importa el archivo de políticas creado anteriormente y se crean las políticas de autorización:

    gcloud beta network-security authz-policies import my-authz-policy-deny \
        --source=authz-policy-deny.yaml \
        --location=global
    

Regional

Si usas un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones interno regional, sigue estos pasos para crear e importar la política de autorización:

  1. Crea el archivo de política de autorización para permitir ciertas solicitudes.

    En el siguiente ejemplo, se crea un archivo authz-policy-deny.yaml para la regla de reenvío LB_FORWARDING_RULE en una región de Google Cloud. La política niega a los clientes con identidades que coincidan con *.hello.com el acceso a la ruta de URL /api/payments. La política también niega el acceso a cualquier VM cliente con la cuenta de servicio my-sa-123@PROJECT_ID.iam.gserviceaccount.com a la URL /api/payments.

    $ cat >authz-policy-deny.yaml <<EOF
    name: my-authz-policy-deny
    target:
      loadBalancingScheme: LB_SCHEME
      resources:
      - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
    httpRules:
    - from:
        sources:
        - principals:
          - suffix: ".hello.com"
      to:
        operations:
        - paths:
          - prefix: "/api/payments"
    - from:
        sources:
        - resources:
           - iamServiceAccount:
               exact: "my-sa-123@PROJECT_ID.iam.gserviceaccount.com"
      to:
        operations:
        - paths:
          - prefix: "/api/payments"
    action: DENY
    EOF
    

    Reemplaza lo siguiente:

    • LB_SCHEME: Es tu esquema de balanceo de cargas. Para el balanceador de cargas de aplicaciones externo regional, establece el esquema en EXTERNAL_MANAGED. Para el balanceador de cargas de aplicaciones interno regional, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID del proyecto de Google Cloud.
    • LOCATION: Es tu región de Google Cloud.
    • LB_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas.
  2. Crea la política de autorización y, luego, importa el archivo YAML.

    En el siguiente comando de ejemplo, se importa el archivo de políticas creado anteriormente y se crean las políticas de autorización en la región LOCATION:

    gcloud beta network-security authz-policies import my-authz-policy-deny \
        --source=authz-policy-deny.yaml \
        --location=LOCATION
    

Política de autorización para permitir solicitudes

Global y entre regiones

Si usas un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones interno entre regiones, sigue estos pasos para crear e importar la política de autorización:

  1. Crea el archivo de política de autorización para permitir ciertas solicitudes.

    En el siguiente ejemplo, se crea un archivo authz-policy-allow.yaml para la regla de reenvío LB_FORWARDING_RULE en la ubicación global. La política solo permite que los clientes de *.example.com accedan a la ruta de URL /api/payments.

    $ cat >authz-policy-allow.yaml <<EOF
    name: my-authz-policy-allow
    target:
      loadBalancingScheme: LB_SCHEME
      resources:
      - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/LB_FORWARDING_RULE"
    httpRules:
    - from:
      sources:
      - principals:
        - suffix: ".example.com"
      to:
        operations:
        - paths:
          - exact: "/api/payments"
    action: ALLOW
    EOF
    

    Reemplaza lo siguiente:

    • LB_SCHEME: Es tu esquema de balanceo de cargas. Para el balanceador de cargas de aplicaciones externo global, establece el esquema en EXTERNAL_MANAGED. Para el balanceador de cargas de aplicaciones interno entre regiones, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID del proyecto de Google Cloud.
    • LB_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas.
  2. Crea la política de autorización y, luego, importa el archivo YAML.

    En el siguiente comando de ejemplo, se importa el archivo de políticas creado anteriormente y se crean las políticas de autorización:

    gcloud beta network-security authz-policies import my-authz-policy-allow \
        --source=authz-policy-allow.yaml \
        --location=global
    

Regional

Si usas un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones interno regional, sigue estos pasos para crear e importar la política de autorización:

  1. Crea el archivo de política de autorización para permitir ciertas solicitudes.

    En el siguiente ejemplo, se crea un archivo authz-policy-allow.yaml para la regla de reenvío LB_FORWARDING_RULE en una región de Google Cloud de un balanceador de cargas de aplicaciones interno regional. La política permite que solo los clientes de *.example.com accedan a la ruta de URL /api/payments cuando la solicitud se origina en una VM con la etiqueta de recurso TAG_VALUE.

    $ cat >authz-policy-allow.yaml <<EOF
    name: my-authz-policy-allow
    target:
      loadBalancingScheme: LB_SCHEME
      resources:
      - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
    httpRules:
    - from:
      sources:
      - principals:
        - suffix: ".example.com"
        resources:
        - tagValueIdSet:
          - ids: "TAG_VALUE"
      to:
        operations:
        - paths:
          - exact: "/api/payments"
    action: ALLOW
    EOF
    

    Reemplaza lo siguiente:

    • LB_SCHEME: Es tu esquema de balanceo de cargas. Si usas un balanceador de cargas de aplicaciones externo regional, establece el esquema en EXTERNAL_MANAGED. Si usas un balanceador de cargas de aplicaciones interno regional, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID del proyecto de Google Cloud.
    • LOCATION: Es tu región de Google Cloud.
    • LB_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas.
  2. Crea la política de autorización y, luego, importa el archivo YAML.

    En el siguiente comando de ejemplo, se importa el archivo de políticas creado anteriormente y se crean las políticas de autorización en la región LOCATION:

    gcloud beta network-security authz-policies import my-authz-policy-allow \
        --source=authz-policy-allow.yaml \
        --location=LOCATION
    

Política de autorización para delegar a una extensión de servicio

Antes de comenzar, configura un motor de autorización externo. Para obtener más información sobre las extensiones de servicio, consulta la descripción general de los textos destacados de Cloud Load Balancing.

Global y entre regiones

Si usas un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones interno entre regiones, sigue estos pasos para crear e importar la política de autorización:

  1. Crea el archivo de política de autorización para delegar ciertas solicitudes a un servicio externo.

    En el siguiente ejemplo, se crea un archivo authz-policy-custom.yaml para la regla de reenvío LB_FORWARDING_RULE en la ubicación global. La política llama a la extensión AUTHZ_EXTENSION para todo el tráfico a la ruta de URL /api/payments cuando la solicitud contiene un encabezado Authorization no vacío.

    $ cat >authz-policy-custom.yaml <<EOF
    name: my-authz-policy-custom
    target:
      loadBalancingScheme: LB_SCHEME
      resources:
      - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/LB_FORWARDING_RULE"
    httpRules:
    - to:
        operations:
        - paths:
          - exact: "/api/payments"
      when: 'request.headers["Authorization"] != ""'
    action: CUSTOM
    customProvider:
      authzExtension:
        resources:
        - "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/global/authzExtensions/AUTHZ_EXTENSION"
    EOF
    

    Reemplaza lo siguiente:

    • LB_SCHEME: Es tu esquema de balanceo de cargas. Para el balanceador de cargas de aplicaciones externo global, establece el esquema en EXTERNAL_MANAGED. Para el balanceador de cargas de aplicaciones interno entre regiones, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID del proyecto de Google Cloud.
    • LB_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas.
    • AUTHZ_EXTENSION: Es el nombre de la extensión de autorización.
  2. Crea la política de autorización y, luego, importa el archivo YAML.

    En el siguiente comando de ejemplo, se importa el archivo de políticas creado anteriormente y se crean las políticas de autorización:

    gcloud beta network-security authz-policies import my-authz-policy-custom \
        --source=authz-policy-custom.yaml \
        --location=global
    

Regional

Si usas un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones interno regional, sigue estos pasos para crear e importar la política de autorización:

  1. Crea el archivo de política de autorización para delegar ciertas solicitudes a un servicio externo.

    En el siguiente ejemplo, se crea un archivo authz-policy-custom.yaml para la regla de reenvío LB_FORWARDING_RULE en una región de Google Cloud de un balanceador de cargas de aplicaciones interno regional. La política llama a la extensión AUTHZ_EXTENSION para todo el tráfico a la ruta de URL /api/payments cuando la solicitud contiene un encabezado Authorization no vacío.

    $ cat >authz-policy-custom.yaml <<EOF
    name: my-authz-policy-custom
    target:
      loadBalancingScheme: LB_SCHEME
      resources:
      - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
    httpRules:
    - to:
        operations:
        - paths:
          - exact: "/api/payments"
      when: 'request.headers["Authorization"] != ""'
    action: CUSTOM
    customProvider:
      authzExtension:
        resources:
        - "https://networkservices.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/authzExtensions/AUTHZ_EXTENSION"
    EOF
    

    Reemplaza lo siguiente:

    • LB_SCHEME: Es tu esquema de balanceo de cargas. Para el balanceador de cargas de aplicaciones externo regional, establece el esquema en EXTERNAL_MANAGED. Para el balanceador de cargas de aplicaciones interno regional, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID del proyecto de Google Cloud.
    • LOCATION: Es tu región de Google Cloud.
    • LB_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas.
    • AUTHZ_EXTENSION: Es el nombre de la extensión de autorización.
  2. Crea la política de autorización y, luego, importa el archivo YAML.

    En el siguiente comando de ejemplo, se importa el archivo de políticas creado anteriormente y se crean las políticas de autorización en la región LOCATION:

    gcloud beta network-security authz-policies import my-authz-policy-custom \
        --source=authz-policy-custom.yaml \
        --location=LOCATION
    

Prueba las políticas de autorización

Para probar las políticas de autorización, envía tráfico al balanceador de cargas. Si deseas obtener más información, consulta las siguientes páginas:

Comprende los registros de la política de autorización en Cloud Logging

Para comprender cómo se registran las políticas de autorización cuando se permite o rechaza una solicitud, consulta lo siguiente:

  • Cuando una solicitud no coincide con las políticas ALLOW ni DENY, la política DENY permite la solicitud y la registra como allowed_as_no_deny_policies_matched_request. Por el contrario, la política ALLOW rechaza la solicitud y la registra como denied_as_no_allow_policies_matched_request. Debido a que una de las políticas rechaza la solicitud, esta se rechaza.

    Si usas un balanceador de cargas de aplicaciones externo global, statusDetails se establece en denied_by_authz_policy en el registro. Consulta el siguiente ejemplo:

      {
        httpRequest: {8}
        insertId: "example-id"
        jsonPayload: {
          @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
          authzPolicyInfo: {
            policies: [
              0: {
                details: "allowed_as_no_deny_policies_matched_request"
                result: "ALLOWED"
              }
              1: {
                details: "denied_as_no_allow_policies_matched_request"
                result: "DENIED"
              }
            ]
            result: "DENIED"
          }
          backendTargetProjectNumber: "projects/12345567"
          remoteIp: "00.100.11.104"
          proxyStatus: "error=\"http_request_error\"; details=\"denied_by_authz_policy\""
        }
        logName: "projects/example-project/logs/requests"
        receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
        resource: {2}
        severity: "WARNING"
        spanId: "3e1a09a8e5e3e14d"
        timestamp: "2024-08-28T15:33:55.355042Z"
        trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
      }
    

    Si usas un balanceador de cargas de aplicaciones interno regional, un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones interno entre regiones, proxyStatus se establece en error=\"http_request_error\"; details=\"denied_by_authz_policy\" en el registro. Consulta el siguiente ejemplo:

      {
        httpRequest: {8}
        insertId: "example-id"
        jsonPayload: {
          @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
          authzPolicyInfo: {
            policies: [
              0: {
                details: "allowed_as_no_deny_policies_matched_request"
                result: "ALLOWED"
              }
              1: {
                details: "denied_as_no_allow_policies_matched_request"
                result: "DENIED"
              }
            ]
            result: "DENIED"
          }
          backendTargetProjectNumber: "projects/12345567"
          remoteIp: "00.100.11.104"
          proxyStatus: "error=\"http_request_error\"; details=\"denied_by_authz_policy\""
        }
        logName: "projects/example-project/logs/requests"
        receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
        resource: {2}
        severity: "WARNING"
        spanId: "3e1a09a8e5e3e14d"
        timestamp: "2024-08-28T15:33:55.355042Z"
        trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
      }
    
  • Cuando una solicitud coincide con la política DENY, se rechaza y se registra la política que la rechazó.

    Si usas un balanceador de cargas de aplicaciones externo global, statusDetails se establece en denied_by_authz_policy en el registro y el nombre de la política que rechazó la solicitud se registra en policies. Consulta el siguiente ejemplo:

      {
        httpRequest: {8}
        insertId: "example-id"
        jsonPayload: {
          @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
          authzPolicyInfo: {
            policies: [
              0: {
                details: "name: "projects/12345567/locations/global/authzPolicies/deny-authz-policy-test""
                result: "DENIED"
              }
            ]
            result: "DENIED"
          }
          backendTargetProjectNumber: "projects/12345567"
          cacheDecision: [2]
          remoteIp: "00.100.11.104"
          statusDetails: "denied_by_authz_policy"
        }
        logName: "projects/example-project/logs/requests"
        receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
        resource: {2}
        severity: "WARNING"
        spanId: "3e1a09a8e5e3e14d"
        timestamp: "2024-08-28T15:33:55.355042Z"
        trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
      }
    

    Si usas un balanceador de cargas de aplicaciones interno regional, un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones interno entre regiones, proxyStatus se establece en error=\"http_request_error\"; details=\"denied_by_authz_policy\" y el nombre de la política se registra en policies. Consulta el siguiente ejemplo:

      {
        httpRequest: {8}
        insertId: "example-id"
        jsonPayload: {
          @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
          authzPolicyInfo: {
            policies: [
              0: {
                details: "name: "projects/12345567/locations/$REGION/authzPolicies/deny-authz-policy-test""
                result: "DENIED"
              }
            ]
            result: "DENIED"
          }
          backendTargetProjectNumber: "projects/12345567"
          remoteIp: "00.100.11.104"
          proxyStatus: "error=\"http_request_error\"; details=\"denied_by_authz_policy\""
        }
        logName: "projects/example-project/logs/requests"
        receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
        resource: {2}
        severity: "WARNING"
        spanId: "3e1a09a8e5e3e14d"
        timestamp: "2024-08-28T15:33:55.355042Z"
        trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
      }
    
  • Cuando una solicitud no coincide con la política de DENY, pero sí con la política de ALLOW, se permite la solicitud. En el registro, esta acción se registra como allowed_as_no_deny_policies_matched_request para la política DENY. También se registra la política que permitió la solicitud.

    Si usas un balanceador de cargas de aplicaciones externo global, no hay statusDetails en el registro. La política que permitió la solicitud también se registra en policies. Consulta el siguiente ejemplo:

      {
        httpRequest: {8}
        insertId: "example-id"
        jsonPayload: {
          @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
          authzPolicyInfo: {
            policies: [
              0: {
                details: "allowed_as_no_deny_policies_matched_request"
                result: "ALLOWED"
              }
              1: {
                details: "name: "projects/12345567/locations/global/authzPolicies/allow-authz-policy-test""
                result: "ALLOWED"
              }
            ]
            result: "ALLOWED"
          }
          backendTargetProjectNumber: "projects/12345567"
          cacheDecision: [2]
          remoteIp: "00.100.11.104"
        }
        logName: "projects/example-project/logs/requests"
        receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
        resource: {2}
        severity: "WARNING"
        spanId: "3e1a09a8e5e3e14d"
        timestamp: "2024-08-28T15:33:55.355042Z"
        trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
      }
    

    Si usas un balanceador de cargas de aplicaciones interno regional, un balanceador de cargas de aplicaciones externo regional o un balanceador de cargas de aplicaciones interno entre regiones, no hay un campo proxyStatus en el registro. La política que permitió la solicitud también se registra en policies. Consulta el siguiente ejemplo:

      {
        httpRequest: {8}
        insertId: "example-id"
        jsonPayload: {
          @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
          authzPolicyInfo: {
            policies: [
              0: {
                details: "allowed_as_no_deny_policies_matched_request"
                result: "ALLOWED"
              }
              1: {
                details: "name: "projects/12345567/locations/$REGION/authzPolicies/allow-authz-policy-test""
                result: "ALLOWED"
              }
            ]
            result: "ALLOWED"
          }
          backendTargetProjectNumber: "projects/12345567"
          cacheDecision: [2]
          remoteIp: "00.100.11.104"
        }
        logName: "projects/example-project/logs/requests"
        receiveTimestamp: "2024-08-28T15:33:56.046651035Z"
        resource: {2}
        severity: "WARNING"
        spanId: "3e1a09a8e5e3e14d"
        timestamp: "2024-08-28T15:33:55.355042Z"
        trace: "projects/example-project/traces/8c8b3dbf9a19c85954d0fa2d958ca509"
      }
    

¿Qué sigue?