Visão geral do IAP para apps locais

Com o Identity-Aware Proxy (IAP), é possível gerenciar o acesso a apps baseados em HTTP fora doGoogle Cloud. Isso inclui apps locais nos data centers da sua empresa.

Para saber como proteger seus apps locais com IAP, consulte este documento.

Introdução

O IAP protege os apps locais com o conector local do IAP. O conector local usa um modelo do Cloud Deployment Manager para criar os recursos necessários para hospedar e implantar o conector local do IAP em um projeto doGoogle Cloud com o IAP ativado, encaminhando as solicitações autenticadas e autorizadas para apps locais.

O conector on-prem cria os seguintes recursos:

Uma implantação pode ter vários serviços de back-end do Cloud Service Mesh executados atrás de um balanceador de carga de aplicativo externo. Cada serviço de back-end é mapeado para um app local individual.

Quando o conector local do IAP é implantado e o IAP é ativado para o serviço de back-end do conector local recém-criado, o IAP protege o app com políticas de acesso do Identity and Access Management (IAM) baseadas no contexto e em identidades. Como uma política de acesso do IAM está configurada no nível do recurso de serviço de back-end, é possível ter listas de controle de acesso diferentes para cada um dos seus aplicativos locais. Isso significa que basta um único projeto do Google Cloud para gerenciar o acesso a vários apps locais.

Como o IAP para apps locais funciona

Quando uma solicitação é enviada para um app hospedado no Google Cloud, o IAP autentica e autoriza as solicitações do usuário. Em seguida, ele concede ao usuário acesso ao app Google Cloud .

O IAP também pode ser usado para autenticar e autorizar solicitações de usuários para apps locais. Nesse caso, ele encaminha as solicitações para o conector local do IAP que, O conector local do IAP encaminha a solicitação por um grupo de endpoints de rede de conectividade híbrida de Google Cloud para a rede local.

O diagrama a seguir mostra o fluxo de tráfego de alto nível de uma solicitação da Web para um appGoogle Cloud (app1) e um app local (app2).

Regras de roteamento

Ao configurar uma implantação de conector do IAP, você precisa configurar as regras de roteamento. Essas regras encaminham as solicitações da Web autenticadas e autorizadas recebidas no ponto de entrada do seu nome de host de DNS para o nome de host de DNS de destino.

Veja a seguir um exemplo de parâmetros routing definidos para um modelo do Deployment Manager de conector do IAP.

   routing:
     - name: hr
       mapping:
        - name: host
          source: www.hr-domain.com
          destination: hr-internal.domain.com
        - name: sub
          source: sheets.hr-domain.com
          destination: sheets.hr-internal.domain.com
     - name: finance
       mapping:
        - name: host
          source: www.finance-domain.com
          destination: finance-internal.domain.com
  • Cada nome de routing corresponde a um recurso novo do serviço de back-end do Compute Engine criado pelo Ambassador.
  • O parâmetro mapping especifica uma lista de regras de roteamento do Ambassador para um serviço de back-end.
  • A source de uma regra de roteamento é mapeada para um destination, em que source é o URL das solicitações recebidas noGoogle Cloude destination é o URL do seu app local, para onde o IAP encaminha o tráfego após o usuário ser autorizado e autenticado.

A tabela a seguir traz exemplos de regra para encaminhar as solicitações recebidas em www.hr-domain.com para hr-internal.domain.com:

Serviço de back-end do Compute Engine Nome da regra de roteamento Fonte Destino
h hr-host www.hr-domain.com hr-internal.domain.com
hr-sub sheets.hr-domain.com sheets.hr-internal.domain.com
finance = finance-host www.finance-domain.com finance-internal.domain.com

A seguir