Visão geral do IAP para apps locais

O Identity-Aware Proxy (IAP) permite 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 segmenta apps no local com o conector no local do IAP. O conector no local usa um modelo do Cloud Deployment Manager para criar os recursos necessários para hospedar e implantar o conector no local do IAP em umGoogle Cloud projeto ativado para IAP, encaminhando solicitações autenticadas e autorizadas para apps locais.

O conector no local cria os seguintes recursos:

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

Quando o conector no local da IAP é implantado e a IAP é ativada para o serviço de back-end do conector no local recém-criado, a IAP protege seu app com políticas de acesso de identidade e do Identity and Access Management (IAM) baseadas em contexto. 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 apenas um projeto Google Cloud é necessário para gerenciar o acesso a vários apps locais.

Como o IAP para apps locais funciona

Quando uma solicitação é enviada a 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. Em seguida, ele encaminha a solicitação para o conector no local do IAP. O conector no 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 app Google 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 roteiam solicitações da Web autenticadas e autorizadas que chegam ao ponto de entrada do nome do host DNS para o nome do host 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.
  • O source de uma regra de rota é mapeado para um destination, em que source é o URL das solicitações que chegam a Google Cloud, e destination é o URL do seu app local para onde o IAP direciona o tráfego depois que um usuário é 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