Cómo configurar secretos de Docker sin almacenarlos en archivos Compose

Mantén los valores secretos fuera de Compose y del control de versiones; móntalos como archivos con responsables distintos para su creación, rotación y recuperación.

Esto es importante en una infraestructura doméstica donde la contraseña de la base de datos, el token de API o la clave TLS están actualmente incluidos en el YAML o en un bloque de variables de entorno. El riesgo operativo es que eliminar un valor de Compose no sirve de nada si el archivo secreto tiene permisos de lectura para todo el mundo, se copia indiscriminadamente en las copias de seguridad o queda expuesto en los registros. Empieza con una configuración de referencia guardada, realiza un cambio reversible a la vez y detente siempre que el estado observado ya no coincida con la ruta de configuración prevista.

Establece la configuración de referencia de Docker Compose Secrets

Antes de cambiar los ajustes, registra el historial del repositorio, los permisos de los archivos, los montajes de los contenedores, el entorno de los procesos, la antigüedad de la rotación y el acceso de recuperación. Guarda la configuración original y una ejecución representativa de producción para comparar las mejoras posteriores con la misma carga de trabajo, en vez de basarte en la memoria o en un estado sintético de inactividad.

Usa el flujo de trabajo de secrets de Compose actual para confirmar el control admitido y su semántica. Considera los valores predeterminados como un punto de partida conocido, no como prueba de que el ajuste sea adecuado para este servidor, la combinación de clientes o el objetivo de recuperación.

Define los criterios de aceptación y las condiciones de detención antes de editar. La señal de aceptación debe ser visible en los registros, el estado del protocolo, la salida de la aplicación o los datos restaurados; la condición de detención debe impedir un acceso más amplio, la pérdida de datos, el agotamiento de recursos o una interrupción que consuma la siguiente ventana de recuperación.

Aplica el cambio de Secrets de Docker Compose en etapas controladas

Paso 1: Crea un archivo secreto, propiedad de root o del servicio, fuera del directorio del proyecto y restringe sus permisos. Tras el cambio, inspecciona inmediatamente el estado esperado; si no aparece, deshaz este paso antes de aplicar el siguiente.

Paso 2: Declara el archivo en la sección top-level secrets y concédelo solo a los servicios que lo necesiten, usando la convención _FILE de la aplicación cuando esté disponible. Tras el cambio, inspecciona inmediatamente el estado esperado; si no aparece, deshaz este paso antes de aplicar el siguiente.

Paso 3: Rota un secreto a la vez y conserva una ruta de recuperación de emergencia probada que no vuelva a incluir valores en YAML. Después del cambio, inspecciona de inmediato el estado esperado; si no aparece, revierte este paso antes de aplicar el siguiente.

secrets:
  db_password:
    file: /srv/secrets/db_password
services:
  db:
    secrets: [db_password]

Interpreta las ramas de resultado satisfactorio, fallo y excepción

Es un resultado satisfactorio si el valor no aparece en Compose, el control de versiones, las variables de entorno inspeccionables ni los contenedores no relacionados. Registra la carga de trabajo exacta, la versión y el momento en que se obtuvo el resultado; una prueba más ligera no demuestra que el problema original se haya resuelto.

Es un fallo si la aplicación muestra el secreto, no puede volver a cargarlo o una copia de seguridad amplia y un recurso compartido exponen el archivo de origen. No intentes compensarlo debilitando todos los controles cercanos. Vuelve a la última configuración de referencia limpia y determina si la discrepancia corresponde a la identidad, la red, el almacenamiento, la disponibilidad de la aplicación o la capacidad.

Ante una excepción o un resultado ambiguo, revoca el nuevo valor, restaura el secreto anterior mediante el mismo canal protegido y elimina las copias filtradas del historial. Escala el problema solo después de que la prueba de bajo riesgo pueda repetirse y las pruebas demuestren que es necesario un cambio más profundo en la plataforma o el hardware.

Featured

NAS personal en la nube para el hogar ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifica la persistencia bajo la carga original del servidor doméstico

Repite la misma ruta del cliente, el tamaño del archivo, la concurrencia, el evento de suspensión o reinicio y la carga de trabajo simultánea que se usaron en la prueba de referencia. Ejecuta al menos dos ciclos para no confundir un éxito con la caché caliente, una reconexión afortunada o un único inicio limpio con la persistencia.

Confirma tanto el éxito como la contención: el valor no aparece en Compose, el control de versiones, las variables de entorno inspeccionables ni los contenedores no relacionados, mientras que los usuarios, servicios, recursos compartidos y rutas administrativas no relacionadas conservan su comportamiento original. Revisa el flujo de trabajo relacionado de ZimaSpace cuando el cambio afecte a un límite cercano de almacenamiento, red o recuperación.

Finaliza el cambio solo cuando la señal de aceptación persista y la reversión siga siendo viable. Si la aplicación muestra el secreto, no puede volver a cargarlo o una copia de seguridad y un recurso compartido amplios exponen el archivo de origen, detén la automatización, conserva los registros y la configuración guardada, y vuelve al último estado verificado en lugar de acumular más cambios.

Preguntas frecuentes sobre la ramificación de consultas, decisión final y prueba final

Estas preguntas sobre la ramificación de consultas abarcan las siguientes decisiones que los usuarios suelen buscar cuando la configuración principal ya funciona. Amplían el alcance sin introducir una vía de reparación que no se haya probado.

Aplica cada respuesta solo cuando su condición coincida con el entorno medido. Las diferencias de versión, protocolo, sistema de archivos, cliente y límite de confianza pueden cambiar cuál es la opción correcta.

Guarda las respuestas junto con el manual de operaciones y actualízalas después de las actualizaciones o los cambios de topología. Toda excepción que amplíe los permisos de escritura, el alcance de la red o la autoridad para eliminar requiere una nueva prueba de reversión y recuperación.

¿Se cifran en reposo los secretos de los archivos Compose?

No necesariamente. En Compose local, lo habitual es montar un archivo protegido mediante un enlace, por lo que los permisos y los controles de almacenamiento del host siguen siendo importantes.

¿Son aceptables las variables de entorno para los secretos?

Son cómodas, pero es más fácil exponerlas mediante la inspección, la depuración y los procesos secundarios. Si la aplicación lo admite, es preferible usar archivos como entrada.

¿Cómo se deben respaldar los secretos?

Usa un paquete de recuperación cifrado por separado, con acceso restringido, inventario de versiones y un proceso de restauración probado.

Conclusión: La configuración está completa cuando el valor no aparece en Compose, el control de versiones, las variables de entorno inspeccionables ni los contenedores no relacionados, se comprende la rama de fallo y la reversión documentada no depende del componente que se está modificando.

Protocolo de prueba final: restaura la línea base guardada, aplica una vez el cambio aprobado, repite la carga original similar a la de producción, verifica la señal de éxito y el límite de contención, y luego prueba la reversión con datos desechables. Conserva el cambio solo si coinciden las cinco observaciones.