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 segmenta apps locais com a API IAP Conector local. O conector no local usa um Cloud Deployment Manager para criar os recursos necessários para hospedar e implantar o Conector local do IAP em um conector habilitado para IAP projeto do Google Cloud, e encaminhar solicitações autenticadas e autorizadas para ambientes apps.
Conector no local cria os seguintes recursos:
- Uma implantação do Cloud Service Mesh que atua como um proxy para o app local.
- Um balanceador de carga de aplicativo externo que atua como controlador de entrada para solicitações.
- Regras de roteamento.
Uma implantação pode ter várias instâncias serviços de back-end executados 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 local do IAP for implantado e o IAP for ativado para o serviço de back-end do conector local recém-criado, o IAP protege seu aplicativo com e baseadas em contexto Políticas de acesso do Identity and Access Management (IAM). 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. 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 do Google Cloud para a rede no local.
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 umdestination
, em quesource
é o URL das solicitações recebidas no Google Cloud edestination
é 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
- Saiba como proteger apps locais com o IAP.
- Saiba mais sobre como o IAP funciona.