Gestión de configuración más segura con el controlador NGINX

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

• Complejidad : administrar, mantener, validar y aplicar grandes conjuntos de objetos de configuración individuales de diferentes fuentes no es fácil.
• Fragilidad : La ampliación puede ocurrir rápidamente, a menudo en respuesta a un evento. A veces es estratégico, pero como suele suceder en todos los departamentos de operaciones, no es planificado y es orgánico.
• Seguridad : evitar errores y detectar problemas antes de la implementación en producción son piedras angulares de la metodología ágil. También ayudan a mitigar la complejidad y la fragilidad.

Éstas no son preocupaciones que los clientes generalmente enfrentan cuando implementan una aplicação por primera vez. Más bien, surgen a medida que pasa el tiempo y la aplicação se vuelve exitosa y necesita ampliarse. Consideramos que el escalamiento –o, más precisamente, el escalamiento no planificado– es la causa común de las preocupaciones mencionadas anteriormente.

Afortunadamente, el modelo de objetos de configuración del controlador NGINX aborda las tres preocupaciones:

• Reduce la complejidad de 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 colocarlas en producción, lo que facilita fallar rápidamente y garantiza que el tráfico de usuarios de producción siga fluyendo.
• Promueve la seguridad porque es muy flexible. En lugar de obligarlo a ajustar sus procesos para que se ajusten al modelo, el modelo de objetos de configuración está diseñado para alinearse con los flujos de trabajo de su negocio y la división de responsabilidades: puede otorgar a varias unidades de negocio la propiedad adecuada sobre los elementos de configuración según corresponda.

Objetos de configuración del controlador

Profundicemos un poco más en algunos objetos de configuración clave para brindarle una mejor idea de cómo funciona el modelo del controlador.

Entornos

En la mayoría de las organizaciones, el software pasa por múltiples etapas antes de su lanzamiento: desarrollo, aceptación del usuario, preproducción, producción y otras etapas de control de calidad. Estas etapas corresponden al objeto Controlador NGINX llamado Entorno.

Un entorno es una zona de aislamiento para los elementos de configuración dentro del controlador. Comúnmente es el nivel donde se define el control de acceso basado en roles (RBAC). Los entornos pueden llevar artefactos de configuración idénticos a través de las distintas etapas y al mismo tiempo sustituir cambios mínimos en elementos como servidores de destino, centros de datos y otros objetos de infraestructura que comúnmente difieren entre entornos.

Puertas de enlace

Un Gateway es un objeto de configuración dentro de un entorno, a menudo utilizado como el nivel superior para definir cómo se entregan las aplicações a los clientes (configuraciones como nombre de host, protocolo y comportamiento TLS/SSL), aunque dichas configuraciones también se pueden realizar en un nivel inferior. En la práctica, los equipos de operaciones de red (NetOps), las personas que administran los dispositivos de red perimetral o la DMZ, generalmente son los propietarios de objetos Gateway. Las puertas de enlace también emplean el concepto de “Ubicación”, que es la forma en que se vinculan el controlador y las instancias NGINX Plus que reciben las configuraciones y hacen el trabajo real.

Aplicaciones

El siguiente nivel hacia abajo es el objeto de configuración de la aplicación, donde se empiezan a modelar aplicações y a agrupar comportamientos que modelan el tráfico. Puede utilizar tantas o tan pocas aplicaciones como necesite para satisfacer las necesidades de su organización. El único requisito es que una aplicación debe ser única dentro de un entorno.

COMPONENTES

Dentro de una aplicación, los componentes describen el comportamiento de modelado de tráfico deseado para la aplicación. En el caso más simple, todo el tráfico para una ruta determinada se envía al mismo grupo de servidores. Pero los componentes también controlan configuraciones más avanzadas como la manipulación de encabezados, la reescritura de URL, los comportamientos de equilibrio de carga del backend, el manejo de cookies y otras configuraciones. El nombre de host y el comportamiento TLS/SSL también se pueden definir en este nivel.

Uniéndolo todo

Aquí se muestra una representación visual de la relación entre los objetos de configuración:

Tenga en cuenta que solo hay dos grupos que interactúan con el controlador: en este caso, dos equipos de desarrollo, Referencias y Transferencias . En realidad, sabemos que la cantidad de personas involucradas en la entrega y seguridad de aplicação es probablemente mucho mayor y abarca redes y seguridad (Platform Ops), DevOps, desarrollo de aplicaciones y más. Los equipos con más conocimiento pueden establecer políticas y crear flujos de trabajo de autoservicio que se alineen con las mejores prácticas y brinden protección para aquellos equipos que trabajan con aplicaciones, componentes y puertas de enlace dentro del entorno de "desarrollo", que abarca las ubicaciones de los centros de datos este y oeste de la organización.

Veámoslo de una manera ligeramente diferente, más desde la perspectiva de la línea de negocio (LOB) . Los propietarios de LOB toman cada vez más aplicação sobre aplicaciones modernas.

El siguiente diagrama ilustra un escenario más realista que incluye un grupo mucho más grande de usuarios que incluye varios equipos LOB y Shawn, el individuo que administra todas las renovaciones de certificados.

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

A medida que cada canal individual avanza a través de los diversos cambios de objetos desde el control de origen (como GitHub) al controlador, los objetos de configuración se validan en el lado del controlador y luego se combinan con cualquier objeto relacionado antes de que los cambios se envíen a las instancias NGINX Plus.

Así es como Controller puede ayudar a hacer más segura la gestión de la configuración: asegurándose de que los últimos cambios sean compatibles con configuraciones anteriores y configuraciones de otras aplicação y propietarios de LOB.

Somos conscientes de que, en la práctica, todas las configuraciones que se aplican a una única instancia de NGINX Plus deben ser posibles, pero las configuraciones no deben entrar en conflicto, superponerse ni entrar en conflicto entre sí. Y es importante detectar los conflictos desde el principio e informar a las personas que proporcionan la configuración de cada componente individual.

En el ejemplo anterior, cuando el componente de referencia intenta usar el mismo patrón de expresiones regulares que el componente de transferencias ya implementó, se detecta inmediatamente un conflicto de ruta y se puede notificar al equipo de referencia mucho antes de que intente implementar esta configuración en producción, lo que evita los muchos dolores de cabeza asociados con una configuración incorrecta.

Con respecto a los certificados, Shawn está habilitado, a través de la funcionalidad RBAC del controlador, para implementar inmediatamente los cambios de certificado. Los encargados del mantenimiento de Gateway y de los componentes solo necesitan hacer referencia a los certificados correctos y Shawn puede administrarlos con confianza en su propio ciclo de vida. Si Shawn actualiza un certificado en Controller, este se envía a las instancias correctas, sin el pánico asociado con la expiración de un certificado.

Ahora que NGINX Controller tiene todos los objetos de configuración y una asociación de ubicación con una o más instancias de NGINX Plus, puede realizar los últimos pasos: aplicar la configuración.

Seguridad en la práctica

Al final, el objetivo de la gestión de configuración con Controller es aplicar la configuración correcta en las instancias NGINX Plus correctas en la ubicación correcta, lo que garantiza que las aplicaciones, los componentes, las puertas de enlace y todos los certificados e instancias asociados estén configurados correctamente, lo que da como resultado 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 hace más fácil y seguro. Se verifica toda la configuración a medida que se aplica a una instancia de NGINX Plus que tenía algún cambio de objeto asociado (como la persistencia de la sesión en un grupo de carga 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 esa condición, se aplica la configuración. Y para el último detalle de seguridad, si algo falla al aplicar la configuración, el controlador vuelve a una configuración anterior.

Además de garantizar que las configuraciones pasen la prueba, Controller también puede aprovechar las capacidades avanzadas de NGINX, como el vaciado de sesiones, cuando se aplica una nueva configuración, lo que garantiza que los sitios mantengan la disponibilidad y el rendimiento a pesar de los cambios.

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

Para probar NGINX Controller, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .