Vista geral das CAs para apps no local

O Identity-Aware Proxy (IAP) permite-lhe gerir o acesso a apps baseadas em HTTP fora do Google Cloud. Isto inclui apps no local nos centros de dados da sua empresa.

Para saber como proteger apps no local com o IAP, consulte o artigo Configurar o IAP para apps no local.

Introdução

O IAP segmenta apps no local com o conetor no local do IAP. O conetor nas instalações usa um modelo do Cloud Deployment Manager para criar os recursos necessários para alojar e implementar o conetor nas instalações do IAP numGoogle Cloud projeto com o IAP ativado, encaminhando pedidos autenticados e autorizados para apps nas instalações.

O conector no local cria os seguintes recursos:

Uma implementação pode ter vários serviços de back-end do Cloud Service Mesh que são executados atrás de um Application Load Balancer externo. Cada serviço de back-end é mapeado para uma app no local individual.

Quando o conector no local do IAP é implementado e o IAP é ativado para o serviço de back-end do conector no local recém-criado, o IAP protege a sua app com identidade e políticas de acesso de gestão de identidade e de acesso (IAM) com base no contexto. Uma vez que uma política de acesso do IAM está configurada ao nível do recurso do serviço de back-end, pode ter diferentes listas de controlo de acesso para cada uma das suas apps no local. Isto significa que só é necessário um Google Cloud projeto para gerir o acesso a várias apps no local.

Como funcionam as CAs para apps no local

Quando um pedido é enviado para uma app alojada no Google Cloud, o IAP autentica e autoriza os pedidos do utilizador. Em seguida, concede ao utilizador acesso à Google Cloud app.

Quando um pedido é enviado para uma app no local, o IAP autentica e autoriza o pedido do utilizador. Em seguida, encaminha o pedido para o conetor no local do IAP. O conector no local do IAP encaminha o pedido através de um grupo de pontos finais da rede de conetividade híbrida de Google Cloud para a rede no local.

O diagrama seguinte mostra o fluxo de tráfego de alto nível de um pedido Web para uma Google Cloud app (app1) e uma app no local (app2).

Regras de encaminhamento

Quando configura uma implementação do conector de IAP, configura as regras de encaminhamento. Estas regras encaminham pedidos Web autenticados e autorizados que chegam ao ponto de entrada do nome de anfitrião de DNS para o nome de anfitrião de DNS que é o destino.

Segue-se um exemplo de parâmetros routing definidos para um modelo do Deployment Manager do conetor de CNA.

   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 routing corresponde a um novo recurso de serviço de back-end do Compute Engine criado pelo Ambassador.
  • O parâmetro mapping especifica uma lista de regras de encaminhamento do Ambassador para um serviço de back-end.
  • O source de uma regra de encaminhamento é mapeado para um destination, onde source é o URL dos pedidos que chegam a Google Cloude destination é o URL da sua app no local para o qual o IAP encaminha o tráfego depois de um utilizador ter sido autorizado e autenticado.

A tabela seguinte demonstra regras de exemplo para encaminhar pedidos recebidos de www.hr-domain.com para hr-internal.domain.com:

Serviço de back-end do Compute Engine Nome da regra de encaminhamento Origem Destino
hr hr-host www.hr-domain.com hr-internal.domain.com
hr-sub sheets.hr-domain.com sheets.hr-internal.domain.com
finanças finance-host www.finance-domain.com finance-internal.domain.com

O que se segue?