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 adjunta cuentas de servicio o etiquetas a las VMs de Google Cloud

En el caso de los balanceadores de cargas de aplicaciones internos, puedes aplicar políticas de autorización basadas en cuentas de servicio o etiquetas adjuntas a un recurso de VM de Google Cloud . Cualquier solicitud que provenga de una VM cliente que esté vinculada a una cuenta de servicio o etiqueta específica se puede permitir, rechazar o delegar a un servicio externo. En la sección Política de autorización basada en cuentas de servicio o etiquetas de este documento, se proporciona un ejemplo de una política de autorización que usa cuentas de servicio y etiquetas para aplicar el control de acceso.

La aplicación de políticas de autorización basadas en cuentas de servicio o etiquetas no es compatible con los balanceadores de cargas de aplicaciones externos.

Conecta cuentas de servicio a VMs de cliente

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

Adjunta etiquetas a la plantilla de grupo de instancias

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

Crea una clave y un valor de etiqueta

Para crear etiquetas, 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 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.

    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 la clave de etiqueta.
    • ORG_ID: el ID de tu organización.
    • LB_NETWORK: El nombre de tu red de VPC

  2. Agrega el valor de la etiqueta 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 a la plantilla del grupo de instancias

Los administradores de etiquetas pueden vincular etiquetas 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, 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: 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: Tu región de Google Cloud .
    • TAG_KEY: Es el nombre de tu 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 de tu 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 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 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.

    $ 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"
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 de tu proyecto de Google Cloud .
    • LOCATION: 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 de tu 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 específica de Google Cloud . 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/regions/LOCATION/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. 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 de tu proyecto de Google Cloud .
    • LOCATION: 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 basada en cuentas de servicio o etiquetas

Puedes aplicar políticas de autorización basadas en cuentas de servicio o etiquetas solo en balanceadores de cargas de aplicaciones internos. Se puede permitir, denegar o delegar a un servicio externo cualquier tráfico que provenga de una VM cliente vinculada a una cuenta de servicio o etiqueta específicas.

Si deseas crear y adjuntar cuentas de servicio o etiquetas a las VMs de Google Cloud , consulta la sección Crea y adjunta cuentas de servicio o etiquetas a las VMs de Google Cloud en este documento.

Cuenta de servicio

  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 de un balanceador de cargas de aplicaciones interno regional. La política está configurada para denegar las solicitudes de cualquier VM cliente con la cuenta de servicio my-sa-123@PROJECT_ID.iam.gserviceaccount.com para llegar a la ruta de acceso /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:
    - 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 un balanceador de cargas de aplicaciones interno regional, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID de tu proyecto de Google Cloud .
    • LOCATION: 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ítica creado anteriormente y se crea la política de autorización en la región especificada de Google Cloud .

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

    Reemplaza lo siguiente:

    • LOCATION: Tu región de Google Cloud .

Etiqueta

  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 de un balanceador de cargas de aplicaciones interno regional. La política solo permite que las solicitudes que se originan en una VM con la etiqueta de recurso TAG_VALUE 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/regions/LOCATION/forwardingRules/LB_FORWARDING_RULE"
httpRules:
- from:
  sources:
    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. Para un balanceador de cargas de aplicaciones interno regional, establece el esquema en INTERNAL_MANAGED.
    • PROJECT_ID: El ID de tu proyecto de Google Cloud .
    • LOCATION: 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 especificada deGoogle Cloud :

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

    Reemplaza lo siguiente:

    • LOCATION: Tu región de Google Cloud .

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 de tu 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 de tu proyecto de Google Cloud .
    • LOCATION: 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, revisa las siguientes secciones.

La solicitud no coincide con las políticas de ALLOW ni de DENY

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"
      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\" 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"
  }

La solicitud coincide con la política de DENY

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

La solicitud no coincide con la política de DENY, pero sí con la de ALLOW

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?