Cortafuegos y seguridad
No hay ningún puerto abierto para Zenavo
Zenavo nunca se conecta a tu servidor después de la configuración. El agente de Zenavo, instalado durante la configuración, se ejecuta en el servidor y conecta hacia fuera con el plano de control por HTTPS (puerto 443), y Zenavo envía despliegues, registros y terminales por esa conexión. Por tanto:
- API de Kubernetes (6443): ciérrala a internet. Solo la usa el agente, dentro del servidor.
- SSH (22): solo se necesita mientras dura la configuración, desde el plano de control de Zenavo. Después, permítelo solo desde donde administras el servidor, o ciérralo.
Mantén abiertos a todo el mundo el 80, el 443 y (si publicas puertos) el 30000–32767. La pestaña Firewall del servidor los comprueba desde el plano de control. El servidor debe poder llegar a la dirección de la consola por HTTPS.
Qué puede hacer el agente
El agente usa su propia cuenta de servicio de Kubernetes, limitada a lo que Zenavo necesita:
- Solo gestiona los espacios de nombres de los proyectos (
zv-…). Cada uno aplica el nivel baseline de Pod Security de Kubernetes, así que ninguna carga de trabajo puede ser privilegiada, usar la red del host ni montar directorios del host. - No puede leer secretos ni ejecutar comandos fuera de los espacios de nombres de los proyectos, cambiar sus propios permisos ni tocar los componentes de sistema de K3s (puede leer su estado).
- Una política de admisión de Kubernetes aplica estos límites; el agente no puede quitarla.
El contenedor del agente se ejecuta como usuario sin privilegios y con un sistema de archivos de solo lectura. Monta un directorio del host en solo lectura para informar del uso de disco de /var/lib/rancher/k3s.
Qué guarda Zenavo
- Un hash del token del agente. El token en sí solo existe en tu servidor.
- Una credencial de descarga del registro de imágenes que solo puede leer las imágenes de tu equipo.
Zenavo no guarda claves SSH, contraseñas ni credenciales del clúster de un servidor que funciona. La contraseña o clave SSH que introduces la usa la tarea de configuración y se borra en cuanto la configuración termina bien. Si falla, se guarda cifrada durante un día para que puedas reintentar sin volver a escribirla, y después se borra. La configuración no añade nada a ~/.ssh/authorized_keys.
Cuando quitas un servidor, Zenavo borra el token de su agente, así que el agente ya no puede conectar. K3s, el agente y tus datos se quedan en la máquina: ejecuta allí /usr/local/bin/k3s-uninstall.sh si ya no los necesitas.
Servidores añadidos antes del agente
A los servidores añadidos antes de que existiera el agente se llegaba por SSH con una clave que instalaba Zenavo, y por la API de Kubernetes con las credenciales de administrador de K3s. Zenavo los pasa al agente por su cuenta: instala el agente, quita la clave de Zenavo de ~/.ssh/authorized_keys y borra la clave y las credenciales guardadas. Settings → Connection muestra el estado y te permite iniciar el cambio en el momento. Si habías pegado una clave privada propia, quítala tú del servidor si ya no la usas. Después también puedes rotar los certificados de K3s con k3s certificate rotate (reinicia K3s), para que dejen de funcionar las credenciales de administrador que tuvo Zenavo.
Las compilaciones nunca se ejecutan en tu servidor
Las compilaciones de Git se ejecutan en las máquinas de compilación de Zenavo, que no tienen acceso al plano de control, a otros clientes ni a credenciales de la nube. Tu servidor solo descarga imágenes terminadas, fijadas a su digest.