Descripción general de IAP para aplicaciones locales

Identity-Aware Proxy (IAP) te permite administrar el acceso a aplicaciones basadas en HTTP fuera de Google 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 se orienta a aplicaciones locales con el conector local de IAP. El conector local usa una plantilla de Cloud Deployment Manager a fin de crear los recursos necesarios para alojar y, luego, implementar el conector de IAP en un proyecto de Google Cloud habilitado para IAP, lo que reenvía las solicitudes autenticadas y autorizadas a aplicaciones locales.

El conector local crea los siguientes recursos:

Una implementación puede tener varios servicios de backend de Traffic Director 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 IAP local y se habilita IAP para el servicio de backend del conector local recién creado, IAP protege tu aplicación con políticas de acceso de Identity and Access Management (IAM) y de identidad basadas en el contexto. Debido a que una política de acceso de IAM se configura en el nivel de recursos 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 de Google Cloud para administrar el acceso a varias aplicaciones locales.

Cómo funciona IAP para las aplicaciones locales

Cuando se envía una solicitud a una aplicación alojada en Google Cloud, IAP autentica y autoriza las solicitudes de los usuarios. Luego, le otorga al usuario acceso a la aplicación de 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 de IAP local. El conector de IAP local 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 aplicación de Google Cloud (app1) y una aplicación 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 destination, donde source es la URL de solicitudes que llegan a Google Cloud y destination es la URL de tu aplicación local a la que IAP enruta el tráfico después de que un usuario haya sido autorizado y autenticado.

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?