Visão geral da política de autorização

Uma política de autorização (AuthzPolicy) aplicada à regra de encaminhamento dos balanceadores de carga de aplicativo define regras que especificam a origem do tráfego de entrada e as operações permitidas ou restritas para essa origem. Além disso, a política de autorização descreve as condições em que uma regra é aplicada e especifica uma ação para permitir, negar ou avaliar o tráfego.

As políticas de autorização permitem estabelecer verificações de controle de acesso para o tráfego de entrada para balanceadores de carga de aplicativo. As solicitações que passam por essas verificações são roteadas para serviços de back-end. As solicitações que falharem nessas verificações são encerradas com uma resposta não autorizada.

As políticas de autorização podem ser configuradas na regra de encaminhamento de todos os balanceadores de carga de aplicativo com um esquema de balanceamento de carga de EXTERNAL_MANAGED ou INTERNAL_MANAGED. Os seguintes balanceadores de carga de aplicativo oferecem suporte a políticas de autorização:

  • Balanceadores de carga de aplicativos externos globais

  • Balanceadores de carga de aplicativo externos regionais

  • Balanceadores de carga de aplicativo internos regionais

  • Balanceadores de carga de aplicativo internos entre regiões

Nos balanceadores de carga de aplicativo, as políticas de autorização são invocadas após avaliar extensões de rota, políticas de segurança de rede (avaliadas pelo Google Cloud Armor), políticas de compartilhamento de recursos entre origens (CORS) e políticas de Identity-Aware Proxy (IAP), mas antes de executar ações de gerenciamento de tráfego.

Para saber mais sobre quando as políticas de autorização são invocadas no caminho de processamento de solicitações, consulte Pontos de extensibilidade no caminho de dados do balanceamento de carga.

Se você quiser usar políticas de autorização para serviços implantados com o Cloud Service Mesh, consulte Configurar a segurança do serviço com o Envoy.

Regras da política de autorização

Uma política de autorização consiste em uma lista de regras HTTP para correspondência com a solicitação recebida.

Para uma política de autorização com uma ação ALLOW ou DENY, uma regra HTTP (AuthzRule) define as condições que determinam se o tráfego é permitido ou não no balanceador de carga. É necessário ter pelo menos uma regra HTTP.

Para uma política de autorização com uma ação CUSTOM, uma regra HTTP (AuthzRule) define as condições que determinam se o tráfego é delegado ao provedor personalizado para autorização. Um provedor personalizado é obrigatório, enquanto as regras HTTP são opcionais.

Uma correspondência de política ocorre quando pelo menos uma regra HTTP corresponde à solicitação ou quando nenhuma regra HTTP é definida na política.

Uma regra HTTP de política de autorização consiste nos seguintes campos:

  • from: especifica a identidade do cliente permitida pela regra. A identidade pode ser derivada de um certificado de cliente em uma conexão TLS mútua ou pode ser a identidade do ambiente associada à instância de máquina virtual (VM) do cliente, como de uma conta de serviço ou de uma tag segura.
  • to: especifica as operações permitidas pela regra, como os URLs que podem ser acessados ou os métodos HTTP permitidos.
  • when: especifica outras restrições que precisam ser atendidas. É possível usar expressões da Common Expression Language (CEL) para definir as restrições.

Ações da política de autorização

Ao avaliar uma solicitação, uma política de autorização especifica a ação (AuthzAction) a ser aplicada a ela. Uma política de autorização precisa ter pelo menos uma ação, que pode ser uma das seguintes:

  • ALLOW: permite que a solicitação seja transmitida ao back-end se ela corresponder a qualquer uma das regras especificadas em uma política ALLOW. Se as políticas ALLOW existirem, mas não houver correspondência, a solicitação será negada. Em outras palavras, a solicitação será negada se nenhuma das políticas de autorização configuradas com uma ação ALLOW corresponder à solicitação. No Cloud Logging, essa ação é registrada como denied_as_no_allow_policies_matched_request.

    Para que uma ação ALLOW seja aplicada, é necessário ter pelo menos uma regra HTTP.

  • DENY: nega a solicitação se ela corresponder a qualquer uma das regras especificadas em uma política DENY. Se as políticas DENY existirem, mas não houver correspondência, a solicitação será permitida. Em outras palavras, a solicitação é permitida se nenhuma das políticas de autorização configuradas com uma ação DENY corresponder à solicitação. No Cloud Logging, essa ação é registrada como allowed_as_no_deny_policies_matched_request.

    Para que uma ação DENY seja aplicada, é necessário ter pelo menos uma regra HTTP.

  • CUSTOM: delega a decisão de autorização a um provedor de autorização personalizado, como o IAP ou extensões de serviço. Para saber mais, consulte Usar políticas de autorização para delegar decisões de autorização.

    Se houver regras HTTP configuradas para uma política CUSTOM, a solicitação precisará corresponder às regras HTTP para invocar o provedor personalizado. No entanto, se nenhuma regra HTTP for definida, a política de autorização sempre vai delegar a decisão de autorização a um provedor de autorização personalizado. Para saber mais, confira o exemplo a seguir em que nenhuma regra HTTP é definida e a política de autorização delega a decisão de autorização a um IAP:

    Criar a política de autorização e ativar o IAP

Ordem de avaliação da política de autorização

Uma política de autorização oferece suporte a políticas CUSTOM, DENY e ALLOW para controle de acesso. Quando várias políticas de autorização são associadas a um recurso, a política CUSTOM é avaliada primeiro, depois a DENY e, por fim, a ALLOW. A avaliação é determinada pelas seguintes regras:

  1. Se houver uma política CUSTOM que corresponda à solicitação, ela será avaliada usando os provedores de autorização personalizados, e a solicitação será negada se o provedor a rejeitar.CUSTOM As políticas DENY ou ALLOW não são avaliadas, mesmo que estejam configuradas.

  2. Se houver políticas DENY que correspondam à solicitação, ela será negada. As políticas ALLOW não são avaliadas, mesmo que configuradas.

  3. Se não houver políticas ALLOW, a solicitação será permitida.

  4. Se alguma das políticas ALLOW corresponder à solicitação, ela será permitida.

  5. Se as políticas ALLOW existirem, mas não houver correspondência, a solicitação será negada. Em outras palavras, a solicitação é negada por padrão se nenhuma das ações AuthzPolicies com ALLOW configuradas corresponderem à solicitação.

Usar políticas de autorização para delegar decisões de autorização

Para decisões de autorização complexas que não podem ser expressas usando a política de autorização, delegue a decisão de autorização a provedores de autorização personalizados, como o proxy Aware Identity (IAP), ou crie sua própria extensão de autorização usando extensões de serviço. Isso é útil quando você quer usar o mecanismo de autorização local ou provedores de identidade de terceiros pelo IAP.

  • IAP: configure o IAP para controlar o acesso a aplicativos por trás das regras de encaminhamento do balanceador de carga de aplicativo. O IAP verifica a identidade e o contexto do usuário para determinar o acesso. Ele também pode autenticar tokens de conta de serviço do Identity and Access Management (IAM) e avaliar políticas do IAM, protegendo o acesso a buckets de back-end expostos pelo Application Load Balancer. Para mais informações, consulte Delegar autorização para o IAP e o IAM.

    Você pode delegar a autenticação para o IAP e o IAM nos seguintes cenários:

    • Use o IAM para gerenciamento de permissões.
    • Implementar o acesso baseado no contexto.
    • Use a autenticação baseada no navegador para aplicativos da Web que exigem autenticação interativa.

  • Extensões de serviço: delegue decisões de autorização para o mecanismo de autorização personalizado em execução em instâncias de VM Google Cloud ou no local. Isso oferece flexibilidade para políticas de autorização complexas que não são cobertas por políticas integradas. Para mais informações, consulte Configurar uma extensão de autorização.

Política de autorização com base em contas de serviço ou tags

É possível usar atributos como contas de serviço ou tags para identificar a origem do tráfego dos balanceadores de carga de aplicativo internos.

Para balanceadores de carga de aplicativo internos, é possível aplicar políticas de autorização com base em contas de serviço ou tags anexadas a recursos Google Cloud . Qualquer tráfego originado desses recursos Google Cloud vinculados a uma conta ou tag de serviço específica pode ser permitido, negado ou delegado a um serviço externo.

As tabelas a seguir listam os recursos de origem e as diferentes arquiteturas de nuvem privada virtual (VPC) que oferecem suporte ao uso de contas de serviço e tags.

Origem Suporte para contas de serviço Suporte a tags
VM
Nó do GKE
Contêiner do GKE * *
VPC direta para o Cloud Run *
Conector de acesso VPC sem servidor † †
Cloud VPN * *
Cloud Interconnect no local * *
Balanceador de carga de aplicativo
Balanceador de carga de rede

* Não é compatível com Google Cloud.

† O endereço IP de origem é exclusivo e pode ser usado.

VPC Arquitetura da VPC Suporte
Na VPC Entre projetos (VPC compartilhada)
Na VPC Entre regiões
VPC cruzada Vínculo de peering cruzado (VPC de peer)
VPC cruzada Cross Private Service Connect
VPC cruzada Spokes da Central de conectividade de rede

Para saber mais sobre como configurar uma política de autorização baseada em contas de serviço e tags anexadas a um recurso de VM Google Cloud , consulte Política de autorização baseada em contas de serviço ou tags.

Cotas

Para mais informações sobre cotas para políticas de autorização, consulte cotas e limites para políticas de autorização.

Preços

As políticas de autorização não são cobradas durante o período de pré-lançamento. No entanto, você vai incorrer em cobranças de rede ao usar Google Cloud balanceadores de carga. Para informações sobre preços, consulte Preços.

A seguir