Implementación de la autenticación OpenID Connect para Kubernetes con Okta y el controlador de ingreso NGINX

Hemos escrito muchas veces sobre lo importante que es proteger sus aplicaciones y API en el clima actual de ransomware y ataques impulsados por bots. Junto con mecanismos como el firewall de aplicación web (WAF), la autenticación de las identidades de los usuarios y la aplicación de controles de autorización son formas importantes de proteger sus aplicaciones comerciales.

La forma más directa de implementar la autenticación y la autorización es en las propias aplicaciones . Si bien esto puede funcionar cuando su base de usuarios es pequeña y su aplicación no requiere actualizaciones frecuentes, rápidamente se vuelve insostenible a gran escala. Por un lado, cuando los usuarios tienen que recordar un nombre de cuenta y una contraseña diferentes para cada una de muchas aplicaciones, a menudo se encuentran con mensajes frustrantes de "nombre de usuario o contraseña incorrectos" cuando intentan iniciar sesión, lo que los lleva a recurrir a soluciones inseguras como contraseñas "abc123" fáciles de adivinar. ¡Y todos hemos visto monitores adornados con un halo de notas Post-it® con recordatorios de contraseñas!

Las tecnologías de inicio de sesión único (SSO) pueden resolver parcialmente estos problemas al eliminar todos esos nombres de usuario y contraseñas separados en favor de un conjunto de credenciales. Los usuarios inician sesión solo una vez con un proveedor de identidad (IdP) para obtener acceso a muchas aplicaciones. Pero los desarrolladores aún deben incluir código en sus aplicaciones para interactuar con el sistema SSO, lo que puede ser un gran desafío, especialmente a medida que las aplicaciones crecen en complejidad.

A medida que las organizaciones escalan y necesitan satisfacer los requisitos de una base de usuarios en aumento, se vuelve fundamental descargar de la capa de aplicación los requisitos que no son específicos de la funcionalidad de una aplicación (como la autenticación y la autorización). Una ubicación ideal para la autenticación y autorización centralizadas en Kubernetes es el controlador de ingreso , que puede examinar todo el tráfico que ingresa al clúster y enrutarlo a los servicios adecuados. Esto libera a los desarrolladores de la carga de crear, mantener y replicar la lógica de autenticación y pueden aprovechar fácilmente las tecnologías SSO en la capa de ingreso utilizando la API nativa de Kubernetes.

En este blog, mostramos cómo implementar una solución SSO completa con el controlador de ingreso NGINX basado en NGINX Plus que opera como parte retransmisora y respalda el flujo de código de autorización OIDC con Okta como proveedor de identidad (IdP) preconfigurado.

Nota:  Esta función no está disponible con el controlador de ingreso NGINX basado en código abierto.

Requisitos previos

Este blog asume que tienes experiencia operando en entornos Kubernetes. Además, necesitarás lo siguiente:

• Un entorno de Kubernetes : NGINX Ingress Controller es compatible con Kubernetes estándar, así como con numerosas plataformas de Kubernetes, incluidas Amazon Elastic Kubernetes (EKS), bare metal, Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher Kubernetes Engine y Red Hat OpenShift.
• Controlador de ingreso NGINX basado en NGINX Plus : debe tener una licencia válida para la versión basada en NGINX Plus del controlador de ingreso NGINX. Puede comenzar a obtener una licencia hoy mismo solicitando una prueba gratuita de 30 días . Para obtener información adicional, consulte nuestra documentación .
• Una cuenta de desarrollador de Okta : para configurar Okta como su IdP, comience registrándose para obtener una cuenta de desarrollador. Como alternativa, descargue la interfaz de línea de comandos (CLI) de Okta y ejecute el comando okta register para registrar una nueva cuenta. Al momento de escribir este artículo, la CLI de Okta está en versión beta y no se recomienda para su uso en producción.

Preconfiguración del IdP

Los servicios en la nube deben saber dónde recuperar y verificar las identidades de los usuarios, y ahí es donde se hace necesario un IdP. Un IdP administra y almacena identidades digitales de forma segura y garantiza que los atacantes no puedan robar identidades para hacerse pasar por usuarios.

En esta sección usamos la CLI de Okta para preconfigurar Okta como IdP, creando lo que Okta llama una integración de aplicaciones .

1. Ejecute el comando de inicio de sesión de Okta para autenticar la CLI de Okta con su cuenta de desarrollador de Okta. Ingrese su dominio Okta y el token API en las indicaciones.

   $ okta login Okta Org URL: https://your-okta-domain
   Okta API token: your-api-token
   

2. Crear la integración de la aplicación:

   $ okta apps create --app-name=mywebapp --redirect-uri=http[s]://ingress-controller-hostname/_codexch
   

   dónde

   • --app-name define el nombre de la aplicación (aquí, mywebapp )
   • --redirect-uri define la URI a la que se redirigen los inicios de sesión (aquí, ingress-controller-hostname /_codexch )

3. Especifique el tipo de aplicación en respuesta a las indicaciones, primero con1 (que representa una aplicación web) y luego5 (que representa un marco distinto a los enumerados).

   Type of Application
   (The Okta CLI only supports a subset of application types and properties):
   > 1: Web
   > 2: Single Page App
   > 3: Native App (mobile)
   > 4: Service (Machine-to-Machine)
   Enter your choice [Web]: 1
   Type of Application
   > 1: Okta Spring Boot Starter
   > 2: Spring Boot
   > 3: JHipster
   > 4: Quarkus
   > 5: Other
   Enter your choice [Other]: 5
   Configuring a new OIDC Application, almost done:
   Created OIDC application, client-id: 0oa1mi...OrfQAg5d7
   

Configuración del controlador de ingreso NGINX

Configure la versión basada en NGINX Plus de NGINX Ingress Controller como la parte de retransmisión que autentica a los usuarios.

Definición de un secreto de credencial de cliente

Por razones de seguridad, no se admite la codificación rígida del secreto del cliente en el objeto de política OIDC. En su lugar, creamos un secreto de Kubernetes con datos que contienen el valor codificado en base64 del secreto del cliente.

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: base64-encoded-value-of-client-secret 

Luego aplique el archivo YAML que contiene el secreto (aquí, client-secret.yaml ):

$ kubectl apply –f client-secret.yaml

Obtención de los puntos finales de autenticación

Utilice la API de OAuth 2.0 y OpenID Connect para obtener información sobre los puntos finales que Okta expone en sus servidores de autorización.

Ejecute el siguiente comando en su máquina local para generar información sobre sus puntos finales de Okta. Tenga en cuenta los valores de authorization_endpoint , token_endpoint y jwks_uri como se muestra en la salida de muestra. Los utilizarás en la siguiente sección .

$ curl -i https://your-okta-domain/.well-known/openid-configuration
{
    "authorization_endpoint": "https://your-okta-domain/oauth2/v1/authorize",
    ...
    "jwks_uri": "https://your-okta-domain/oauth2/v1/keys",
    ...
    "token_endpoint": "https://your-okta-domain/oauth2/v1/token",
 ...
 }

Definición de la política OIDC de ingreso de NGINX

Se agregó soporte para la autenticación basada en OIDC en NGINX Ingress Controller 1.10.0. Para obtener más detalles, lea Inicio de sesión único fácil y robusto con OpenID Connect y controlador de ingreso NGINX en nuestro blog.

La implementación de la autenticación OIDC del controlador de ingreso NGINX utiliza un objeto de política , un recurso personalizado de Kubernetes que define una política OIDC en el controlador de ingreso NGINX.

1. Inserte la información obtenida en la sección anterior en los campos authEndpoint , tokenEndpoint y jwksURI del objeto Policy .

   apiVersion: k8s.nginx.org/v1
   kind: Policy
   metadata:
     name: oidc-policy
   spec:
     oidc:
       clientID: client-id
       clientSecret: oidc-secret
       authEndpoint: https://your-okta-domain/oauth2/v1/authorize
       tokenEndpoint: https://your-okta-domain/oauth2/v1/token
       jwksURI: https://your-okta-domain/oauth2/v1/keys
   

2. Aplicar la política (aquí definida en oidc.yaml ):

   $ kubectl apply -f oidc.yaml
   

3. (Opcional) Verifique la validez de la póliza:

   $ kubectl get policy 
   
   NAME          STATE   AGE
   oidc-policy   Valid   2m
   

Definición del objeto VirtualServer

VirtualServer y VirtualServerRoute son recursos de ingreso de NGINX que proporcionan las reglas para enrutar el tráfico entrante a las aplicaciones de backend en el clúster de Kubernetes. Para que una política OIDC tenga efecto, se la debe referenciar en un recurso VirtualServer o VirtualServerRoute.

1. Haga referencia a una política OIDC bajo el prefijo / path para que los usuarios que solicitan rutas que coinciden con el prefijo se autentiquen antes de que la solicitud se envíe por proxy al servicio app-server-payload .

   apiVersion: k8s.nginx.org/v1
   kind: VirtualServer
   metadata:
     name: app-ingress
   spec:
     host: unit-demo.linkpc.net
     upstreams:
     - name: app-server-payload
       service: app-server-svc
       port: 80
     routes:
     - path: /
       policies:
       - name: oidc-policy
       action:
         proxy: 
           upstream: app-server-payload
   

2. Aplicar el recurso VirtualServer (aquí definido en app-virtual-server.yaml ):

   $ kubectl apply -f app-virtual-server.yaml
   

3. (Opcional.) Verificar la validez del recurso:

   $ kubectl get vs
   
   NAME          STATE   HOST                   IP    PORTS   AGE
   app-ingress   Valid   unit-demo.linkpc.net                 2m
   

Probando el entorno

Para probar que la integración de OIDC Okta funciona correctamente, ingrese el nombre de host del controlador de ingreso NGINX en la barra de direcciones de su navegador. Serás redirigido al portal de inicio de sesión de Okta, donde podrás ingresar las credenciales de tu cuenta de desarrollador de Okta para obtener acceso a la aplicación backend.

Una vez autenticado exitosamente, obtendrá acceso al servicio ascendente de carga útil del servidor de aplicaciones .

Agregar usuarios a la aplicación

En la mayoría de los casos, varios usuarios de su organización necesitan acceder a sus aplicaciones. Agregue cada usuario en la página Personas en la categoría Directorio en la consola de administración de Okta.

Creación de integraciones SSO para múltiples aplicaciones

Hemos descargado el proceso de autenticación de una aplicación al configurar SSO con Okta como IdP y NGINX Ingress Controller como parte retransmisora. En la práctica, probablemente desee permitir que los usuarios accedan a muchas aplicaciones utilizando un único conjunto de credenciales. Es posible que también desee tener la flexibilidad de variar a qué aplicaciones puede acceder un usuario. Puedes hacer esto repitiendo las instrucciones de las secciones anteriores:

• Preconfiguración del IdP para integrar otras aplicaciones con Okta
• Definición de la política OIDC de ingreso de NGINX para definir otras políticas OIDC
• Definición del objeto VirtualServer para hacer referencia a políticas adicionales

En el ejemplo que se muestra en el siguiente diagrama, hay dos subdominios, unit-demo.marketing.net y unit-demo.engineering.net , que se resuelven en la dirección IP externa del controlador de ingreso NGINX. El controlador de ingreso NGINX dirige las solicitudes a la aplicación de marketing o a la aplicación de ingeniería según el subdominio. Para otorgar acceso a un usuario, en la pestaña Asignaciones de la GUI de Okta, asocie el usuario con cada aplicación adecuada. Luego, Okta otorga al usuario autenticado una cookie de sesión de corta duración para acceder a esas aplicaciones.

CONCLUSIÓN

Al implementar SSO basado en OIDC en Kubernetes usando NGINX Ingress Controller como parte de retransmisión y Okta como IdP, descarga la autenticación y autorización de sus desarrolladores, liberándolos para que se concentren en optimizar la lógica comercial en sus aplicaciones. Para comenzar a utilizar el controlador de ingreso NGINX basado en NGINX Plus , solicite hoy una prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .