Configure políticas de autorização para equilibradores de carga de aplicações

Esta página mostra como configurar políticas de autorização para equilibradores de carga de aplicações.

Antes de começar

Configure o balanceador de carga

Se não tiver criado um balanceador de carga, consulte as páginas seguintes para configurar o balanceador de carga de aplicações preferencial:

Crie e anexe contas de serviço ou etiquetas a Google Cloud VMs

Para equilibradores de carga de aplicações internos, pode aplicar políticas de autorização com base em contas de serviço ou etiquetas anexadas a diferentes Google Cloud recursos.

O exemplo neste documento fornece instruções para criar uma política de autorização com base em contas de serviço ou etiquetas anexadas a instâncias de máquinas virtuais (VM). Google Cloud Qualquer pedido originado numa VM cliente associada a uma conta de serviço ou uma etiqueta específica pode ser permitido, recusado ou delegado a um serviço externo. Um exemplo de uma política de autorização deste tipo que usa contas de serviço e etiquetas para aplicar o controlo de acesso é fornecido na secção Política de autorização baseada em contas de serviço ou etiquetas deste documento.

A aplicação de políticas de autorização com base em contas de serviço ou etiquetas não é suportada para equilibradores de carga de aplicações externos.

Anexe contas de serviço a VMs de cliente

Para instruções sobre como anexar uma conta de serviço a uma instância de VM, consulte os seguintes documentos:

Anexe etiquetas ao modelo do grupo de instâncias

Antes de associar uma etiqueta ao modelo de grupo de instâncias, tem de criar uma chave e um valor de etiqueta. Quando cria uma etiqueta, atribui-lhe uma finalidade.As funcionalidades de rede, incluindo o proxy Web seguro e as políticas de autorização, requerem a finalidade para aplicar a etiqueta.GCE_FIREWALLGCE_FIREWALL Google Cloud

Crie uma chave e um valor de etiqueta

Para criar etiquetas, precisa da função de administrador da etiqueta (roles/resourcemanager.tagAdmin).

Consola

  1. Na Google Cloud consola, aceda à página Etiquetas.

    Aceda a Etiquetas

  2. Clique em Criar.

  3. No campo Descrição da chave da etiqueta, introduza uma descrição.

  4. Selecione a caixa de verificação Para utilização com firewall de rede.

  5. Na lista Projeto, selecione o Google Cloud projeto onde quer criar a etiqueta.

  6. No campo Rede, selecione LB_NETWORK.

  7. Clique em Adicionar valor.

  8. No campo Valor da etiqueta, introduza TAG_VALUE. O valor tem de ser numérico.

  9. No campo Descrição do valor da etiqueta, introduza uma descrição.

  10. Quando terminar de adicionar valores de etiquetas, clique em Criar chave de etiqueta.

gcloud

  1. Crie a chave da etiqueta.

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

    Substitua o seguinte:

    • TAG_KEY: o nome da chave da etiqueta.
    • ORG_ID: o ID da sua organização.
    • LB_NETWORK: o nome da sua rede VPC.

  2. Adicione o valor da etiqueta à chave da etiqueta numérica.

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

    Substitua TAG_VALUE por um valor de etiqueta numérico.

Associe a etiqueta ao modelo de grupo de instâncias

Os administradores de etiquetas podem associar etiquetas a instâncias de VMs individuais ou ao modelo do grupo de instâncias e anexar o valor da etiqueta aos back-ends das VMs ou do modelo.

Para associar etiquetas, precisa da função de utilizador de etiquetas (roles/resourcemanager.tagUser).

  1. Defina o prefixo do nome completo para o seu projeto e zona:

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

    Substitua o seguinte:

    • PROJECT_ID: o ID do seu projeto.
    • ZONE: a zona em que o grupo de instâncias geridas está localizado.

  2. Obtenha o ID do modelo de grupo de instâncias:

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

    Substitua o seguinte:

    • TEMPLATE_NAME: o nome do modelo de grupo de instâncias.
    • LOCATION: a sua Google Cloud região.

  3. Concatenar os valores de FULL_NAME_PREFIX e TEMPLATE_ID:

    PARENT="$FULL_NAME_PREFIX$TEMPLATE_ID"
echo $PARENT

  4. Crie as associações.

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

    Substitua o seguinte:

    • ORG_ID: o ID da sua organização.
    • LOCATION: a sua Google Cloud região.
    • TAG_KEY: o nome da chave da etiqueta segura.
    • TAG_VALUE: o valor numérico da etiqueta.

Crie uma política de autorização

Para criar uma política de autorização, cria um ficheiro YAML que define o destino e as regras e, em seguida, importa o ficheiro através do comando gcloud beta network-security authz-policies.

Esta secção fornece instruções para criar diferentes tipos de políticas de autorização anexadas à regra de encaminhamento de um equilibrador de carga.

Política de autorização para recusar pedidos

Esta secção fornece um exemplo de política de autorização que nega pedidos com base em determinados atributos de pedidos.

Global

Se estiver a usar um Application Load Balancer externo global, siga estes passos para criar e importar uma política de autorização que recusa pedidos com base em intervalos de endereços IP:

  1. Crie um ficheiro YAML de política de autorização para negar determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-deny.yaml para a regra de encaminhamento LB_FORWARDING_RULE na localização global. A política nega o acesso ao caminho do URL /api/payments a clientes com endereços IP no intervalo 10.0.0.0/24.

    $ 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:
    - ipBlocks:
      - prefix: "10.0.0.0"
        length: "24"
- to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para o balanceador de carga de aplicações externo global, defina o esquema como EXTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização:

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

Entre regiões

Se estiver a usar um Application Load Balancer interno entre regiões, siga estes passos para criar e importar uma política de autorização que recuse pedidos com base nos diretores do certificado de cliente.

  1. Crie um ficheiro YAML de política de autorização para negar determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-deny.yaml para a regra de encaminhamento LB_FORWARDING_RULE na global localização. A política nega o acesso ao caminho do URL /api/payments a clientes que tenham www.example.com nos SANs do nome DNS do certificado de cliente.

    $ 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:
      - principalSelector: CLIENT_CERT_DNS_NAME_SAN
        principal:
          exact: "www.example.com"
  to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para o balanceador de carga de aplicações interno entre regiões, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização:

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

Regional

Se estiver a usar um Application Load Balancer externo regional ou um Application Load Balancer interno regional, siga estes passos para criar e importar uma política de autorização que recusa pedidos com base nos diretores do certificado de cliente.

  1. Crie um ficheiro YAML de política de autorização para negar determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-deny.yaml para a regra de encaminhamento LB_FORWARDING_RULE numaGoogle Cloud região. A política nega o acesso ao caminho do URL /api/payments a clientes que tenham www.example.com nos SANs do nome DNS do certificado de cliente.

    $ 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:
      - principalSelector: CLIENT_CERT_DNS_NAME_SAN
        principal:
          exact: "www.example.com"
  to:
    operations:
    - paths:
      - prefix: "/api/payments"
action: DENY
EOF

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para o balanceador de carga de aplicações externo regional, defina o esquema como EXTERNAL_MANAGED. Para o balanceador de carga de aplicações interno regional, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LOCATION: a sua Google Cloud região.
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O seguinte comando de exemplo importa o ficheiro de política criado anteriormente e cria uma política de autorização na região LOCATION:

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

Política de autorização para permitir pedidos

Esta secção fornece um exemplo de política de autorização que permite pedidos originários de intervalos de endereços IP específicos.

Global e entre regiões

Se estiver a usar um Application Load Balancer externo global ou um Application Load Balancer interno entre regiões, siga estes passos para criar e importar uma política de autorização:

  1. Crie um ficheiro YAML de política de autorização para permitir determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-allow.yaml para a regra de encaminhamento LB_FORWARDING_RULE na localização global. A política permite que os clientes com endereços IP no intervalo 10.0.0.0/24 acedam ao caminho do 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:
    - ipBlocks:
      - prefix: "10.0.0.0"
        length: "24"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para o balanceador de carga de aplicações externo global, defina o esquema como EXTERNAL_MANAGED. Para o balanceador de carga de aplicações interno entre regiões, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização:

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

Regional

Se estiver a usar um Application Load Balancer externo regional ou um Application Load Balancer interno regional, siga estes passos para criar e importar uma política de autorização:

  1. Crie um ficheiro YAML de política de autorização para permitir determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-allow.yaml para a regra de encaminhamento LB_FORWARDING_RULE numa região específica Google Cloud . A política permite que os clientes com endereços IP no intervalo 10.0.0.0/24 acedam ao caminho do 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:
    - ipBlocks:
      - prefix: "10.0.0.0"
        length: "24"
  to:
    operations:
    - paths:
      - exact: "/api/payments"
action: ALLOW
EOF

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Se estiver a usar um Application Load Balancer externo regional, defina o esquema como EXTERNAL_MANAGED. Se estiver a usar o Application Load Balancer interno regional, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LOCATION: a sua Google Cloud região.
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização na região LOCATION:

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

Política de autorização baseada em contas de serviço ou etiquetas

Pode aplicar políticas de autorização com base em contas de serviço ou etiquetas apenas em equilibradores de carga de aplicações internos. Qualquer tráfego proveniente de uma VM de cliente associada a uma conta de serviço ou uma etiqueta específica pode ser permitido, recusado ou delegado a um serviço externo.

Se quiser criar e anexar contas de serviço ou etiquetas a Google Cloud VMs, consulte a secção Crie e anexe contas de serviço ou etiquetas a Google Cloud VMs neste documento.

Conta de serviço

  1. Crie um ficheiro YAML de política de autorização para negar determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-deny.yaml para a regra de encaminhamento LB_FORWARDING_RULE de um balanceador de carga de aplicações interno regional. A política está configurada para recusar pedidos de todas as VMs de cliente com a conta de serviço my-sa-123@PROJECT_ID.iam.gserviceaccount.com para alcançar o caminho /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

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para um balanceador de carga de aplicações interno regional, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LOCATION: a sua Google Cloud região.
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização na Google Cloud região especificada.

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

    Substitua o seguinte:

    • LOCATION: a sua Google Cloud região.

Etiqueta

  1. Crie um ficheiro YAML de política de autorização para permitir determinados pedidos.

    O exemplo seguinte cria um ficheiro authz-policy-allow.yaml para a regra de encaminhamento LB_FORWARDING_RULE de um balanceador de carga de aplicações interno regional. A política só permite que os pedidos originados de uma VM com a etiqueta de recurso TAG_VALUE acedam ao caminho do 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

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para um balanceador de carga de aplicações interno regional, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LOCATION: a sua Google Cloud região.
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização naGoogle Cloud região especificada:

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

    Substitua o seguinte:

    • LOCATION: a sua Google Cloud região.

Política de autorização para delegar numa extensão de serviço

Antes de começar, configure um motor de autorização externo. Para mais informações sobre extensões de serviços, consulte o artigo Vista geral dos destaques de chamadas do Cloud Load Balancing.

Global e entre regiões

Se estiver a usar um Application Load Balancer externo global ou um Application Load Balancer interno entre regiões, siga estes passos para criar e importar uma política de autorização:

  1. Crie um ficheiro de política de autorização para delegar determinados pedidos num serviço externo.

    O exemplo seguinte cria um ficheiro authz-policy-custom.yaml para a regra de encaminhamento LB_FORWARDING_RULE na localização global. A política chama a extensão AUTHZ_EXTENSION para todo o tráfego para o caminho do URL /api/payments quando o pedido contém um cabeçalho Authorization não vazio.

    $ 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

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para o balanceador de carga de aplicações externo global, defina o esquema como EXTERNAL_MANAGED. Para o balanceador de carga de aplicações interno entre regiões, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.
    • AUTHZ_EXTENSION: o nome da extensão de autorização.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização:

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

Regional

Se estiver a usar um Application Load Balancer externo regional ou um Application Load Balancer interno regional, siga estes passos para criar e importar uma política de autorização:

  1. Crie um ficheiro YAML de política de autorização para delegar determinados pedidos a um serviço externo.

    O exemplo seguinte cria um ficheiro authz-policy-custom.yaml para a regra de encaminhamento LB_FORWARDING_RULE numa região de um balanceador de carga de aplicações interno regional. Google Cloud A política chama a extensão AUTHZ_EXTENSION para todo o tráfego para o caminho do URL /api/payments quando o pedido contém um cabeçalho Authorization não vazio.

    $ 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

    Substitua o seguinte:

    • LB_SCHEME: o seu esquema de balanceamento de carga. Para o balanceador de carga de aplicações externo regional, defina o esquema como EXTERNAL_MANAGED. Para o balanceador de carga de aplicações interno regional, defina o esquema como INTERNAL_MANAGED.
    • PROJECT_ID: o ID do seu projeto Google Cloud .
    • LOCATION: a sua Google Cloud região.
    • LB_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga.
    • AUTHZ_EXTENSION: o nome da extensão de autorização.

  2. Crie uma política de autorização e importe o ficheiro YAML.

    O comando de exemplo seguinte importa o ficheiro de política criado anteriormente e cria uma política de autorização na região LOCATION:

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

Teste uma política de autorização

Para testar uma política de autorização, envie algum tráfego para o equilibrador de carga. Para mais informações, consulte as seguintes páginas:

Compreenda os registos da política de autorização nos Registos na nuvem

Para compreender como as políticas de autorização são registadas quando um pedido é permitido ou recusado, reveja as secções seguintes.

O pedido não corresponde às políticas de ALLOW nem de DENY

Quando um pedido não corresponde à política ALLOW nem à política DENY, a política DENY permite o pedido e regista-o como allowed_as_no_deny_policies_matched_request. Por outro lado, a política ALLOW rejeita o pedido e regista-o como denied_as_no_allow_policies_matched_request. Uma vez que uma das políticas recusa o pedido, o pedido é recusado.

  • Se estiver a usar um Application Load Balancer externo global, statusDetails está definido como denied_by_authz_policy no registo. Veja o exemplo seguinte:

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

  • Se estiver a usar um Application Load Balancer interno regional, um Application Load Balancer externo regional ou um Application Load Balancer interno entre regiões, proxyStatus é definido como error=\"http_request_error\"; details=\"denied_by_authz_policy\" no registo. Veja o exemplo seguinte:

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

O pedido corresponde à Política do DENY

Quando um pedido corresponde à política DENY, é recusado e a política que recusou o pedido é registada.

  • Se estiver a usar um Application Load Balancer externo global, statusDetails é definido como denied_by_authz_policy no registo, e o nome da política que recusou o pedido é registado em policies. Veja o exemplo seguinte:

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

  • Se estiver a usar um Application Load Balancer interno regional, um Application Load Balancer externo regional ou um Application Load Balancer interno entre regiões, proxyStatus é definido como error=\"http_request_error\"; details=\"denied_by_authz_policy\" e o nome da política é registado em policies. Veja o exemplo seguinte:

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

A solicitação não corresponde à Política DENY, mas corresponde à Política ALLOW

Quando um pedido não corresponde à política do DENY, mas corresponde à política do ALLOW, o pedido é permitido. No registo, esta ação é registada como allowed_as_no_deny_policies_matched_request para a política DENY. A política que permitiu o pedido também é registada.

  • Se estiver a usar um Application Load Balancer externo global, não existe statusDetails no registo. A política que permitiu o pedido também é registada no policies. Veja o exemplo seguinte:

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

  • Se estiver a usar um Application Load Balancer interno regional, um Application Load Balancer externo regional ou um Application Load Balancer interno entre regiões, não existe o campo proxyStatus no registo. A política que permitiu o pedido também é registada em policies. Veja o exemplo seguinte:

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

O que se segue?