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 melhor o tráfego.

Com as políticas de autorização, é possível estabelecer verificações de controle de acesso para o tráfego de entrada nos balanceadores de carga de aplicativo. As solicitações que passam nessas verificações são encaminhadas para serviços de back-end. As solicitações que falham 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 são compatíveis com 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 depois de 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 do Identity-Aware Proxy (IAP), mas antes da execução de 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 de 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 corresponder à solicitação de entrada.

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 pode passar pelo 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 é necessá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 do cliente em uma conexão TLS mútua ou pode ser a identidade ambiente associada à instância de máquina virtual (VM) do cliente, como de uma conta de serviço ou 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. 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 passe para o back-end se ela corresponder a qualquer uma das regras especificadas em uma política ALLOW. Se houver políticas ALLOW, 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 a ela. No Cloud Logging, essa ação é registrada como denied_as_no_allow_policies_matched_request.

    Para que uma ação de ALLOW seja aplicada, você precisa de 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 houver políticas DENY, mas nenhuma correspondência, a solicitação será permitida. Em outras palavras, a solicitação será permitida se nenhuma das políticas de autorização configuradas com uma ação DENY corresponder a ela. No Cloud Logging, essa ação é registrada como allowed_as_no_deny_policies_matched_request.

    Para que uma ação de DENY seja aplicada, você precisa de pelo menos uma regra HTTP.

  • CUSTOM: delega a decisão de autorização a um provedor de autorização personalizado, como 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 estão associadas a um único recurso, a política CUSTOM é avaliada primeiro, depois a política DENY e, por fim, a política 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 alguma delas esteja configurada.

  2. Se houver alguma política DENY que corresponda à solicitação, ela será negada. Nenhuma política ALLOW é avaliada, mesmo que esteja configurada.

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

  4. Se alguma das políticas ALLOW corresponder à solicitação, permita-a.

  5. Se houver políticas ALLOW, mas não houver correspondência, a solicitação será negada. Em outras palavras, a solicitação é negada por padrão se nenhuma das AuthzPolicies configuradas com a ação ALLOW corresponder à 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 a provedores de autorização personalizados, como o Identity-Aware Proxy (IAP), ou crie sua própria extensão de autorização usando as Extensões de serviço. Isso é útil quando você quer usar seu 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 balanceador de carga de aplicativo. Para mais informações, consulte Delegar autorização ao IAP e ao IAM.

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

    • Use o IAM para gerenciar permissões.
    • Implemente o acesso baseado no contexto.
    • Use a autenticação baseada em navegador para aplicativos da Web que exigem autenticação interativa.
  • Extensões de serviço: delegue decisões de autorização ao seu mecanismo de autorização personalizado executado 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 baseada 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 . Todo o tráfego originado desses recursos Google Cloud vinculados a uma conta de serviço ou tag 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
Entre VPCs Link de peering cruzado (VPC de peering)
Entre VPCs Private Service Connect entre projetos
Entre VPCs Spokes do Network Connectivity Center entre redes

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 informações sobre cotas de 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, o uso de balanceadores de carga Google Cloud gera cobranças de rede. Para informações sobre preços, consulte Preços.

A seguir