Una sola puerta de entrada para cada herramienta interna, un patrón de self-hosting

Todo equipo de operaciones acumula herramientas pequeñas. Un task board, un servidor de dashboards, una consola de contenedores, un gestor de contraseñas, un par de aplicaciones web internas que alguien escribió. Cada una empieza su vida en su propio puerto, con su propio certificado y su propia idea de la autenticación, y al cabo de un año nadie está seguro de cuáles están expuestas, cuáles están parcheadas, o cuáles tienen todavía un certificado válido. Este es el patrón que usamos para operar todo un conjunto de herramientas internas como un único servicio bien cuidado: una sola puerta de entrada, una sola forma de arrancar las cosas, una sola política de acceso.

La forma de la pila

El patrón tiene cuatro capas, y cada una tiene un trabajo:

• DNS: un nombre wildcard, como *.tools.example.com, que apunta a un único host.
• Reverse proxy: Traefik en ese host, terminando TLS y encaminando cada hostname al contenedor correcto.
• Contenedores: cada herramienta en su propio contenedor Podman en una red de contenedores privada, sin puertos publicados en el host salvo los del proxy.
• Supervisión: systemd arranca, reinicia y ordena todo, de modo que la pila sobrevive a un reinicio sin que intervenga nadie.

Con esto en su sitio, añadir una herramienta es una lista corta en lugar de un proyecto: arrancar un contenedor en la red, añadir una ruta, listo. No hay un nuevo agujero en el firewall, ni un nuevo registro DNS, ni una nueva solicitud de certificado.

DNS: un wildcard, y olvídese

Un registro wildcard significa que tasks.tools.example.com, grafana.tools.example.com y vault.tools.example.com resuelven todos al host del proxy sin que nadie vuelva a tocar el DNS. Combínelo con un certificado wildcard para el mismo nombre, y cada herramienta nueva nace con TLS válido.

Mantenga el wildcard en un subdominio dedicado. No quiere que cualquiercosa.example.com aterrice en su host de herramientas.

El proxy: rutas como ficheros que se pueden leer

Traefik puede descubrir rutas a partir de etiquetas de contenedor o de ficheros de configuración sencillos. Para una pila pequeña y de larga vida preferimos los ficheros: son fáciles de revisar, fáciles de poner bajo control de versiones, y no cambian porque alguien reiniciara un contenedor con etiquetas distintas. Una ruta para un gestor de tareas tiene este aspecto:

http:
  routers:
    tasks:
      rule: "Host(`tasks.tools.example.com`)"
      entryPoints: [websecure]
      service: tasks
      middlewares: [mgmt-only]
      tls: {}
  services:
    tasks:
      loadBalancer:
        servers: [{ url: "http://tasks:3456" }]
  middlewares:
    mgmt-only:
      ipAllowList:
        sourceRange: ["192.0.2.0/24"]

El middleware es la parte importante. El proxy es el único lugar donde decide quién puede llegar a una herramienta, así que ponga la decisión ahí.

Acceso: dos cerraduras, no una

Las herramientas internas tienen sus propios inicios de sesión, y su calidad varía. No confíe solo en ellos. Ponga dos controles por delante, en capas:

• Una lista de origen permitida en el proxy, limitada a las redes desde las que su equipo trabaja realmente. Expanda cada CIDR antes de escribirlo y léalo de vuelta después. Una longitud de prefijo mal tecleada puede convertir un único rango de oficina en una gran parte de internet:

python3 -c "import ipaddress,sys; n=ipaddress.ip_network(sys.argv[1],strict=False); print(n, n[0], '->', n[-1], n.num_addresses)" 192.0.2.0/24

• Un middleware de autenticación (basic auth sobre TLS como mínimo, o autenticación delegada a su proveedor de identidad) para las herramientas que no deberían ser alcanzables ni siquiera desde dentro sin una segunda credencial.

El gestor de contraseñas merece una reflexión especial. Un servidor compatible con Bitwarden como Vaultwarden almacena el contenido de las bóvedas cifrado por los clientes, de modo que el servidor nunca lo tiene en forma legible. Es una propiedad fuerte, pero no elimina la necesidad de restringir quién puede llegar al servidor.

Contenedores bajo systemd

Ejecutar contenedores a mano funciona hasta el primer reinicio. Podman se integra con systemd a través de Quadlet: describe el contenedor en un pequeño fichero de unidad y systemd lo trata como cualquier otro servicio.

# /etc/containers/systemd/tasks.container
[Unit]
Description=Task manager
After=network-online.target

[Container]
Image=docker.io/vikunja/vikunja:<pinned-tag>
Network=tools.network
Volume=/srv/tools/tasks:/app/vikunja/files:Z

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Tras systemctl daemon-reload, systemctl start tasks lo ejecuta, y a partir de entonces arranca con el sistema. Fije las etiquetas de imagen en lugar de seguir latest, de modo que una actualización sea una decisión que usted toma, con un volcado y un rollback preparados, en lugar de algo que le ocurre en el siguiente reinicio.

Mantenga SELinux enforcing. Etiquete cada volumen para el contenedor que lo posee (:Z para un volumen privado, :z para uno que más de un contenedor debe compartir).

Renombrar sin romper nada

Tarde o temprano una herramienta se mueve: un host nuevo, un dominio nuevo, un nombre más ordenado. Mantenga el nombre antiguo funcionando haciendo que el proxy lo responda con una redirección permanente al nuevo. Use 308 Permanent Redirect en lugar de 301, porque un 308 indica a los clientes que repitan el mismo método y el mismo cuerpo en la nueva dirección.

Hay una trampa que muerde a los scripts, no a los navegadores. Los navegadores siguen las redirecciones. Muchos clientes de línea de comandos y librerías no lo hacen, a menos que se les indique. Un script que envía un POST al nombre antiguo recibe un 308, no lo sigue, y sigue adelante. No se creó nada, nada falló de forma ruidosa, y si el script solo comprueba que algo respondió, informa de éxito. Con curl, use -L para seguir, y compruebe siempre el código de estado y el cuerpo:

curl -s -o out.json -w '%{http_code}\n' -X POST https://tasks.tools.example.com/api/v1/...

Un cuerpo de respuesta con las palabras «Permanent Redirect» donde esperaba JSON es la señal. Cuando renombre, busque el nombre antiguo en sus scripts e integraciones y actualícelos, y conserve la redirección solo como red de seguridad.

Backups, monitorización y parcheo

Monitorice cada ruta desde fuera del host buscando la página esperada, no simplemente una respuesta, y parchee una herramienta cada vez con la imagen anterior conservada hasta que la nueva haya funcionado durante un tiempo.

Una lista de comprobación para sus propias herramientas

• ¿Puede enumerar cada herramienta interna, su hostname y quién puede llegar a ella?
• ¿Publica alguna herramienta su propio puerto al host o a internet, saltándose el proxy?
• ¿Son todos sus rangos de la lista permitida tan estrechos como cree? Expándalos y mire.
• ¿Vuelven sus contenedores por sí solos tras un reinicio?
• ¿Comprueban sus scripts los códigos de estado, o solo que algo respondió?
• ¿Cuándo restauró por última vez su gestor de contraseñas?

Una sola puerta de entrada, una sola política y una sola forma de arrancar las cosas convierten un cajón de herramientas sueltas en un servicio sobre el que se puede razonar.

CTA

Si quiere que las herramientas de su equipo se operen así, en su propia instancia, nuestros ingenieros pueden ayudarle. Hable con un ingeniero

Related

Relacionado: Herramientas de operaciones self-hosted gestionadas · El hardening baseline de cada host