Añadir servidores

InfraWard no usa agentes. Llega a cada servidor por SSH con una cuenta dedicada de solo lectura que crea el script de alta. Solo das de alta las máquinas de primer nivel: un nodo Proxmox, un host Docker o Podman, un servidor Plesk o un Linux normal. Lo que contienen (CT, VMs, contenedores, imágenes, sitios) se descubre solo.

Dar de alta un servidor requiere el permiso assets.write (roles Admin y Editor).

Antes de empezar

Comprueba que el servidor cumple los requisitos de los servidores gestionados: OpenSSH con sshd_config.d, sudo (o deja que lo instale el script), python3 y el reloj sincronizado. El worker de InfraWard tiene que llegar al servidor por su puerto SSH.

1. Genera el comando

Ve a Inventario → Añadir servidor.

1. Servidor: la IP o el hostname con el que el worker llegará al servidor, el puerto SSH (22 por defecto) y un nombre opcional.

2. Acceso: cómo entra InfraWard.

   Modo	Cómo funciona	Cuándo usarlo
   Certificados de vida corta (CA SSH de OpenBao)	No se instala ninguna clave. sshd confía en la CA de InfraWard solo para el usuario inventory. Cada trabajo obtiene un certificado válido durante 5 minutos.	Por defecto y recomendado. Requiere OpenBao.
   Clave estática	InfraWard genera un par de claves ed25519, guarda la privada en el proveedor de secretos e instala la pública en authorized_keys con restrict.	Sin OpenBao, o cuando no puedes tocar la configuración de sshd. Permite además el alta manual.

3. Opciones:

   • Instalar sudo si falta (--install-sudo): el script instala sudo con el gestor de paquetes del sistema. Necesario en Proxmox VE. Con esta opción, el comando se ejecuta como root, sin sudo.
   • Permitir acceso interactivo de administración: solo para administradores y en modo con certificados. Crea la cuenta infraward-admin, que usa la terminal web. Puedes retirarla después desde la ficha del servidor.

4. Organización y política (opcional): etiquetas, proyectos, una plantilla de política y exclusiones del escaneo. Se aplican antes de la primera recolección y del primer escaneo, lo que sirve para dejar un servidor fuera del escaneo desde el principio.

5. Pulsa Generar comando de alta.

2. Ejecuta el comando en el servidor

La página muestra el comando, cuándo caduca y dos pestañas.

Por URL (por defecto)

El servidor descarga el script de InfraWard y avisa cuando termina:

curl --proto =https --proto-redir =https -fsSL --max-time 120 https://infraward.example.com/api/enroll/<token> | sudo bash

En un servidor sin sudo (por ejemplo, Proxmox VE), ejecútalo como root con la opción:

curl --proto =https --proto-redir =https -fsSL --max-time 120 https://infraward.example.com/api/enroll/<token> | bash -s -- --install-sudo

El token es de un solo uso y caduca a los 20 minutos por defecto (ENROLLMENT_TOKEN_TTL, entre 15 y 30 minutos). Solo se guarda su hash. Si caduca, pulsa Generar comando nuevo.

Con una URL https, --proto =https --proto-redir =https impide que curl siga una redirección a HTTP sin cifrar, donde cualquiera en el camino podría cambiar un script que se ejecuta como root. --max-time 120 evita que se quede colgado. Al avisar a InfraWard, el script también usa solo HTTPS si la URL de la API es https.

Script embebido (VPN/NAT)

Para servidores que no llegan a InfraWard. El script entero va en el comando, comprimido y en base64, y no lleva token:

echo '<script en base64>' | base64 -d | gunzip | sudo bash

El script imprime las huellas SHA256 de las host keys del servidor. Pégalas en InfraWard para terminar el alta. El worker sigue necesitando llegar al servidor por SSH.

Alta manual (solo con clave estática): en lugar de ejecutar el script, añade la clave pública que muestra InfraWard al authorized_keys de una cuenta existente (nunca root) y pulsa Ya lo he añadido. Sin el script no hay ayudante restringido, así que la recolección se limita a lo que pueda leer esa cuenta.

3. Sigue el progreso

La página avanza sola: Comando generado → Esperando clave → Conectando → Escaneando → Listo.

1. El worker se conecta con StrictHostKeyChecking=yes contra las huellas que envió el script. Si no coinciden, rechaza la conexión y no recoge nada.
2. Recolección con Ansible: sistema, paquetes, servicios, puertos en escucha y red.
3. Descubrimiento: CT y VMs de Proxmox; contenedores, imágenes, redes y volúmenes de Docker y Podman; suscripciones de Plesk.
4. Escaneos: un SBOM del servidor y de cada imagen de contenedor, evaluados con Trivy.

En nuestras pruebas, un host Docker con cuatro contenedores tardó unos dos minutos, casi todo en escanear las imágenes. Las imágenes grandes tardan más.

Si un paso falla, la pestaña Recolecciones del servidor muestra el log de esa ejecución con el error. Consulta Logs de las ejecuciones.

Qué cambia el script en el servidor

El script es idempotente: si lo vuelves a ejecutar, actualiza la configuración sin duplicar nada. Solo toca los ficheros de esta tabla.

Ruta	Modo	Para qué
Usuario inventory	los dos	Cuenta dedicada con shell pero sin contraseña.
/usr/local/libexec/infraward/infraward-query	los dos	Ayudante de root con una lista cerrada de consultas de solo lectura. Valida cada argumento y ejecuta los comandos sin shell.
/etc/sudoers.d/infraward-inventory	los dos	Una regla: inventory puede ejecutar el ayudante con sudo -n. Nunca ALL. Se valida con visudo.
/etc/infraward/sudoers-version	los dos	Versión de la regla, para que InfraWard avise cuando haya que actualizarla.
~inventory/.ssh/authorized_keys	clave estática	Una línea por asset, marcada con inventory@infraward:<id-del-asset>, con restrict. Se escribe como inventory, nunca como root. El script se detiene si ~/.ssh o authorized_keys son un enlace simbólico o pertenecen a otro usuario.
/etc/ssh/sshd_config.d/00-infraward.conf	certificados	Bloque Match User inventory: CA de confianza, fichero de principales, sin TTY y sin reenvíos. Se valida con sshd -t y se deshace si falla.
/etc/ssh/infraward/trusted_user_ca_keys y /etc/ssh/infraward/principals/inventory	certificados	Clave pública de la CA de InfraWard y el único principal aceptado.
Usuario infraward-admin, /etc/ssh/sshd_config.d/01-infraward-admin.conf, /etc/sudoers.d/infraward-admin	acceso de administración	Cuenta de la terminal web. Solo acepta certificados de la CA con el principal infraward-operators; ni claves ni contraseña.
/etc/infraward/podman-users	ambos, opcional	Usuarios de Podman rootless que InfraWard puede consultar. Solo se escribe con --podman-users; lo normal es que lo escriba después Habilitar (consulta Podman).

El sshd_config principal no se modifica nunca. Si sshd_config limita los usuarios con AllowUsers o AllowGroups y deja fuera a inventory, el script avisa y no cambia nada.

Nodos Proxmox, hosts Docker y Podman como root

En estos hosts el ayudante restringido limita menos de lo que parece. Para recoger los CT, InfraWard usa pct exec, que es root dentro del CT, y un CT privilegiado no aísla del host. En los hosts Docker, el ayudante solo permite consultas de lectura y docker save de una imagen, pero docker inspect muestra la configuración de los contenedores, variables de entorno incluidas. No añadas nunca inventory al grupo docker. Podman como root (podman con root) equivale a lo mismo; los usuarios rootless de /etc/infraward/podman-users solo exponen sus propios contenedores.

Comprueba el resultado en el servidor

sudo -l -U inventory
sudo sshd -T -C user=inventory,host=localhost,addr=127.0.0.1 | grep -Ei 'trustedusercakeys|authorizedprincipalsfile'

Notas por plataforma

• Proxmox VE: da de alta el nodo con --install-sudo. Los CT se descubren y se recogen desde el nodo con pct exec; instala python3 en cada CT que quieras recoger. Las VMs se descubren desde el nodo; para recoger su contenido, da de alta cada VM como servidor.
• Docker: se descubren contenedores, imágenes, redes y volúmenes. Las imágenes se exportan con docker save y se escanean en el worker, así que nunca se ejecutan.
• Podman: consulta más abajo.
• Plesk: se descubren suscripciones, dominios, bases de datos y certificados. Las consultas de Plesk nunca leen contraseñas ni claves privadas.

Podman

Los hosts con Podman reciben el rol podman-host. InfraWard usa el comando nativo podman, así que no hace falta podman-docker ni un socket de root, y un mismo host puede tener Docker y Podman a la vez.

• Podman como root: los contenedores, imágenes, volúmenes y redes se inventarían igual que los de Docker. Los pods y los contenedores de quadlet o de systemd se ven en cada contenedor (el contenedor infra del pod no se inventaría). Las imágenes se exportan con podman save y se escanean en el worker, y la terminal web se abre en estos contenedores.
• Podman rootless: cada recolección detecta, en modo lectura, los usuarios que usan Podman (contenedores en marcha, un socket de usuario activo o almacén de contenedores en su home). Aparecen en la tarjeta Usuarios de Podman del servidor con uno de tres estados: Inventariado, Sin socket o Sin habilitar. Los detectados sin habilitar y los habilitados sin socket activo generan además un aviso en el servidor.

Detectar un usuario no habilita nada. Para inventariar sus contenedores, pulsa Habilitar en esa tarjeta. InfraWard ofrece dos formas de ejecutar el mismo script, que activa linger y el podman.socket del usuario y lo añade a /etc/infraward/podman-users, el consentimiento del lado del servidor:

Opción	Cuándo
Copiar el comando y ejecutarlo con cualquier cuenta con sudo	Siempre.
Ejecutar con infraward-admin	El servidor tiene el acceso de administración y puedes abrir una terminal en él. Abre una terminal de solo lectura que muestra el comando y su salida.

Después vuelve a recolectar el servidor. Los contenedores de esos usuarios aparecen con su propietario (alice/web). InfraWard consulta el socket de cada usuario ejecutando el cliente de Podman como ese usuario, nunca como root.

Para fijar la lista a mano en el alta, añade --podman-users al comando, por ejemplo curl … | sudo bash -s -- --podman-users=alice,bob. --podman-users= la vacía; sin la opción, la lista no se toca.

Podman necesita la versión 8 del sudoers (InfraWard 0.6.0). En un host con Podman dado de alta con una versión anterior, el servidor muestra sudoers desactualizado y no se inventaría nada de Podman: regenera el comando y vuelve a ejecutarlo.

Mantenimiento

En la ficha del servidor, InfraWard avisa cuando la regla de sudoers o las claves de la CA instaladas en el servidor están desactualizadas. Usa Regenerar el comando y ejecuta el comando nuevo: actualiza el servidor sin darlo de baja.

Un servidor dado de alta con clave estática puede pasar a certificados con Pasar a certificados (CA). Ejecuta el comando que genera; el script quita la clave estática solo cuando sshd ya acepta certificados, e InfraWard borra la clave privada del proveedor de secretos en cuanto el worker conecta con un certificado.

Dar de baja un servidor

Acción	Efecto
Retirar, en el acceso de administración	Elimina infraward-admin y sus ficheros de sshd y sudoers. El servidor sigue en el inventario.
Dar de baja	Reversible. El asset pasa a retirado, se cancelan las altas pendientes y se borra la clave estática del proveedor de secretos. InfraWard muestra un comando de limpieza.
Purgar	Definitivo. Borra el asset, su historial y sus hallazgos. Solo admin, con reautenticación.

Ejecuta en el servidor el comando de limpieza que muestra InfraWard. Quita la línea del asset de authorized_keys, la confianza en la CA y la cuenta de administración (en modo con certificados) y, si ningún otro asset de InfraWard los usa, la regla de sudoers, el ayudante y el usuario inventory. sshd solo se recarga si sshd -t es correcto.