BLOG | NGINX

Habilitación de la multitenencia y el aislamiento de espacios de nombres en Kubernetes con NGINX

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Amir Rawdat
Amir Rawdat
Publicado el 14 de junio de 2022

[ Editor : Esta publicación es un extracto de nuestro completo libro electrónico, Gestión del tráfico de Kubernetes con F5 NGINX: Una guía práctica . Descárgalo gratis hoy .]

A medida que las organizaciones escalan, los flujos de trabajo de desarrollo y operativos en Kubernetes se vuelven más complejos. Generalmente es 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. Pero sus implementaciones pueden sufrir daños críticos si los equipos no comparten esos recursos de forma segura o si los piratas informáticos explotan sus configuraciones.

Las prácticas de múltiples inquilinos y el aislamiento del espacio de nombres a nivel de red y recursos ayudan a los equipos a compartir recursos de Kubernetes de forma segura. También puede reducir significativamente la magnitud de las infracciones al aislar las aplicações por inquilino. Este método ayuda a aumentar la resiliencia porque solo se pueden comprometer subsecciones de aplicações propiedad de equipos específicos, mientras que los sistemas que proporcionan otras funcionalidades permanecen intactos.

El controlador de ingreso NGINX admite múltiples modelos de múltiples inquilinos, pero vemos dos patrones principales. El patrón de proveedor de servicios de infraestructura generalmente incluye múltiples implementaciones de NGINX Ingress Controller con aislamiento físico, mientras que el patrón empresarial generalmente utiliza una implementación de NGINX Ingress Controller compartida con aislamiento de espacio de nombres. En esta sección exploramos el patrón empresarial en profundidad; para obtener información sobre cómo ejecutar múltiples controladores de ingreso NGINX, consulte nuestra documentación .

Delegación con el controlador de ingreso NGINX

NGINX Ingress Controller admite tanto el recurso Ingress de Kubernetes estándar como los recursos Ingress de NGINX personalizados, lo que permite una gestión del tráfico más sofisticada y la delegación del control sobre la configuración a varios equipos. Los recursos personalizados son VirtualServer, VirtualServerRoute , GlobalConfiguration , TransportServer y Policy .

Con NGINX Ingress Controller, los administradores de clúster utilizan recursos de VirtualServer para aprovisionar reglas de dominio de Ingress (nombre de host) que enrutan el tráfico externo a las aplicações backend, y recursos de VirtualServerRoute para delegar la administración de URL específicas a los propietarios de aplicação y equipos de DevOps.

Hay dos modelos que puede elegir al implementar la multitenencia en su clúster de Kubernetes: autoservicio completo y autoservicio restringido .

Implementación de autoservicio completo

En un modelo de autoservicio completo, los administradores no participan en los cambios diarios en la configuración del controlador de ingreso NGINX. Son responsables únicamente de implementar el controlador de ingreso NGINX y el servicio Kubernetes que expone la implementación externamente. Luego, los desarrolladores implementan aplicações dentro de un espacio de nombres asignado sin involucrar al administrador. Los desarrolladores son responsables de administrar los secretos TLS, definir la configuración de equilibrio de carga para los nombres de dominio y exponer sus aplicações mediante la creación de servidores virtuales o recursos Ingress estándar.

Para ilustrar este modelo, replicamos la aplicação de muestra 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 e implementa NGINX Ingress Controller en el espacio de nombres nginx-ingress (resaltado en verde), los equipos DevA (rosa) y DevB (violeta) crean sus propios recursos de VirtualServer e implementan aplicações aisladas dentro de sus espacios de nombres ( A y B respectivamente).

Los equipos DevA y DevB establecen reglas de ingreso para sus dominios para enrutar conexiones externas a sus aplicações.

El equipo DevA aplica el siguiente objeto de recurso VirtualServer para exponer aplicações para el dominio a.bookinfo.com en el espacio de nombres A.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: bookinfo
namespace: A
spec:
host: a.bookinfo.com
upstreams:
- name: productpageA
service: productpageA
port: 9080
routes:
- path: /
action:
pass: productpageA
view raw full-self-service-vs-a.yaml hosted with ❤ by GitHub

De manera similar, el equipo DevB aplica el siguiente recurso VirtualServer para exponer aplicações para el dominio b.bookinfo.com en el espacio de nombres B.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: bookinfo
namespace: B
spec:
host: b.bookinfo.com
upstreams:
- name: productpageB
service: productpageB
port: 9080
routes:
- path: /
action:
pass: productpageB
view raw full-self-service-vs-b.yaml hosted with ❤ by GitHub

Implementación de autoservicio restringido

En un modelo de autoservicio restringido, los administradores configuran los recursos de VirtualServer para enrutar el tráfico que ingresa al clúster al espacio de nombres apropiado, pero delegan la configuración de las aplicações en los espacios de nombres a los equipos de desarrollo responsables. Cada uno de estos equipos es responsable únicamente de su subruta de aplicação tal como está instanciada en el recurso VirtualServer y utiliza los recursos VirtualServerRoute para definir reglas de tráfico y exponer subrutas de aplicação dentro de su espacio de nombres.

Diagrama de topología de autoservicio restringido en un clúster de Kubernetes, donde los administradores configuran los recursos de VirtualServer, pero delegan la configuración de las aplicações a los equipos de desarrollo, que utilizan los recursos de VirtualServerRoute para definir reglas de tráfico y exponer subrutas de aplicação

Como se ilustra 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 las definiciones de recursos VirtualServerRoute.

Esta definición de recurso VirtualServer establece dos reglas basadas en rutas que hacen referencia a las definiciones de recursos VirtualServerRoute para dos subrutas, /productpage-A y /productpage-B .

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: example
spec:
host: bookinfo.example.com
routes:
- path: /productpage-A
route: A/ingress
- path: /productpage-B
route: B/ingress
view raw restricted-self-service-vs.yaml hosted with ❤ by GitHub

Luego, los equipos de desarrolladores responsables de las aplicaciones en los espacios de nombres A y B definen recursos VirtualServerRoute para exponer subrutas de aplicação dentro de sus espacios de nombres. Los equipos están aislados por espacio de nombres y restringidos a implementar subrutas de aplicação establecidas por recursos de VirtualServer provistos por el administrador:

  • El equipo DevA (rosa en el diagrama) aplica el siguiente recurso VirtualServerRoute para exponer la regla de subruta de aplicação establecida por el administrador para /productpage-A .

    apiVersion: k8s.nginx.org/v1
    kind: VirtualServerRoute
    metadata:
    name: ingress
    namespace: A
    spec:
    host: bookinfo.example.com
    upstreams:
    - name: productpageA
    service: productpageA-svc
    port: 9080
    subroutes:
    - path: /productpage-A
    action:
    pass: productpageA
    view raw restricted-self-service-vsr-a.yaml hosted with ❤ by GitHub

  • El equipo DevB (violeta) aplica el siguiente recurso VirtualServerRoute para exponer la regla de subruta de aplicação establecida por el administrador para /productpage-B .

    apiVersion: k8s.nginx.org/v1
    kind: VirtualServerRoute
    metadata:
    name: ingress
    namespace: B
    spec:
    host: bookinfo.example.com
    upstreams:
    - name: productpageB
    service: productpageB-svc
    port: 9080
    subroutes:
    - path: /productpage-B
    action:
    pass: productpageB
    view raw restricted-self-service-vsr-b.yaml hosted with ❤ by GitHub

Para obtener más información sobre las funciones que puede configurar en los recursos VirtualServer y VirtualServerRoute, consulte la documentación del controlador de ingreso NGINX .

Nota:  Puede usar tipos de Ingress fusionables para configurar el enrutamiento entre espacios de nombres, pero en un modelo de delegación de autoservicio restringido, ese enfoque tiene tres desventajas en comparación con los recursos VirtualServer y VirtualServerRoute:

  1. Es menos seguro.
  2. A medida que su implementación de Kubernetes crece y se vuelve más compleja, se vuelve cada vez más propensa a modificaciones accidentales, porque los tipos de Ingress fusionables no impiden que los desarrolladores establezcan reglas de Ingress para nombres de host dentro de su espacio de nombres.
  3. A diferencia de los recursos VirtualServer y VirtualServerRoute, los tipos de Ingress fusionables no permiten que el recurso de Ingress principal (“maestro”) controle las rutas de los recursos de Ingress “secundarios”.

Aprovechamiento de Kubernetes RBAC 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 asignados al usuario.

Por ejemplo, en un modelo de autoservicio restringido, solo los administradores con privilegios especiales pueden acceder de forma segura a los recursos de VirtualServer; debido a que esos recursos definen el punto de entrada al clúster de Kubernetes, el uso indebido puede provocar interrupciones en todo el sistema.

Los desarrolladores utilizan los recursos de VirtualServerRoute para configurar las reglas de ingreso para las rutas de aplicação que poseen, por lo que los administradores establecen políticas RBAC que permiten a los desarrolladores crear solo esos recursos. Incluso pueden restringir ese permiso a espacios de nombres específicos si necesitan regular aún más el acceso de los desarrolladores.

En un modelo de autoservicio completo, se puede otorgar a los desarrolladores acceso seguro a los recursos de VirtualServer, pero nuevamente el administrador 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 .

Agregar políticas

Los recursos de políticas de NGINX son otra herramienta que permite a los equipos distribuidos configurar Kubernetes en implementaciones de múltiples inquilinos. Los recursos de políticas habilitan funcionalidades como autenticación mediante OAuth y OpenID Connect (OIDC), limitación de velocidad y firewall de aplicação web (WAF). Los recursos de políticas se referencian en los recursos VirtualServer y VirtualServerRoute para que surtan efecto en la configuración de Ingress.

Por ejemplo, un equipo a cargo de la gestión de identidad en un clúster puede definir políticas JSON Web Token (JWT) o OIDC como la siguiente, que utiliza Okta como proveedor de identidad OIDC (IdP).

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
name: okta-oidc-policy
spec:
oidc:
clientID: <client_id>
clientSecret: okta-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
view raw oidc-policy.yaml hosted with ❤ by GitHub

Los equipos de NetOps y DevOps pueden usar recursos VirtualServer o VirtualServerRoute para hacer referencia a esas políticas, como en este ejemplo.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: bookinfo-vs
spec:
host: bookinfo.example.com
tls:
secret: bookinfo-secret
upstreams:
- name: backend
service: productpage
port: 9080
routes:
- path: /
policies:
- name: okta-oidc-policy
action:
pass: backend
view raw oidc-vs.yaml hosted with ❤ by GitHub

Juntos, los recursos NGINX Policy, VirtualServer y VirtualServerRoute permiten arquitecturas de configuración distribuidas, donde los administradores pueden delegar fácilmente la configuración a otros equipos. Los equipos pueden ensamblar módulos en distintos espacios de nombres y configurar el controlador de ingreso NGINX con casos de uso sofisticados de manera segura, escalable y manejable.

Diagrama de un clúster de Kubernetes multiinquilino, donde el administrador delega la configuración de funciones específicas a varios equipos

Para obtener más información sobre los recursos de políticas, consulte la documentación del controlador de ingreso NGINX .

Esta publicación es un extracto de nuestro completo libro electrónico, Gestión del tráfico de Kubernetes con NGINX: Una guía práctica . Descárgalo gratis hoy .

Pruebe usted mismo el controlador de ingreso NGINX basado en NGINX Plus hoy mismo con una prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.