Cómo proteger datos confidenciales con Docker Compose Secrets

La gestión de secretos seguros es un aspecto importante de la seguridad de los contenedores. Si está inyectando contraseñas y claves API como variables de entorno, corre el riesgo de exposición de información no intencional. Las variables de shell a menudo se registran, se transmiten a procesos secundarios o se filtran a servicios de informes de errores sin su conocimiento.

Inyectar valores como secretos dedicados mitiga estos riesgos. Docker tiene soporte incorporado para la administración segura de secretos que puede conectar con Docker Compose. El acceso a los secretos se otorga por servicio.

¿Cómo funcionan los secretos?

La CLI de Docker tiene un lote de comandos de administración secretos, pero estos solo funcionan con clústeres de Swarm. No puede agregar secretos a contenedores independientes solo con la CLI de Docker.

Docker Compose agregó secretos "falsos" para llevar estas capacidades a las cargas de trabajo sin un clúster. La implementación de Compose funciona de manera similar a las características de Docker Swarm y funciona con cualquier archivo de Compose.

Los secretos se crean como archivos de texto normales que se montan en sus contenedores. Su aplicación accede al valor del secreto leyendo el contenido del archivo. Este modelo permite que los valores permanezcan inertes hasta que se usen explícitamente dentro de su contenedor, a diferencia de las variables de entorno visibles de forma permanente.

Definición de secretos en archivos de composición

Introducir un secreto en un contenedor es un proceso de dos pasos. Primero debe definir el secreto, utilizando los secrets de nivel superior campo en su archivo Compose. Luego actualiza sus definiciones de servicio para hacer referencia a los secretos que requieren.

Aquí hay un ejemplo que usa secretos para proporcionar una contraseña segura a un servicio:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - db_password
secrets:
    db_password:
      file: ./db_password.txt

El valor del secreto se leerá desde el db_password.txt de su directorio de trabajo archivo cuando ejecuta docker-compose up . Compose montará el archivo en /run/secrets/db_password dentro del contenedor. Su aplicación puede acceder a la contraseña de la base de datos leyendo el contenido del archivo secreto.

Uso de secretos de Docker existentes

Más allá de los secretos basados ​​en archivos, Compose también le permite hacer referencia a los secretos existentes de Docker Swarm. Si usa este mecanismo, debe crear los secretos en Docker antes ejecutas docker-compose up . Los docker secrets el espacio de comando solo funcionará cuando su punto final activo de Docker sea un nodo administrador de Swarm.

Cree el secreto mediante la CLI de Docker:

# take value from standard input
echo P@55w0rd | docker secret create db_password -
 
OR 
 
# take value from a file
docker secret create db_password ./db_password.txt

Ahora actualice su archivo Docker Compose para hacer referencia al secreto:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - db_password
secrets:
    db_password:
      external: true

Configuración del external del secreto El campo indica a Compose que obtenga su valor de sus secretos de Docker existentes. La pila fallará con un error si intenta iniciarla antes de que exista el secreto.

Sintaxis secreta extendida

Compose admite una sintaxis de secretos más larga si necesita un control más granular sobre el proceso de inyección. Cambiar a esta sintaxis le permite personalizar los permisos de archivos y cambiar el nombre montado del secreto.

Hay cinco campos opcionales disponibles:

• source – El nombre del secreto al que se hace referencia:debe ser uno de los valores definidos en los secrets de su archivo Compose. sección.
• target – Nombre de archivo que se usará cuando el secreto se monte en el contenedor.
• uid – UID para establecer en el archivo secreto montado. El valor predeterminado es 0.
• gid – GID para establecer en el archivo secreto montado. El valor predeterminado es 0.
• mode – Permisos del sistema de archivos para aplicar al archivo secreto montado, expresados ​​en notación octal. El valor predeterminado es 0444. Tenga en cuenta que los archivos secretos nunca se pueden escribir, ya que siempre se montan en el sistema de archivos temporal de un contenedor.

Aquí hay un ejemplo modificado que cambia el nombre del archivo secreto montado y cambia sus permisos:

version: "3"
services:
  app:
    image: example-app:latest
    secrets:
      - source: db_password
        target: database_password_secret
        mode: 0440
secrets:
    db_password:
      external: true

La sintaxis simple suele ser suficiente para la mayoría de las implementaciones. Si tiene requisitos más específicos, la versión extendida debería darle el control que necesita. Las referencias secretas individuales pueden mezclar y combinar las dos sintaxis dentro del mismo archivo Compose.

Secretos y autoría de imágenes

Muchas imágenes populares de Docker de la comunidad ahora admiten secretos en lugar de variables de entorno. Como autor de imágenes, ofrecer secretos es un enfoque de mejores prácticas para proteger los datos de sus usuarios.

Puede admitir ambos mecanismos al permitir que las variables de entorno se establezcan en una ruta de archivo. Si su imagen necesita una conexión a la base de datos, permita que los usuarios configuren la DB_PASSWORD variable de entorno a cualquiera de P@55w0rd o /run/secrets/db_password . Su contenedor debe verificar si el valor de la variable hace referencia a un archivo válido; si es así, deséchelo y lea el valor final del archivo.

Este modelo brinda a los usuarios la flexibilidad de elegir el mecanismo más apropiado para su implementación. Recuerde que no todos los usuarios podrán adoptar secretos:si Swarm y Compose no están disponibles, no tendrán forma de proporcionar sus valores.

Conclusión

El uso de secretos en lugar de variables de entorno regulares reduce los riesgos de divulgación de información no intencional. Imagine el peor de los casos en el que un contenedor envió sus variables de entorno a un servicio de registro de terceros comprometido. Los atacantes ahora tienen la contraseña de su base de datos y las claves API.

Al restringir los datos secretos al acceso al sistema de archivos, los valores no se pueden leer sin darse cuenta, ya que no son una característica perpetua de su entorno. Recuerde que los archivos secretos conllevan sus propios riesgos. Puede tener la tentación de enviarlos al control de código fuente, lo que significaría que cualquier persona con acceso a su repositorio podría leer sus valores.

Los secretos deben ser "secretos" durante todo el ciclo de vida de su contenedor. Para implementaciones de producción, generalmente es mejor automatizar compilaciones con un sistema CI. Establezca sus secretos en la configuración de canalización de su proveedor de CI, luego use su secuencia de comandos de compilación para escribirlos en archivos a los que puede acceder Compose. Esto garantiza que solo usted tenga acceso a los valores reales, a través de la interfaz de su herramienta de CI.