Docker Secrets: diferencias entre Swarm y Compose
Las credenciales no deben quedar copiadas dentro de imágenes o repositorios. Docker ofrece mecanismos para entregarlas a servicios, pero es importante distinguir secretos de Swarm de archivos declarados por Compose.
Cambiar una variable de entorno por un archivo no crea automáticamente cifrado y control de acceso completos. Evalúa almacenamiento, permisos y consumidores.
Secretos de Swarm
Swarm administra secretos para servicios con un modelo propio de distribución y protección. Debes tener un clúster autorizado y acceso al manager correspondiente.
Puedes crear un secreto desde un archivo privado:
docker secret create db_password_v1 ./secrets/db_password.txt
docker secret lsEl archivo debe existir y estar protegido. No utilices una contraseña real escrita en un echo que permanecerá en el historial.
Asigna el secreto únicamente a los servicios que lo necesitan y comprueba su ubicación de lectura según la plataforma.
Archivos en Compose
Un ejemplo para PostgreSQL:
services:
db:
image: postgres:16
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
volumes:
- db_data:/var/lib/postgresql/data
secrets:
db_password:
file: ./secrets/db_password.txt
volumes:
db_data:La imagen debe soportar la variable _FILE específica. No es una convención que cualquier aplicación interprete automáticamente.
En Compose sin Swarm, el archivo local sigue existiendo y requiere permisos y tratamiento de respaldo adecuados. No atribuyas a ese caso todas las garantías de un secreto administrado por Swarm.
Preparación y permisos
Genera material aleatorio mediante una herramienta apropiada y conserva la carpeta fuera de Git. Ajusta propietario y acceso para que el usuario del proceso pueda leerlo sin abrirlo a todos.
Un archivo privado que el contenedor no puede leer no se arregla necesariamente con chmod 777. Identifica UID, GID y modelo de mounts de la plataforma.
Lectura en la aplicación
Configura una ruta explícita y maneja el error cuando el archivo falte. No imprimas el valor para demostrar que se cargó.
Si eliminas saltos de línea, hazlo solo cuando el formato del secreto lo permita. Un trim genérico puede modificar un valor donde los espacios son significativos.
Rotación real
Crear un archivo nuevo o actualizar una variable no cambia automáticamente la contraseña de una base ya inicializada. Debes coordinar el sistema que valida la credencial y sus consumidores.
En Swarm, utiliza nombres versionados o el procedimiento compatible para reemplazar un secreto. Comprueba el servicio antes de retirar la versión anterior.
Qué todavía debes proteger
Los administradores del host, el acceso a Docker, los backups y herramientas de diagnóstico pueden formar parte de la superficie de exposición. Revisa también permisos de CI/CD.
Si un secreto se publicó, retirarlo del archivo actual no deshace la exposición. Revócalo y revisa dónde pudo conservarse, incluidos commits y artefactos.
Preguntas frecuentes
¿Un archivo secreto de Compose queda cifrado automáticamente?
No debes asumirlo. Revisa el mecanismo de la plataforma y protege el archivo y sus copias.
¿Cualquier variable con sufijo _FILE funciona?
No. La imagen o aplicación debe implementar esa lectura; consulta su documentación.
¿Cambiar el archivo rota la contraseña de MySQL o PostgreSQL?
No de forma general. Las variables de inicialización y la administración de una cuenta existente son procesos distintos.
En pocas palabras
Swarm y Compose pueden entregar secretos como archivos, pero sus garantías no son iguales. La aplicación debe leerlos correctamente y el host y sus respaldos siguen necesitando protección.
Conclusión
Identifica quién puede leer cada secreto y prueba su rotación con una aplicación de laboratorio. Retira credenciales antiguas solo después de verificar que los consumidores utilizan las nuevas.
Para continuar, revisa Docker: qué es y cómo usarlo para ejecutar contenedores y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.