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

Amir RawdatIngeniero de soluciones

Hemos escrito muchas veces sobre la importancia de proteger sus aplicaciones y API en el contexto actual de ataques de ransomware y ataques impulsados por bots. Además de mecanismos como un cortafuegos de aplicaciones web (WAF), autenticar las identidades de los usuarios y aplicar controles de autorización son medidas importantes para proteger sus aplicaciones empresariales.

La forma más directa de implementar la autenticación y la autorización es hacerlo en las propias aplicaciones. Aunque esto puede funcionar cuando la base de usuarios es pequeña y la aplicación no requiere actualizaciones frecuentes, enseguida se vuelve inviable a gran escala. Para empezar, cuando los usuarios tienen que recordar un nombre de cuenta y una contraseña diferentes para cada una de las numerosas aplicaciones, al intentar iniciar sesión suelen encontrarse con frustrantes mensajes de «nombre de usuario o contraseña incorrectos», lo que los lleva a recurrir a soluciones poco seguras, como contraseñas fáciles de adivinar del tipo «abc123». ¡Y todos hemos visto monitores rodeados de 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 sustituir todos esos nombres de usuario y contraseñas independientes por un único conjunto de credenciales. Los usuarios solo tienen que iniciar sesión una vez con un proveedor de identidad (IdP) para acceder a numerosas aplicaciones. Sin embargo, los desarrolladores deben seguir incluyendo código en sus aplicaciones para que interactúen con el sistema SSO, lo que puede resultar muy complicado, especialmente a medida que aumenta la complejidad de las aplicaciones.

A medida que las organizaciones crecen y necesitan satisfacer las exigencias de una base de usuarios en rápido aumento, resulta fundamental trasladar fuera 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. Un lugar idóneo para centralizar la autenticación y la autorización en Kubernetes es el controlador de Ingress, que puede examinar todo el tráfico que entra en el clúster y dirigirlo a los servicios adecuados. Esto libera a los desarrolladores de la carga de crear, mantener y replicar la lógica de autenticación, y les permite aprovechar fácilmente las tecnologías de SSO en la capa de entrada mediante la API nativa de Kubernetes.

En este blog, mostramos cómo implementar una solución de SSO completa con NGINX Ingress Controller basado en NGINX Plus actuando como parte intermediaria y compatible con el flujo de código de autorización de OIDC con Okta como proveedor de identidades (IdP) preconfigurado.

Nota: Esta funcionalidad no está disponible con NGINX Ingress Controller basado en NGINX Open Source.

Requisitos previos

Este blog presupone que tiene experiencia trabajando en entornos de Kubernetes. Además, necesita lo siguiente:

• Un entorno de Kubernetes – NGINX Ingress Controller es compatible tanto con Kubernetes estándar como con numerosas plataformas de Kubernetes, entre ellas Amazon Elastic Kubernetes (EKS), servidores físicos, Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher Kubernetes Engine y Red Hat OpenShift.
• NGINX Ingress Controller basado en NGINX Plus – Debe disponer de una licencia válida para la versión de NGINX Ingress Controller basada en NGINX Plus. Puede empezar hoy mismo con una licencia solicitando una prueba gratuita de 30 días. Para obtener más información, consulte nuestra documentación.
• Una cuenta de desarrollador de Okta – Para configurar Okta como proveedor de identidades (IdP), primero regístrese para obtener una cuenta de desarrollador. Como alternativa, descargue la interfaz de línea de comandos de Okta (CLI) y ejecute el comando okta register para crear una cuenta nueva. En el momento de redactar este documento, la CLI de Okta se encuentra en fase beta y no se recomienda su uso en entornos de producción.

Configuración previa del IdP

Los servicios en la nube deben saber dónde obtener y verificar las identidades de los usuarios, y es ahí donde resulta necesario un IdP. Un IdP gestiona y almacena las identidades digitales de forma segura e impide que los atacantes las roben para suplantar a los usuarios.

En esta sección, utilizamos la CLI de Okta para preconfigurar Okta como IdP y crear lo que Okta denomina una «integración de aplicaciones».

1. Ejecuta el comando okta login para autenticar la CLI de Okta con tu cuenta de desarrollador de Okta. Cuando se te solicite, introduce tu dominio de Okta y el token de API.

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

1. Crea la integración de la aplicación:

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

1. donde
   • --app-name define el nombre de la aplicación (en este caso, mywebapp)
   • --redirect-uri define el URI al que se redirigen los inicios de sesión (en este caso, ingress-controller-hostname/_codexch)
2. Especifique el tipo de aplicación cuando se le solicite, primero con 1 (que representa una aplicación web) y después con 5 (que representa un framework distinto de 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 Ingress NGINX

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

Definir un secreto de credenciales de cliente

Por motivos de seguridad, no se admite incluir directamente el secreto de cliente en el objeto de política OIDC. En su lugar, creamos un secreto de Kubernetes con datos que contienen el valor del secreto de cliente codificado en base64.

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

A continuación, aplica el archivo YAML que contiene el secreto (en este caso, client-secret.yaml):

$ kubectl apply –f client-secret.yaml

Obtener los endpoints de autenticación

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

Ejecuta el siguiente comando en tu equipo local para mostrar información sobre tus endpoints de Okta. Anota los valores de authorization_endpoint, token_endpoint y jwks_uri que aparecen en el resultado de ejemplo. 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 NGINX Ingress

La compatibilidad con la autenticación basada en OIDC se añadió en NGINX Ingress Controller 1.10.0. Para obtener más información, consulte Inicio de sesión único sencillo y robusto con OpenID Connect y NGINX Ingress Controller en nuestro blog.

La implementación de la autenticación OIDC de NGINX Ingress Controller utiliza un objeto Policy, un recurso personalizado de Kubernetes que define una política OIDC en NGINX Ingress Controller.

1. Introduzca 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

1. Aplique la política (definida aquí en «oidc.yaml»):

$ kubectl apply -f oidc.yaml

1. (Opcional) Compruebe la validez de la política:

$ kubectl get policy 

NAME          STATE   AGE
oidc-policy   Valid   2m

Definición del objeto VirtualServer

VirtualServer y VirtualServerRoute son recursos de NGINX Ingress que proporcionan las reglas para enrutar el tráfico entrante a las aplicaciones de backend del clúster de Kubernetes. Para que una política OIDC surta efecto, debe hacerse referencia a ella en un recurso VirtualServer o VirtualServerRoute.

1. Haga referencia a una política OIDC bajo el prefijo de ruta / para que los usuarios que soliciten rutas que coincidan con el prefijo sean autenticados antes de que la solicitud se redirija 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

1. Aplique el recurso VirtualServer (definido aquí en «app-virtual-server.yaml»):

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

1. (Opcional). Verifique la validez del recurso:

$ kubectl get vs

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

Prueba del entorno

Para comprobar que la integración de OIDC con Okta funciona correctamente, introduzca el nombre de host del controlador de entrada NGINX en la barra de direcciones de su navegador. Se le redirigirá al portal de inicio de sesión de Okta, donde podrá introducir las credenciales de su cuenta de desarrollador de Okta para acceder a la aplicación de backend.

Una vez que te hayas autenticado correctamente, tendrás acceso al servicio ascendente app-server-payload.

Añadir usuarios a la aplicación

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

Creación de integraciones de SSO para varias aplicaciones

Hemos externalizado el proceso de autenticación de una aplicación configurando el SSO con Okta como IdP y NGINX Ingress Controller como parte intermediaria. En la práctica, probablemente quiera permitir que los usuarios accedan a varias aplicaciones con un único conjunto de credenciales. También puede que quiera disponer de flexibilidad para determinar a qué aplicaciones puede acceder cada usuario. Para ello, repita las instrucciones de las secciones anteriores:

• Preconfiguración del IdP para integrar otras aplicaciones con Okta
• Definición de la política OIDC de NGINX Ingress 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 de NGINX Ingress Controller. NGINX Ingress Controller enruta las solicitudes a la aplicación de Marketing o a la de Ingeniería en función del subdominio. Para conceder acceso a un usuario, en la pestaña Asignaciones de la interfaz gráfica de Okta, asocie al usuario con cada aplicación correspondiente. A continuación, Okta concede al usuario autenticado una cookie de sesión de corta duración para acceder a esas aplicaciones.

Conclusión

Al implementar el SSO basado en OIDC en Kubernetes utilizando NGINX Ingress Controller como parte intermediaria y Okta como IdP, descarga a sus desarrolladores de las tareas de autenticación y autorización, lo que les permite centrarse en optimizar la lógica de negocio de sus aplicaciones. Para empezar a utilizar NGINX Ingress Controller basado en NGINX Plus, solicite una prueba gratuita de 30 días hoy mismo o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Amir RawdatIngeniero de soluciones

Más artículos de Amir Rawdat