[Editor– Esta publicación es un extracto de nuestro completo libro electrónico, Gestión del tráfico de Kubernetes con F5 NGINX: guía práctica. Descárguelo gratis hoy mismo.]
A medida que las organizaciones crecen, los flujos de trabajo de desarrollo y operaciones en Kubernetes se vuelven más complejos. Por lo general, resulta más rentable —y puede ser más seguro— que los equipos compartan clústeres y recursos de Kubernetes, en lugar de que cada equipo tenga su propio clúster. Sin embargo, sus implementaciones pueden sufrir daños graves si los equipos no comparten esos recursos de forma segura o si los hackers aprovechan las vulnerabilidades de sus configuraciones.
Las prácticas de multitenencia y el aislamiento de espacios de nombres a nivel de red y de recursos ayudan a los equipos a compartir los recursos de Kubernetes de forma segura. También puede reducir considerablemente el alcance de las brechas aislando las aplicaciones por inquilino. Este método ayuda a mejorar la resiliencia, ya que solo pueden verse comprometidas determinadas partes de las aplicaciones pertenecientes a equipos específicos, mientras que los sistemas que proporcionan otras funcionalidades permanecen intactos.
NGINX Ingress Controller admite varios modelos multiinquilino, pero observamos dos patrones principales. El patrón de proveedor de servicios de infraestructura suele incluir varias implementaciones de NGINX Ingress Controller con aislamiento físico, mientras que el patrón empresarial suele utilizar una implementación compartida de NGINX Ingress Controller con aislamiento de espacios de nombres. En esta sección analizamos en profundidad el patrón empresarial; para obtener información sobre cómo ejecutar varios NGINX Ingress Controllers, consulte nuestra documentación.
Delegación con NGINX Ingress Controller
NGINX Ingress Controller admite tanto el recurso Ingress estándar de Kubernetes como los recursos Ingress personalizados de NGINX, que permiten una gestión del tráfico más sofisticada y delegar el control de la configuración en varios equipos. Los recursos personalizados son VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer y Policy.
Con NGINX Ingress Controller, los administradores de clústeres utilizan recursos VirtualServer para aprovisionar reglas de dominio (nombre de host) de Ingress que dirigen el tráfico externo a las aplicaciones de backend, y recursos VirtualServerRoute para delegar la gestión de URL específicas en los propietarios de las aplicaciones y los equipos de DevOps.
Hay dos modelos entre los que puede elegir al implementar la multitenencia en su clúster de Kubernetes: autoservicio completo y autoservicio restringido.
Implementación del autoservicio completo
En un modelo de autoservicio completo, los administradores no intervienen en los cambios cotidianos de la configuración de NGINX Ingress Controller. Solo son responsables de implementar NGINX Ingress Controller y el servicio de Kubernetes que expone la implementación al exterior. A continuación, los desarrolladores implementan aplicaciones en un espacio de nombres asignado sin la intervención del administrador. Los desarrolladores son responsables de gestionar los secretos TLS, definir la configuración del equilibrio de carga para los nombres de dominio y exponer sus aplicaciones mediante la creación de recursos VirtualServer o recursos Ingress estándar.
Para ilustrar este modelo, replicamos la aplicación de ejemplo bookinfo (creada originalmente por Istio) con dos subdominios, a.bookinfo.com y b.bookinfo.com, como se muestra en el siguiente diagrama. Una vez que el administrador instala y despliega NGINX Ingress Controller en el espacio de nombres nginx-ingress (resaltado en verde), los equipos DevA (rosa) y DevB (morado) crean sus propios recursos VirtualServer y despliegan aplicaciones aisladas en sus respectivos espacios de nombres (A y B, respectivamente).
Los equipos DevA y DevB configuran reglas de Ingress para sus dominios a fin de dirigir las conexiones externas a sus aplicaciones.
El equipo DevA aplica el siguiente objeto de recurso VirtualServer para exponer aplicaciones del dominio a.bookinfo.com en el espacio de nombres A.
Cargando ejemplo de código…
Del mismo modo, el equipo DevB aplica el siguiente recurso VirtualServer para exponer aplicaciones del dominio b.bookinfo.com en el espacio de nombres B.
Cargando ejemplo de código…
Implementación del autoservicio restringido
En un modelo de autoservicio restringido, los administradores configuran los recursos VirtualServer para dirigir el tráfico que entra en el clúster al espacio de nombres correspondiente, pero delegan la configuración de las aplicaciones de los espacios de nombres en los equipos de desarrollo responsables. Cada equipo es responsable únicamente de la subruta de su aplicación, tal como se instancia en el recurso VirtualServer, y utiliza recursos VirtualServerRoute para definir reglas de tráfico y exponer las subrutas de la aplicación dentro de su espacio de nombres.
Como se muestra en el diagrama, el administrador del clúster instala e implementa NGINX Ingress Controller en el espacio de nombres nginx-ingress (resaltado en verde) y define un recurso VirtualServer que establece reglas basadas en rutas que hacen referencia a definiciones de recursos VirtualServerRoute.
Esta definición de recurso VirtualServer establece dos reglas basadas en rutas que hacen referencia a definiciones de recursos VirtualServerRoute para dos subrutas, /productpage-A y /productpage-B.
Cargando ejemplo de código…
Los equipos de desarrollo responsables de las aplicaciones de los espacios de nombres A y B definen a continuación recursos VirtualServerRoute para exponer las subrutas de las aplicaciones dentro de sus espacios de nombres. Los equipos están aislados por espacio de nombres y solo pueden desplegar las subrutas de aplicaciones establecidas por los recursos VirtualServer aprovisionados por el administrador:
- El equipo DevA (en rosa en el diagrama) aplica el siguiente recurso VirtualServerRoute para exponer la regla de subruta de la aplicación establecida por el administrador para
/productpage-A.Cargando ejemplo de código…
- El equipo DevB (morado) aplica el siguiente recurso VirtualServerRoute para exponer la regla de subruta de la aplicación configurada por el administrador para
/productpage-B.Cargando ejemplo de código…
Para obtener más información sobre las funcionalidades que puede configurar en los recursos VirtualServer y VirtualServerRoute, consulte la documentación de NGINX Ingress Controller.
Nota: Puede utilizar tipos de Ingress combinables para configurar el enrutamiento entre espacios de nombres, pero, en un modelo restringido de delegación de autoservicio, este enfoque presenta tres desventajas con respecto a los recursos VirtualServer y VirtualServerRoute:
- Es menos seguro.
- A medida que tu despliegue de Kubernetes crece y se vuelve más grande y complejo, aumenta el riesgo de que se produzcan modificaciones accidentales, ya que los tipos de Ingress combinables no impiden que los desarrolladores establezcan reglas de Ingress para nombres de host dentro de su espacio de nombres.
- A diferencia de los recursos VirtualServer y VirtualServerRoute, los tipos de Ingress combinables no permiten que el recurso Ingress principal («maestro») controle las rutas de los recursos Ingress «subordinados».
Aprovechamiento del RBAC de Kubernetes en un modelo de autoservicio restringido
Puede utilizar el control de acceso basado en roles (RBAC) de Kubernetes para regular el acceso de un usuario a los espacios de nombres y a los recursos de NGINX Ingress en función de los roles que tenga asignados.
Por ejemplo, en un modelo de autoservicio restringido, solo se puede permitir de forma segura que los administradores con privilegios especiales accedan a los recursos de VirtualServer, ya que estos recursos definen el punto de entrada al clúster de Kubernetes y su uso indebido puede provocar interrupciones en todo el sistema.
Los desarrolladores utilizan recursos VirtualServerRoute para configurar reglas de Ingress para las rutas de las aplicaciones que gestionan, por lo que los administradores establecen políticas de RBAC que permiten a los desarrolladores crear únicamente esos recursos. Incluso pueden restringir ese permiso a espacios de nombres específicos si necesitan limitar aún más el acceso de los desarrolladores.
En un modelo de autoservicio completo, se puede conceder de forma segura a los desarrolladores acceso a los recursos VirtualServer, aunque el administrador también puede restringir ese permiso a espacios de nombres específicos.
Para obtener más información sobre la autorización RBAC, consulte la documentación de Kubernetes.
Añadir políticas
Los recursos Policy de NGINX son otra herramienta que permite a los equipos distribuidos configurar Kubernetes en implementaciones multiinquilino. Los recursos Policy habilitan funcionalidades como la autenticación mediante OAuth y OpenID Connect (OIDC), la limitación de solicitudes y el firewall de aplicaciones web (WAF). Para que surtan efecto en la configuración de Ingress, los recursos Policy deben estar referenciados en los recursos VirtualServer y VirtualServerRoute.
Por ejemplo, un equipo encargado de la gestión de identidades en un clúster puede definir políticas de tipo JSON Web Token (JWT) u OIDC como la siguiente, que utiliza Okta como proveedor de identidades OIDC (IdP).
Cargando ejemplo de código…
Los equipos de NetOps y DevOps pueden usar recursos VirtualServer o VirtualServerRoute para hacer referencia a esas políticas, como se muestra en este ejemplo.
Cargando ejemplo de código…
En conjunto, los recursos Policy, VirtualServer y VirtualServerRoute de NGINX permiten implementar arquitecturas de configuración distribuida, en las que los administradores pueden delegar fácilmente la configuración en otros equipos. Los equipos pueden combinar módulos de distintos espacios de nombres y configurar NGINX Ingress Controller para casos de uso avanzados de forma segura, escalable y fácil de gestionar.
Para obtener más información sobre los recursos Policy, consulte la documentación de NGINX Ingress Controller.
Este artículo es un extracto de nuestro completo libro electrónico, «Gestión del tráfico de Kubernetes con NGINX: guía práctica». Descárguelo gratis hoy mismo.
Pruebe usted mismo NGINX Ingress Controller basado en NGINX Plus con una prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.