Habilita IAP para GKE

En esta página, se explica cómo proteger una instancia de Google Kubernetes Engine (GKE) con Identity-Aware Proxy (IAP).

Descripción general

IAP está integrado a través de Ingress para GKE. Esta integración te permite controlar el nivel de acceso de los empleados en lugar de usar una VPN.

En el clúster de GKE, el tráfico entrante es controlado por el balanceo de cargas de HTTP(S), un componente de Cloud Load Balancing. Por lo general, el balanceador de cargas de HTTP(S) está configurado por el controlador de Ingress de Kubernetes. El controlador de Ingress recibe información sobre la configuración de un objeto Ingress de Kubernetes, que está vinculado con uno o más objetos de Servicio. Cada objeto de servicio contiene información de enrutamiento que se usa para direccionar una solicitud entrante a un pod o puerto específico.

A partir de la versión Kubernetes 1.10.5-gke.3, tienes la posibilidad de agregar configuraciones al balanceador de cargas mediante la asociación de un servicio con un objeto de BackendConfig. BackendConfig es una definición personalizada de recurso (CRD) que está definida en el repositorio kubernetes/ingress-gce.

El controlador de ingreso de Kubernetes lee los datos de configuración provenientes de BackendConfig y configura el balanceador de cargas según corresponda. BackendConfig contiene datos de configuración específicos de Cloud Load Balancing y permite definir una configuración aparte para cada servicio de backend de balanceo de cargas de HTTP(S).

Antes de comenzar

Con el fin de habilitar IAP para GKE, necesitas lo siguiente:

• Un proyecto de la consola de Google Cloud con facturación habilitada
• Un grupo de una o más instancias de GKE entregadas mediante un balanceador de cargas de HTTPS. El balanceador de cargas debería crearse de forma automática cuando generas un objeto Ingress en un clúster de GKE
  • Aprende cómo crear un Ingress para HTTPS
• Un nombre de dominio registrado con la dirección de tu balanceador de cargas
• Un código de la app para verificar que todas las solicitudes tengan una identidad
  • Aprender cómo obtener la identidad del usuario

Habilita IAP

Si no has configurado la pantalla de consentimiento de OAuth para tu proyecto, podrás que se te solicite hacerlo. Para configurar tu pantalla de consentimiento de OAuth, consulta Configura tu pantalla de consentimiento de OAuth.

Configura el acceso de IAP

1. Ve a la página Identity-Aware Proxy.
   Ir a la página Identity-Aware Proxy
2. Selecciona el proyecto que deseas proteger con IAP.

3. Selecciona la casilla de verificación junto al recurso al que deseas otorgar acceso.

   Si no ves un recurso, asegúrate de que se haya creado y que el controlador de entrada de Compute Engine de BackendConfig está sincronizado.

   Para verificar que el servicio de backend esté disponible, ejecuta el siguiente comando: gcloud:

   gcloud compute backend-services list
4. En el panel de la derecha, haz clic en Agregar principal.
5. En el diálogo Agregar principales que aparece, ingresa las direcciones de correo electrónico de los grupos o Las personas que deberían tener la función Usuario de aplicación web protegida con IAP para el proyecto.

   Los siguientes tipos de principales pueden tener este rol:

   • Cuenta de Google: [e-mail]
   • Grupo de Google: [e-mail]
   • Cuenta de servicio: [e-mail]
   • Dominio de Google Workspace: example.com

   Asegúrate de agregar una Cuenta de Google a la que tengas acceso.

6. En la lista desplegable Funciones, selecciona Cloud IAP > Usuario de aplicación web protegida con IAP.
7. Haz clic en Guardar.

Configura BackendConfig

A fin de configurar BackendConfig para IAP, crea un secreto de Kubernetes y, luego, agrega un bloque iap a BackendConfig.

Crea un secreto de Kubernetes

BackendConfig usa un secreto de Kubernetes para unir el cliente OAuth que ya creaste. Los secretos de Kubernetes se administran como otros objetos de Kubernetes mediante la interfaz de línea de comandos (CLI) kubectl. Para crear un secreto, ejecuta el siguiente comando, en el que client_id_key y client_secret_key son las claves del archivo JSON que descargaste cuando creaste las credenciales de OAuth:

kubectl create secret generic my-secret --from-literal=client_id=client_id_key \
    --from-literal=client_secret=client_secret_key

El comando anterior muestra el resultado para confirmar cuando se crea correctamente el secreto:

secret "my-secret" created

Agrega un bloque iap a BackendConfig

A fin de configurar BackendConfig para IAP, debes especificar los valores enabled y secretName. Para especificar estos valores, asegúrate de tener el permiso compute.backendServices.update y agrega el bloque iap a BackendConfig. En este bloque, my-secret es el nombre del secreto de Kubernetes que creaste antes:

Nota: No puedes habilitar IAP y Cloud CDN en una BackendConfig. Si BackendConfig no tiene un bloque de IAP, se heredará cualquier configuración de IAP existente en el servicio de backend.

Para las versiones de GKE 1.16.8-gke.3 y posteriores, usa la versión de la API “cloud.google.com/v1”. Si usas una versión anterior de GKE, usa `cloud.google.com/v1beta1`.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: config-default
  namespace: my-namespace
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

También debes asociar puertos de servicio a tu BackendConfig para activar IAP. Una forma de establecer esta asociación es hacer que todos los puertos del servicio sean predeterminados para tu BackendConfig, lo que puedes hacer si agregas la siguiente anotación a tu recurso de servicio:

metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "config-default"}'

Para probar la configuración, ejecuta kubectl get event. Si ves el mensaje "no BackendConfig for service port exists", significa que asociaste correctamente un puerto de servicio a tu BackendConfig, pero el recurso de BackendConfig no se encontró. Este error puede ocurrir si no creaste el recurso BackendConfig, lo creaste en el espacio de nombres incorrecto o escribiste mal la referencia en la anotación del servicio.

Nota: IAP agrega el parámetro de consulta gcp-iap-mode=AUTHENTICATING al redireccionamiento. después de la autenticación de OAuth, así que asegúrate de comprobar el estado configuración de enrutamiento para garantizar que las solicitudes redirigidas vayan al servicio de backend correcto después de que un usuario se autentique con OAuth.

Si el secretName al que se hace referencia no existe o no está estructurado correctamente, aparecerá uno de los siguientes mensajes de error:

• BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found. Para resolver este error, asegúrate de haber creado el secreto de Kubernetes correctamente, como se describió en la sección anterior.
• BackendConfig default/config-default is not valid: secret "foo" missing client_secret data. Para resolver este error, asegúrate de haber creé las credenciales de OAuth correctamente. Además, asegúrate de haber hecho referencia a las claves client_id y client_secret correctas en el JSON que descargaste antes.

Cuando la marca enabled se establece en true y secretName se establece correctamente, IAP se configura para el recurso seleccionado.

Nota: Es posible que recibas el mensaje de advertencia “Agrega una regla de firewall” en el IAP de configuración para backends basados en grupos de extremos de red (NEG), aunque exista la regla de firewall correcta. La regla de firewall es informativa y se puede ignorar de forma segura.

Desactiva IAP

Para desactivar IAP, debes configurar enabled en false en BackendConfig. Si borras el bloque de IAP de BackendConfig, la configuración se mantendrá. Por ejemplo, si IAP está habilitado con secretName: my_secret y borras el bloque, IAP se seguirá activando con las credenciales de OAuth almacenadas en my_secret,

¿Qué sigue?

• Más información sobre cómo configurar Cloud CDN en GKE
• Más información sobre cómo configurar Cloud Armor para GKE
• Más información acerca del recurso de BackendConfig