Ejecutar Docker de forma segura en un Unmanaged VPS empieza antes del primer `docker run`. Hay que preparar el host, controlar el origen de las imágenes, proteger los secrets y evitar privileges innecesarios. El aislamiento de contenedores ayuda, pero no sustituye la seguridad del host.
Preflight - prepara primero el host
- mantén Linux y Docker Engine actualizados;
- usa SSH keys y una política clara de firewall;
- expón solo los ports necesarios;
- incluye los persistent volumes en el plan de backup;
- configura log rotation y disk monitoring.
la guía sobre seguridad del hosting aporta el contexto de defense-in-depth. Para controles del host consulta la guía de herramientas de administración del servidor.
Trata las imágenes como dependencias
Utiliza registries o publishers de confianza. Fija versions o digests cuando la reproducibilidad sea importante. Evita construir el proceso de producción alrededor de un tag flotante `latest`.
Privileges que conviene evitar por defecto
- `--privileged`;
- montajes amplios del filesystem del host;
- Docker socket dentro de un contenedor normal;
- secrets dentro de la imagen;
- host networking solo por comodidad.
Compose no sustituye una política operativa
Docker Compose describe services, networks y volumes. Monitoring, backups, update cadence, log retention y rollback siguen siendo procesos independientes.
Mapa de exposición pública
| Service | Public? | Modelo habitual |
|---|---|---|
| Reverse proxy | sí | 80/443 |
| Application container | normalmente no | internal Docker network |
| Database | normalmente no | private/internal network |
SERVER1 Unmanaged VPS encaja cuando necesitas control completo del Docker host. Para opciones generales de VM consulta SERVER1 VPS. Si prefieres un servicio gestionado, confirma antes si Docker está incluido en el support scope.
La contenerización simplifica el packaging y el deployment, pero no gestiona por ti la seguridad ni la recuperación del host.
Threat model: ¿quién puede controlar el Docker daemon?
Docker daemon es un componente con privilegios muy elevados. Quien puede controlarlo puede crear containers, montar rutas del host y realizar otras operaciones potentes. Añadir un usuario al grupo `docker` no es solo una comodidad: es una decisión de seguridad.
¿Cuándo merece la pena Rootless Docker?
Rootless mode ejecuta daemon y containers dentro de un non-root user namespace, reduciendo privilegios a nivel del host. No es automáticamente adecuado para cualquier workload: valida networking, low ports, storage drivers y compatibilidad de tooling. Puede ser especialmente interesante en developer o staging.
Secrets: una environment variable no siempre es la respuesta definitiva
No incluyas secrets dentro de las imágenes ni en el repositorio. Utiliza un mecanismo de secrets en runtime o un archivo externo con permisos mínimos. Ten en cuenta que environment variables pueden aparecer accidentalmente en herramientas de debugging u operación.
Una image no es un backup
| Qué debe recuperarse | Fuente de recuperación |
|---|---|
| Application image | registry/build pipeline |
| Persistent database data | backup probado |
| User uploads | volume/object-storage backup |
| Compose/config | version control / secure config store |
| Secrets | proceso independiente de secret management |
Update runbook: “pull y restart” es demasiado poco
- revisa changelog y security notes de la image;
- haz backup del state que no puedas recrear;
- prueba la nueva image en staging;
- valida health checks y migrations;
- tras production deploy, observa logs, restart count y latency;
- mantén la image o digest anterior para rollback rápido.
