Cómo decide Albgott quién entra.
Lo que una conexión tiene que atravesar antes de llegar a algo. /system explica qué hay desplegado; esta página explica quién puede tocarlo y qué no está terminado todavía.
La postura por defecto
Todo lo que hay en esta página es una variación de una sola regla: el tráfico entre mis redes se deniega por defecto, y cada excepción es una regla con nombre en el MikroTik, con un origen, un destino y un puerto. Que dos máquinas estén en redes "internas" no les permite hablar. Una regla para ese flujo exacto, sí.
El router se protege a sí mismo de la misma forma: solo responde a lo poco que tiene que responder y descarta todo lo demás antes de que llegue a importar.
El tráfico de salida es la única excepción deliberada. Mis redes pueden salir a internet libremente, porque CI necesita descargar dependencias y los hosts necesitan actualizarse, y mantener una lista de cada destino legítimo costaría más de lo que protege. La entrada es una lista blanca estricta. La salida no, y lo sé.
Que dos máquinas compartan red no les permite hablar. Una regla escrita para ese flujo exacto, sí.
El MikroTik solo ve el tráfico que cruza entre redes, así que cada host tiene además su propio firewall: el de Proxmox para las máquinas invitadas y ufw en todo lo demás. Y antes de que un host ejecute nada, recibe la misma base: SSH solo con clave, sin login de root y sin contraseña como alternativa. El proceso completo está en /operations.
Entrar en remoto
El acceso remoto pasa por dos túneles WireGuard separados, los dos terminados en el MikroTik: uno para el trabajo diario y otro para administrar la infraestructura. Un dispositivo conectado nunca entra en una VLAN. Recibe una dirección en un overlay enrutado y el firewall lo filtra como a cualquier otra red, así que puede tratar un portátil por VPN de forma distinta al mismo portátil conectado en casa.
La separación tiene que ver con quién está al otro lado. Trabajo con otras personas, y el túnel de trabajo es por donde se conectan: llega a las herramientas internas y ahí se queda. El túnel de administración es el único camino al plano de control, y ningún colaborador lo tiene. Un dispositivo comprometido en el túnel de trabajo no puede llegar a la consola de un hipervisor, y para eso existen dos túneles.
Un peer es un dispositivo, no una persona. Mi móvil y mi portátil son peers distintos, cada uno con el nombre del dispositivo y de su túnel, así que si pierdo el móvil revoco un peer y nada más cambia. Una configuración de peer nunca se comparte entre dispositivos, y si sospecho que una clave se ha filtrado, creo un peer nuevo en lugar de reutilizar el viejo. Los clientes usan split tunnel, así que solo las redes de Albgott pasan por la VPN.
Algo que aprendí equivocándome: que el handshake de WireGuard funcione solo significa que el dispositivo ha llegado al router. No dice nada de lo que puede hacer después. Cada pregunta la responde una capa distinta:
| Capa | Decide |
|---|---|
| WireGuard | Si el dispositivo puede crear el túnel cifrado |
| Rutas del cliente (AllowedIPs) | Qué redes de destino entran en el túnel |
| Firewall del router | Qué combinaciones de origen, destino y puerto se permiten |
| DNS | Qué nombres resuelven a direcciones internas |
| Autenticación de la aplicación | Si la persona puede usar la aplicación a la que ha llegado |
La última fila lleva a la siguiente sección. La VPN pone al dispositivo en el camino correcto; la aplicación decide si la persona que hay detrás es quien dice ser.
Quién eres una vez dentro
Hay dos proveedores de identidad, y los dos funcionan hoy por motivos distintos. Authentik es el objetivo a largo plazo: con el tiempo, todo debería iniciar sesión a través de él. Zitadel está para las aplicaciones públicas que necesiten sus propios usuarios, porque trae multi-tenancy real (usuarios, proyectos y ajustes separados por organización) desde el principio.
Lo que sigue en curso es qué servicios están de verdad detrás del SSO de Authentik. Hoy es el stack de observabilidad, con MFA mediante una app de autenticación. El resto no es solo cuestión de tiempo: algunos servicios solo ofrecen SSO en su plan de pago, y eso frena el despliegue por motivos que no controlo. Aquí la identidad funciona y está sin terminar a la vez.
| Servicio | Qué es | Accesible por | Estado |
|---|---|---|---|
| Authentik | Proveedor de identidad principal, el objetivo a largo plazo para todo | Solo proxy interno | En marcha; hoy el stack de observabilidad, MFA con app de autenticación |
| Zitadel | Segundo proveedor de identidad, multi-tenant, para futuras aplicaciones públicas | Proxy público | En marcha; todavía sin uso en producción |
Dónde viven los secretos
Infisical funciona como gestor de secretos solo interno. El objetivo es sencillo: dejar de guardar credenciales en texto plano dentro de ficheros de configuración y de compose repartidos por los hosts, y darles un único sitio gestionado.
La migración sigue en curso. Primero decido qué secretos se mueven; solo cuando Infisical es de verdad la fuente de verdad para ellos cambio lo que los consume. Ese orden importa sobre todo en CI, donde un error hace más daño. Los agentes de build viven en su propia VLAN y solo llegan a los pocos servicios que un despliegue necesita de verdad. Nada permite que un build comprometido llegue al plano de gestión.
Vigilar los problemas
Seguridad y observabilidad comparten stack: la monitorización descrita en /operations es también lo que antes notaría la mayoría de problemas de acceso. Uptime Kuma comprueba los endpoints desde fuera mientras Prometheus vigila desde dentro, así que una mala configuración se ve aunque las métricas parezcan correctas. Las alertas van a un solo móvil. Las críticas saltan antes, y los avisos de un host se silencian mientras haya una alerta crítica activa para ese mismo host, así que un problema real se oye una vez y con claridad.
El hueco: nada de esto se diseñó como monitorización de seguridad. Detecta bastante de rebote, y las alertas específicas de seguridad están en el roadmap.
Lo que sigue abierto
Las carencias de las secciones anteriores, en un solo sitio:
Todavía no hay copias fuera de los nodos, así que rehacer un host comprometido significaría reconstruirlo desde la documentación, no restaurar una copia buena conocida. Está recogido en /operations.
Authentik y Zitadel funcionan, pero no todos los servicios inician sesión con ellos todavía. Los voy pasando de uno en uno.
Infisical está en marcha, pero algunas credenciales siguen en ficheros de configuración en los hosts, que es justo lo que Infisical viene a sustituir.
La observabilidad general está montada y es útil, pero las alertas pensadas específicamente para seguridad siguen en el roadmap.
Lo siguiente: /system explica qué hay desplegado, y /operations cómo se mantiene funcionando.