Descripción general de IAP para aplicaciones locales

Identity-Aware Proxy (IAP) te permite administrar el acceso a las apps basadas en HTTP fuera deGoogle Cloud. Esto incluye aplicaciones locales en los centros de datos de tu empresa.

Para obtener información sobre cómo proteger las aplicaciones locales con IAP, consulta cómo configurar IAP para aplicaciones locales.

Introducción

IAP segmenta las apps locales con el conector local de IAP. El conector local usa una plantilla de Cloud Deployment Manager para crear los recursos necesarios para alojar e implementar el conector local de IAP en un proyecto deGoogle Cloud habilitado para IAP, y reenvía las solicitudes autenticadas y autorizadas a las apps locales.

El conector On-Prem crea los siguientes recursos:

Una implementación puede tener varios servicios de backend de Cloud Service Mesh que se ejecutan detrás de un balanceador de cargas de aplicaciones externo. Cada servicio de backend se asigna a una aplicación local individual.

Cuando se implementa el conector local de IAP y se habilita IAP para el servicio de backend del conector local recién creado, IAP protege tu app con políticas de acceso de Identity and Access Management (IAM) basadas en la identidad y el contexto. Debido a que se configura una política de acceso de IAM en el nivel de recurso del servicio de backend, puedes tener diferentes listas de control de acceso para cada una de tus apps locales. Esto significa que solo se necesita un proyecto Google Cloudpara administrar el acceso a varias apps locales.

Cómo funciona IAP para las aplicaciones locales

Cuando se envía una solicitud a una app alojada en Google Cloud, IAP autentica y autoriza las solicitudes del usuario. Luego, le otorga acceso a la app Google Cloud .

Cuando se envía una solicitud a una aplicación local, IAP autentica y autoriza la solicitud del usuario. Luego, enruta la solicitud al conector local de IAP. El conector local de IAP reenvía la solicitud a través de un grupo de extremos de red de conectividad híbrida desde Google Cloud a la red local.

En el siguiente diagrama, se muestra el flujo de tráfico de alto nivel de una solicitud web para una app deGoogle Cloud (app1) y una app local (app2).

Reglas de enrutamiento

Cuando configuras una implementación de conector de IAP, configura las reglas de enrutamiento. Estas reglas enrutan las solicitudes web autenticadas y autorizadas que llegan a tu punto de entrada de nombre de host DNS al nombre de host DNS de destino.

A continuación, se muestra un ejemplo de los parámetros routing definidos para una plantilla de administrador de implementación de conector de 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 nombre routing corresponde a un nuevo recurso de servicio de backend de Compute Engine creado por Ambassador.
  • El parámetro mapping especifica una lista de reglas de enrutamiento de Ambassador para un servicio de backend.
  • El source de una regla de enrutamiento se asigna a un destination, en el que source es la URL de las solicitudes que llegan aGoogle Cloud, y destination es la URL de tu app local a la que IAP enruta el tráfico después de que se autoriza y autentica a un usuario.

En la siguiente tabla, se muestran reglas de ejemplo para enrutar las solicitudes entrantes de www.hr-domain.com a hr-internal.domain.com:

Servicio de backend de Compute Engine Nombre de la regla de enrutamiento Origen Destino
hr 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

¿Qué sigue?