¿Por qué lo creamos?
Durante mucho tiempo, en Rambler Group, utilizamos una arquitectura de red de centro de datos de tres niveles, en la que cada proyecto o componente de infraestructura vivía en un vlan dedicado. Todo el tráfico, tanto entre vlans como entre centros de datos, pasó por equipos de nivel de borde.
Los equipos de borde son enrutadores costosos capaces de realizar muchas funciones diferentes, por lo tanto, los puertos también son costosos. Con el tiempo, el tráfico horizontal creció (de máquina a máquina, por ejemplo, replicación de bases de datos, solicitudes a varios servicios, etc.) y en algún momento surgió el problema de la utilización de puertos en los enrutadores fronterizos.
Una de las principales funciones de estos dispositivos es el filtrado de tráfico. Como resultado, también se volvió más difícil administrar la ACL: tenía que hacer todo manualmente, además la ejecución de la tarea por parte del departamento adyacente también llevó tiempo. Se dedicó más tiempo a configurar puertos en el nivel de acceso. Era necesario realizar no solo acciones manuales de los mismos NOC, sino también identificar posibles problemas de seguridad, ya que los hosts cambian de ubicación, respectivamente, pueden obtener acceso ilegal a los vlans de otras personas.
Ha llegado el momento de cambiar algo, y las redes Clos, o, como también se les llama, fábricas de IP, acudieron al rescate.
A pesar de la similitud externa, la diferencia fundamental entre esta arquitectura y la anterior es que cada dispositivo, incluida la capa hoja, actúa como un enrutador, y la puerta de enlace predeterminada para el servidor es Top-of-Rack. Por lo tanto, el tráfico horizontal entre los hosts de diferentes proyectos ahora puede atravesar la capa de la columna vertebral y no el borde.
Además, en el mismo nivel de la columna vertebral, podemos conectar centros de datos entre sí, y ahora no hay más de cuatro dispositivos de red en la ruta entre dos servidores. Los equipos de borde en esta arquitectura solo se necesitan para conectar operadores de telecomunicaciones y solo permiten el tráfico vertical (hacia y desde Internet).
La característica principal de la red Klose es que carece de un lugar donde pueda filtrar el tráfico entre hosts. Por tanto, esta función debe realizarse directamente en el servidor. Un firewall centralizado es un programa que filtra el tráfico en el propio host que lo recibe.
Requisitos
La necesidad de implementar un firewall centralizado fue dictada por varios factores a la vez:
- consumidores finales y
- infraestructura existente.
Por tanto, los requisitos para la aplicación eran los siguientes:
- El firewall debe poder funcionar y crear reglas en el host y las máquinas virtuales. Además, la lista de reglas no debe diferir del entorno donde se ejecuta el firewall. Es decir, las reglas son idénticas.
- . , – ssh, ( Prometheus), .
- , -.
- , – .
- .
- : « , ».
La nube de Rambler Group es bastante dinámica: se crean y eliminan máquinas virtuales, se instalan y desmantelan servidores. Por lo tanto, no utilizamos el acceso punto a punto, nuestra infraestructura tiene el concepto de un "grupo de host".
Hostgroup es un marcado de un grupo de servidores que describe de forma única su función. Por ejemplo, news-prod-coolstream-blue.
Por lo tanto, sigue otro requisito: los usuarios deben operar con entidades de alto nivel: grupos de hosts, proyectos, etc.
Idea e implementación
Tulling Un
firewall centralizado es una cosa grande y compleja que requiere la configuración del agente. Encontrar problemas puede llevar más de cinco minutos, por lo que apareció una herramienta junto con el agente y el servidor, que le dice al usuario si el agente está configurado correctamente y qué debe solucionarse. Por ejemplo, un requisito importante para un host es la existencia de un registro DNS en el grupo de host o PTR. La herramienta le informará sobre todo esto y mucho más ( sus funciones se describen a continuación ).
Cortafuegos unificado
Intentamos adherirnos al siguiente principio: la aplicación que configura el firewall en el host debe ser la única para no recibir “reglas intermitentes”. Es decir, si el servidor ya tiene su propia herramienta de personalización (por ejemplo, si las reglas las configura otro agente), entonces nuestra aplicación no pertenece allí. Bueno, la condición opuesta también funciona: si existe nuestro agente de firewall, solo él establece las reglas; aquí está el principio del control total.
El cortafuegos no es iptables
Como ya sabe, iptables es solo una utilidad de línea de comandos para trabajar con netfilter. Para portar el firewall a diferentes plataformas (Windows, sistemas BSD), el agente y el servidor trabajan con su propio modelo. Más sobre esto a continuación, en la sección "Arquitectura" .
El agente no intenta resolver errores lógicos
Como se indicó anteriormente, el agente no toma ninguna decisión. Si desea cerrar el puerto 443, en el que ya se está ejecutando su servidor HTTP, no hay problema, ¡ciérrelo!
Arquitectura
Es difícil encontrar algo nuevo en la arquitectura de dicha aplicación.
- Tenemos un agente, él configura las reglas en el host.
- Tenemos un servidor, da reglas definidas por el usuario.
- Contamos con biblioteca y herramientas.
- Tenemos un solucionador de alto nivel: cambia las direcciones IP a grupos de hosts / proyectos y viceversa. Más sobre todo esto a continuación .
Rambler Group tiene muchos hosts e incluso más máquinas virtuales, y todas ellas, de una forma u otra, pertenecen a alguna entidad:
- VLAN
- Red
- Proyecto
- Grupo anfitrión.
Este último describe la pertenencia del anfitrión al proyecto y su función. Por ejemplo, news-prod-backend-api, donde: news - project; prod - su env, en este caso es producción; backend - función; api es una etiqueta personalizada arbitraria.
Firewall
Resolver opera a nivel de red y / o transporte, y los grupos de host y los proyectos son entidades de alto nivel. Por lo tanto, para "hacer amigos" y comprender quién es el propietario del host (o la máquina virtual), debe obtener una lista de direcciones; llamamos a este componente "Resolver de alto nivel". Cambia los nombres de alto nivel a un conjunto de direcciones (en términos del resolutor, está "contenido") y, a la inversa, una dirección al nombre de la entidad ("contiene").
Biblioteca - Núcleo
Para la unificación y unificación de algunos componentes, apareció una biblioteca, también se llama Núcleo. Es un modelo de datos con sus propios controladores y vistas que te permiten completarlo y leerlo. Este enfoque simplifica enormemente el código del lado del servidor y del agente, y también ayuda a comparar las reglas actuales en el host con las reglas recibidas del servidor.
Disponemos de varias fuentes para rellenar el modelo:
- archivos de reglas (dos tipos diferentes: simplificados y que describen completamente la regla)
- reglas recibidas del servidor
- reglas recibidas del propio anfitrión.
Agent
Agent no es un enlace sobre iptables, sino una aplicación independiente que funciona usando un contenedor sobre bibliotecas C libiptc, libxtables. El agente en sí no toma ninguna decisión, solo configura las reglas en el host.
La función del agente es mínima: leer los archivos de reglas (incluidos los predeterminados), obtener datos del servidor (si está configurado para operación remota), fusionar las reglas en un conjunto, verificar si difieren del estado anterior y, si difieren, aplicar.
Otro papel importante del agente es no convertir el host en una calabaza durante la instalación inicial o cuando recibe una respuesta no válida del servidor. Para evitar esto, proporcionamos un conjunto de reglas en el paquete de forma predeterminada, como ssh, monitoreo de acceso, etc. Si el agente de firewall recibe un código de respuesta que no sea el código de respuesta número 200, el agente no intentará realizar ninguna acción y abandonará el estado anterior. Pero no protege contra errores lógicos, si niega el acceso en los puertos 80, 443, el agente seguirá haciendo su trabajo, incluso cuando el servicio web se esté ejecutando en el host.
Tulza
Tulza está destinado a administradores de sistemas y desarrolladores que mantienen el proyecto. El objetivo es increíblemente simple: con un clic, obtener todos los datos sobre el trabajo del agente. La utilidad puede informarle sobre:
- ¿Se está ejecutando el demonio del agente?
- ¿Existe un registro PTR para el anfitrión?
- .
Esta información es suficiente para diagnosticar problemas en una etapa temprana.
Servidor
Servidor es aplicación + base de datos. Toda la lógica del trabajo la realiza él. Una característica importante del servidor es que no almacena direcciones IP. El servidor solo funciona con objetos de nivel superior: los nombres grupo de host, proyecto, etc.
Las reglas en la base son las siguientes: Acción: Aceptar Src: proyecto-B, proyecto-C Dst: Proyecto-B Proto: tcp Puertos: 80, 443.
¿Cómo entiende el servidor qué reglas dar ya quién? De los requisitos se desprende que las reglas deben ser idénticas independientemente de dónde se esté ejecutando el agente, ya sea un host o una máquina virtual.
Una solicitud de un agente siempre llega al servidor con un valor: una dirección IP. Es importante recordar que cada agente pide reglas para sí mismo, es decir, él es el destino.
Para comprender mejor el funcionamiento del servidor, considere el proceso de obtención de reglas de host que pertenecen a un proyecto.
El resolver entra en juego primero. Su tarea es cambiar la dirección IP por el nombre de host y luego averiguar en qué entidad se encuentra este host. HL-Resolver responde al servidor que el host está contenido en el proyecto A. HL-Resolver se refiere a la fuente de datos (que no hemos mencionado antes). Datasource es una especie de base de conocimientos de la empresa sobre servidores, proyectos, grupos de hosts, etc.
A continuación, el servidor busca todas las reglas para el proyecto con destino = nombre del proyecto. Como no tenemos direcciones en la base de datos, necesitamos cambiar el nombre de los proyectos a hostenyms y luego a direcciones, para que la solicitud se envíe nuevamente a la fuente de datos a través del resolutor. HL-Resoler devuelve una lista de direcciones, después de lo cual el agente recibe una lista de reglas preparada.
Si nuestro destino es un host con máquinas virtuales, entonces se ejecuta el mismo script no solo para el host, sino también para cada máquina virtual en él.
A continuación se muestra un diagrama que muestra un caso simple: un host (hardware o máquina virtual) recibe las reglas para el host en el Proyecto-A.
Lanzamientos
No es difícil adivinar que al tener una administración de firewall centralizada, también puede romper todo de manera centralizada. Por lo tanto, las liberaciones para el agente y el servidor se llevan a cabo por etapas.
Para el servidor: prueba azul-verde + A / B
Azul-verde es una estrategia de implementación que involucra a dos grupos de hosts. Y el cambio va en porciones 1,3,5,10 ... 100%. por lo tanto, si surgen problemas con la nueva versión, solo una pequeña fracción de los servicios se verá afectada.
Para un agente, Canary
Canary (o implementación canary) es algo similar a las pruebas A / B. Actualizamos solo algunos de los agentes y analizamos las métricas. Si todo va bien, cogemos otra pieza más grande y así sucesivamente hasta el 100%.
Conclusión
Como resultado, creamos un autoservicio para ingenieros de sistemas, que le permite administrar el acceso a la red desde un punto. Por lo tanto, nosotros:
- HTTP-API
- .