git - ¿Cómo gestionar secretos en un entorno Microservice/Container/Cloud?

docker microservices

Question

Microservicios y Cloud es una cosa. Todo el mundo está hablando y escribiendo. Personalmente estoy pensando mucho en estos temas: ¿Cómo se puede usar esto para beneficiarnos? ¿Cuáles son los posibles desafíos? ¿Cómo puede esto acelerar el desarrollo diario? ¿Y cómo manejar todas las cosas? Una pregunta que me molesta desde hace unos días es "¿Cómo gestionar los secretos en un entorno de microservicio / nube?".

Imagine una empresa con 150 ingenieros de software y varios equipos con diversos productos. Cada equipo está creando un software y cada servicio necesita varias cantidades de secretos (API-Keys, Passwords, SSH-Keys, lo que sea). La forma "antigua" era crear unos cuantos archivos de configuración en formato ini / yaml / txt y leerlos desde. 12Factoras aplicaciones dicen: Hazlo por env vars.

Las variables env se pueden configurar por máquina y los archivos de configuración también se pueden colocar allí. Esto funciona si tiene una mano llena de máquinas y la implementación se realiza por unos pocos administradores del sistema. Una de las reglas generales dice: "No guarde secretos en un repositorio de Git".

Ahora llega el nuevo mundo. Cada equipo es responsable de la aplicación que producen. Deben ser desplegados y ejecutados por el equipo. Así que nuestra empresa se está moviendo hacia un contenedor y un modo de autoservicio (por ejemplo, Mesos y Marathon o Kubernetes).

Por supuesto, Dockerfiles también puede establecer env vars. Y sí, puede agregar su archivo de configuración en el contenedor de Docker durante la compilación. Pero con esto, todos pueden acceder a los secretos (por ejemplo, de otros equipos). Y nadie sabe quién usa estos secretos y hace algo peligroso.

También quieres versionar tus Dockerfiles. Y las aplicaciones que desea ejecutar en Marathon también deben ser versionadas (Git o lo que sea) (y deben ser aplicadas por la API REST). Entonces, ¿dónde almacenar y administrar todos los secretos de estos contenedores / aplicaciones? Porque con los frameworks de planificación como Swarm and Machine (para Docker), Mesos y Marathon (que también se pueden usar para Docker) o Kubernetes, no sabes dónde se ejecutará tu aplicación. Esto será programado en varias máquinas. Y la mayoría de estas herramientas no tienen autenticación (de manera predeterminada, esto puede agregarse mediante un proxy Nginx o algo así).

Una idea para administrar secretos es usar una herramienta como Vault . Pero nunca vi soporte "nativo" en una aplicación. Lo mismo se aplica para Blackbox . Y no sé cómo la gestión de la configuración puede resolver esto. Sé que Chef es compatible con las bases de datos cifradas, pero afaik no es posible utilizar Chef para configurar / construir contenedores Docker.

¿Cómo gestiona los secretos en un entorno de varios equipos con varios ingenieros en un entorno Microservice / Container / Cloud?

Answer 1

Hay varias soluciones.

Primero, NO pongas tus secretos en la imagen. Eso es solo una mala idea, como te habrás dado cuenta. Si no agrega sus secretos en tiempo de construcción, debe hacerlo en tiempo de ejecución. Esto nos deja con algunas opciones:

• Utilice las variables de entorno como lo sugiere la aplicación 12 Factor . A continuación, deberá escribir un script que rellene los archivos de configuración con los valores de estas variables cuando se inicie el contenedor. Esto funciona, pero realmente no me gusta, ya que las variables de entorno se filtran fácilmente (se pueden ver en contenedores vinculados e docker inspect y a menudo se incluyen en los informes de errores). También vea Summon .

• Utilizar volúmenes. Simplemente monte el archivo de configuración con los secretos en tiempo de ejecución. Esto funciona, pero significa que tienes un archivo con los secretos que se encuentran en el host. Esto se vuelve más complicado cuando no sabe en qué host se ejecutará su contenedor, como cuando se utilizan marcos como Swarm y Mesos.

• Utilice una tienda segura de k / v como Vault / Keywhiz . Como señala, deberá realizar algunas secuencias de comandos para introducir los valores en la aplicación (como ocurre con las variables env). También debe autenticarse en la tienda k / v de alguna manera (es posible que desee ver los controladores de volumen para Keywhiz y Vault , o usar un token de un solo uso que se pasa a través de una variable de env).

Kubernetes ya cuenta con un respaldo bastante avanzado para los secretos , y espero ver que otros marcos adopten sus propias soluciones.