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 las aplicaciones locales con la función IAP Conector local. El conector local usa Cloud Deployment Manager para crear los recursos necesarios para alojar e implementar el Conector IAP local en un tipo de IAP habilitado proyecto de Google Cloud, reenviar solicitudes autenticadas y autorizadas a entornos de Google Chat.

El conector local crea los siguientes recursos:

Una implementación puede tener varios servicios de Cloud servicios de backend 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 app con funciones de y basadas en el contexto las políticas de acceso de Identity and Access Management (IAM). Debido a que un IAM se configura la política de acceso en el servicio a nivel de los recursos, puedes tener diferentes listas de control de acceso tus aplicaciones 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 a el conector IAP local. El conector IAP local Reenvía la solicitud a través de un grupo de extremos de red de conectividad híbrida. de 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?