Gestión más segura de la configuración con NGINX Controller

Brian EhlertDirector de Gestión de Producto

Al hablar con nuestros clientes durante el último año, hemos observado algunos temas recurrentes que los llevan a evaluar productos de orquestación como NGINX Controller:

• Complejidad – Gestionar, mantener, validar y aplicar grandes conjuntos de objetos de configuración individuales procedentes de distintas fuentes no es fácil.
• Fragilidad – La ampliación puede producirse rápidamente, a menudo como respuesta a un acontecimiento. A veces es estratégica, pero, como suele ocurrir en todos los departamentos de operaciones, también puede ser espontánea y no planificada.
• Seguridad – Evitar errores y detectar problemas antes del despliegue en producción son pilares fundamentales de la metodología ágil. También ayudan a mitigar la complejidad y la fragilidad.

Estas no son preocupaciones a las que los clientes suelan enfrentarse al implementar una aplicación por primera vez. Más bien, surgen con el paso del tiempo, cuando la aplicación tiene éxito y necesita escalar. Consideramos que el escalado —o, más concretamente, el escalado no planificado— es la causa común de las preocupaciones mencionadas anteriormente.

Afortunadamente, el modelo de objetos de configuración de NGINX Controller aborda las tres cuestiones:

• Reduce la complejidad de la implementación al reunir en una única ubicación todos los componentes de configuración que podrían afectar a un conjunto específico de instancias de NGINX Plus.
• Reduce la fragilidad al permitir que los equipos validen y prueben las configuraciones antes de implementarlas en producción, lo que facilita detectar los errores cuanto antes y garantiza que el tráfico de usuarios en producción siga fluyendo.
• Promueve la seguridad gracias a su gran flexibilidad. En lugar de obligarle a adaptar sus procesos al modelo, el modelo de objetos de configuración está diseñado para ajustarse a los flujos de trabajo de su empresa y al reparto de responsabilidades. De este modo, puede otorgar a las distintas unidades de negocio el control adecuado sobre los elementos de configuración pertinentes.

Objetos de configuración del controlador

Profundicemos un poco más en algunos objetos de configuración clave para que entiendas mejor cómo funciona el modelo de Controller.

Entornos

En la mayoría de las organizaciones, el software pasa por varias etapas antes de su lanzamiento: desarrollo, aceptación por parte del usuario, preproducción, producción y otras fases de control de calidad. Estas etapas se corresponden con el objeto de NGINX Controller denominado Entorno.

Un Entorno es una zona de aislamiento para los elementos de configuración de Controller. Suele ser el nivel en el que se define el control de acceso basado en roles (RBAC). Los Entornos permiten trasladar artefactos de configuración idénticos a través de las distintas etapas, introduciendo cambios mínimos en elementos como los servidores de destino, los centros de datos y otros objetos de infraestructura que suelen diferir entre Entornos.

Puertas de enlace

Una puerta de enlace es un objeto de configuración dentro de un entorno que suele utilizarse como nivel superior para definir cómo se entregan las aplicaciones a los clientes —con ajustes como el nombre de host, el protocolo y el comportamiento de TLS/SSL—, aunque estos ajustes también pueden establecerse en un nivel inferior. En la práctica, los objetos de puerta de enlace suelen estar a cargo de los equipos de operaciones de red (NetOps), es decir, quienes gestionan los dispositivos de red perimetral o la DMZ. Las puertas de enlace también utilizan el concepto de «ubicación», que permite vincular Controller con las instancias de NGINX Plus que reciben las configuraciones y realizan el trabajo propiamente dicho.

Aplicaciones

El siguiente nivel es el objeto de configuración App, donde puede empezar a modelar aplicaciones y agrupar comportamientos de gestión del tráfico. Puede utilizar tantas Apps como necesite para satisfacer las necesidades de su organización. El único requisito es que cada App sea única dentro de un Environment.

Componentes

Dentro de una aplicación, los componentes describen el comportamiento deseado para la gestión del tráfico de la aplicación. En el caso más sencillo, todo el tráfico de una ruta determinada se envía al mismo grupo de servidores. Sin embargo, los componentes también permiten controlar opciones más avanzadas, como la manipulación de cabeceras, la reescritura de URL, el comportamiento del balanceo de carga del backend, la gestión de cookies y otros ajustes. El comportamiento del nombre de host y de TLS/SSL también puede definirse en este nivel.

Cómo encaja todo

A continuación se muestra una representación visual de la relación entre los objetos de configuración:

Observe que solo hay dos grupos que interactúan con Controller: en este caso, dos equipos de desarrollo, Referencias y Transferencias. En realidad, sabemos que el número de personas implicadas en la entrega y la seguridad de aplicaciones probablemente sea mucho mayor e incluya a profesionales de redes y seguridad (operaciones de plataforma), DevOps, desarrollo de aplicaciones y otras áreas. Los equipos con más conocimientos pueden establecer políticas y crear flujos de trabajo de autoservicio que se ajusten a las prácticas recomendadas y proporcionen medidas de protección a los equipos que trabajan con aplicaciones, componentes y puertas de enlace dentro del entorno «Dev», que abarca las ubicaciones de los centros de datos Este y Oeste de la organización.

Veámoslo de una forma ligeramente distinta, más desde la perspectiva de una línea de negocio (LOB). Los responsables de las líneas de negocio toman cada vez más decisiones sobre las aplicaciones modernas.

El siguiente diagrama ilustra un escenario más realista que abarca un grupo de usuarios mucho más amplio, incluidos varios equipos de las líneas de negocio (LOB) y Shawn, la persona que gestiona todas las renovaciones de certificados.

Ahora tenemos más actores individuales y canalizaciones que influyen en el flujo de datos resultante.

A medida que cada canalización avanza por los distintos cambios de objetos desde el control de código fuente (como GitHub) hasta Controller, los objetos de configuración se validan en Controller y, a continuación, se combinan con los objetos relacionados antes de enviar los cambios a las instancias de NGINX Plus.

Así es como Controller puede ayudar a que la gestión de la configuración sea más segura: garantizando que los cambios más recientes sean compatibles con la configuración anterior y con la de otros propietarios de aplicaciones y líneas de negocio.

Somos conscientes de que, en la práctica, todas las configuraciones que se aplican a una única instancia de NGINX Plus deben ser viables, pero los ajustes no deben entrar en conflicto, solaparse ni interferir entre sí. Además, es importante detectar los conflictos de antemano e informar a las personas responsables de proporcionar la configuración de cada componente.

En el ejemplo anterior, cuando el componente Referencias intenta utilizar el mismo patrón de expresión regular que ya ha implementado el componente Transferencias, se detecta inmediatamente un conflicto de rutas y se puede avisar al equipo de Referencias mucho antes de que intente desplegar esta configuración en producción, evitando así los numerosos problemas asociados a una configuración incorrecta.

En lo que respecta a los certificados, Shawn puede implementar cambios de inmediato gracias a la funcionalidad RBAC de Controller. Los responsables del mantenimiento del Gateway y de los Components solo tienen que hacer referencia a los certificados correctos, y Shawn puede gestionarlos con confianza durante todo su ciclo de vida. Si Shawn actualiza un certificado en Controller, este se distribuye a las instancias correspondientes, evitando la alarma que suele provocar la caducidad de un certificado.

Ahora que NGINX Controller dispone de todos sus objetos de configuración y de una asociación de ubicación con una o varias instancias de NGINX Plus, puede llevar a cabo los últimos pasos: aplicar la configuración.

La seguridad en la práctica

En última instancia, el objetivo de la gestión de la configuración con Controller es aplicar la configuración correcta a las instancias de NGINX Plus adecuadas en la ubicación correspondiente. Garantizar que las aplicaciones, los componentes, las puertas de enlace y todos los certificados e instancias asociados estén configurados correctamente permite realizar implementaciones más seguras y escalables.

Esta verificación final es la última parte del proceso de gestión de la configuración que Controller facilita y hace más seguro. La configuración completa se verifica al aplicarla a una instancia de NGINX Plus en la que se haya modificado algún objeto asociado —por ejemplo, la persistencia de sesión en un grupo de cargas de trabajo web para NGINX Plus implementado como proxy—, lo que garantiza que la instancia sea compatible con la configuración deseada. Si se cumple esta condición, se aplica la configuración. Y, como última medida de seguridad, si se produce algún error al aplicar la configuración, Controller revierte a una configuración anterior.

Además de garantizar que las configuraciones superen las comprobaciones, Controller también puede aprovechar funcionalidades avanzadas de NGINX, como el drenaje de sesiones, cuando se aplica una nueva configuración, lo que garantiza que los sitios mantengan su disponibilidad y rendimiento durante los cambios.

Para los equipos de operaciones, los conceptos y diseños de flujos de trabajo descritos anteriormente contribuyen a la seguridad que ofrece NGINX Controller en la gestión de la configuración. Estas medidas de protección ayudan a coordinar los flujos de trabajo y los distintos equipos que trabajan con aplicaciones modernas, al tiempo que satisfacen las necesidades de la empresa.

Para probar NGINX Controller, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Brian EhlertDirector de Gestión de Producto

Más artículos de Brian Ehlert