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 do Google 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 do IAP (em inglês). Esse modelo configurável do Cloud Deployment Manager cria os recursos necessários para hospedar e implantar o conector do IAP em um projeto do Google Cloud com o Identity-Aware Proxy ativado, encaminhando as solicitações autenticadas e autorizadas para apps locais.

O modelo configurável do Cloud Deployment Manager cria os seguintes recursos:

Uma implantação pode ter vários serviços de back-end do Compute Engine criados por Ambassador executados atrás de um balanceador de carga HTTP(S) externo. Cada serviço de back-end é mapeado para um app local individual.

Depois que o conector é implantado, o IAP protege o app com políticas de acesso do gerenciamento de identidade e acesso (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

No caso de um app hospedado no Google Cloud, o IAP autentica e autoriza as solicitações de usuários enviadas a esse aplicativo. Assim, ele concede ao usuário acesso ao app no 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 de IAP que, por sua vez, as envia do Google Cloud para a rede local por meio de uma conexão local a local estabelecida com o Cloud Interconnect .

O diagrama a seguir mostra de modo geral o fluxo do tráfego de uma solicitação da Web para um aplicativo no Google Cloud (app1) e para um aplicativo 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 no Google Cloud e 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