Dónde poner la contraseña de ansible-vault

26

Estamos planeando usar la bóveda ansible en nuestro proyecto para evitar fugas de contraseñas o claves en git.

La idea es poner todos nuestros datos confidenciales en un archivo simple y luego cifrar este archivo con ansible-vault usando una contraseña antes de presionar para git.

Para descifrar el archivo, tenemos que pasar la contraseña de la bóveda a ansible, estoy pensando en 3 posibilidades:

  • Almacénelo dentro de una variable de entorno del servidor
  • Pásalo como una opción para el comando ansible-playbook
  • Almacénelo en un archivo no versionado.

¿Hay alguna otra opción, que es la mejor (y segura) forma de almacenar la contraseña de Ansible-Vault? La documentación de las mejores prácticas de Ansible no dice nada al respecto.

tormenta
fuente
Charla muy relevante: danielsomerfield.github.io/turtles
Xiong Chiamiov
Aquí hay algunas buenas respuestas: devops.stackexchange.com/questions/3806/…
Visite el

Respuestas:

13

La idea es poner todos nuestros datos confidenciales [...]

El significado de "todos" en esta oración debe analizarse con mucho cuidado antes de implementar la solución que planea.

Ansible vault es una herramienta muy útil, pero solo debe usarse para almacenar secretos que son:

  1. Específicamente necesario para los despliegues ansibles
  2. Fácilmente inutilizable para los propietarios que deben ignorarlos, pero que pueden "recordarlos" de manera ilegítima (por lo general, empleados que no han sido abordados)

El segundo punto es crítico.

Muchas personas, y potencialmente todo el equipo de DevOps, tendrán acceso a la contraseña de la bóveda ansible y, por lo tanto, a todos los secretos.

Por lo tanto, para todos los secretos almacenados en la bóveda, debe cumplirse una condición por la cual una persona o máquina con acceso no autorizado a ellos debe ser incapaz de hacer uso de ellos si así lo desea.

En términos concretos, si usa ansible para implementar una base de datos y sus usuarios, puede almacenar las contraseñas en la bóveda, pero tendrá que tener mucho cuidado (y probablemente considerar otra solución) si ese servicio estará disponible en Internet. y sin la necesidad de ninguna autenticación VPN!

Los usuarios (DevOps) expuestos al secreto, deben ser incapaces de usar contraseñas "recordadas" si se les impone una barrera de seguridad (por ejemplo, se revocó el acceso VPN). Además de esto, el acceso al repositorio de código fuente (donde se almacena la bóveda) también debe ser revocado antes de cambiar las contraseñas.

En estas condiciones, la bóveda ansible es una herramienta muy útil.

Intentar almacenar un secreto que podría ser utilizado por cualquier persona o máquina en Internet en la bóveda sería, en cambio, un error (por ejemplo, las credenciales de VPN de los usuarios).

¿Hay alguna otra opción, que es la mejor (y segura) forma de almacenar la contraseña de Ansible-Vault

Bajo las condiciones del párrafo anterior, creo que una buena práctica sería:

  1. Almacene la contraseña de la bóveda en una bóveda segura externa (algo como Vault de HashiCorp o cualquier SaaS para la gestión de credenciales)
  2. Permita el acceso al elemento de la bóveda externa a DevOps (necesitarán la contraseña para la prueba) y el sistema CI / CD o el controlador ansible
  3. ¡Mantenga una convención para usar secretos ! ¡No podrá revisar los cambios en los secretos y no podrá buscar variables ansibles en los archivos de secretos! Así que sé minucioso desde el principio. Una buena convención es nombrar todas las variables almacenadas en la bóveda ansible con un secret_prefijo. Cuando veas algo como:

    postgres.yml:

    postgres_password: "{{ secret_postgres_password }}"
    

    sabrá que el valor se almacena en la bóveda ansible.

Vincenzo Pii
fuente
1
Un buen punto sobre el almacenamiento de la contraseña de Ansible Vault en un lugar más seguro (HashiCorp Vault o SaaS Vault, como AWS Secrets Manager). Sin embargo, aún debe rotarse (cambiarse) si alguien deja el equipo, ya que han tenido acceso a él aunque sea brevemente. Esto puede mitigarse quizás mediante el uso de bóvedas separadas (dev, prueba, producción), es decir, archivos secretos en YAML. Ansible 2.4+ también le permite especificar diferentes contraseñas para dichos archivos utilizando una 'ID de bóveda' - página de documentos
RichVel
1
Ansible 2.3 introdujo una función que encripta solo los valores en los archivos YAML, no todo el archivo; esto es más simple de mantener que la convención anterior que menciona en el punto 3 al final de esta respuesta.
RichVel
7

Estamos planeando usar la bóveda ansible en nuestro proyecto para evitar fugas de contraseñas o claves en git.

Como todavía no ha implementado nada, puede reconsiderar esto. El uso de un sistema como la bóveda Ansible tiene varios inconvenientes de seguridad:

  • no hay seguimiento de auditoría de quién ha accedido
  • cuando un empleado se va, es fácil para ellos llevarse la tienda secreta con ellos
  • cuando un empleado se va, eliminar su acceso significa cambiar la contraseña y redistribuirla a todos los demás
  • una contraseña de bóveda Ansible comprometida se puede usar para siempre en una versión anterior de la bóveda, como se almacena en el control de versiones
  • los secretos tienen que ser estáticos

Un sistema potencialmente mucho más seguro, aunque más complejo, que no tiene estos inconvenientes es utilizar Hashicorp Vault para almacenar sus secretos. A continuación, puede extraer valores de ella casi tan fácilmente como desde la bóveda Ansible utilizando https://github.com/jhaals/ansible-vault .

Sin embargo, debe administrar la autenticación en Hashicorp Vault, y esa es la pregunta de la tortuga . Para los humanos, creo que la mejor solución es solicitar una contraseña periódicamente y expirar el token después de un corto período de tiempo; para máquinas, para utilizar el servidor de autenticación de AWS o similar. Nunca puede deshacerse por completo de la necesidad de autenticación en alguna parte, pero puede dificultar que un atacante obtenga acceso a ella.

Ahora, si configurar y administrar un servidor de secretos es demasiado para usted, entonces ciertamente puede usar el almacén de Ansible. Sin embargo, ¿por qué almacenar la contraseña en las máquinas individuales? Para uso interactivo, solo puede solicitar la contraseña y los usuarios pueden almacenarla en el administrador de contraseñas de su elección. iTerm en OS X tiene un administrador de contraseñas que se integra con Keychain.app que lo hace particularmente fácil allí.

Xiong Chiamiov
fuente
2
La mejor manera de usar Ansible Vault es no usarlo. ¡Gracias por señalarlo!
tormenta
1
Para organizaciones pequeñas y medianas, recomendaría buscar un administrador de secretos basado en la nube como AWS Secrets Manager: esto es mucho menos trabajo que ejecutar un clúster altamente disponible para HashiCorp Vault, pero una gran mejora en la seguridad que obtienes con Ansible Vault, incluida la auditoría y el control de acceso granular. Por supuesto, terminas dependiendo de ese servicio, pero eso se puede encapsular con un poco de codificación de aplicaciones y trabajo de Ansible. El principal beneficio es que algunos secretos no necesitan ser administrados por Ansible en absoluto, por ejemplo, contraseñas de base de datos: solo deje que la aplicación obtenga secretos del administrador de secretos.
RichVel
3

Esto va bastante a las políticas internas que tiene sobre el manejo de datos confidenciales.

Me gustaría contarles mi enfoque sobre esto y explicar lo que veo como pros y contras. Mantengo la contraseña de Ansible Vault en un archivo en la máquina de control y tengo una variable de entorno apuntando a ella:

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

Lo tengo en mi estación de trabajo (ya que necesito probar y desarrollar libros de jugadas), algunos colegas también lo tienen y, por supuesto, lo tenemos en la máquina de control Ansible principal.

Pros:

  • no en una ubicación / repositorio compartido (es un archivo no versionado como usted dice)
  • uno no necesita saber su contraseña de bóveda Ansible para ejecutar una jugada (esto es bajo la condición de que tenga una herramienta de CI, por ejemplo, Jenkins, donde puede lanzar fácilmente libros de jugadas)

Contras:

  • no es fácil rotar la contraseña
  • todos los que trabajan en sus libros de jugadas deben tenerlo en su estación de trabajo

Los contras tienen mitigaciones, pero nuevamente depende de las políticas y reglas que ha adoptado en sus operaciones diarias.

13dimitar
fuente
1
Buena combinación ... verifique la otra respuesta, aunque puede ser de su interés.
tormenta
0

Eche un vistazo a este proyecto para administrar sus contraseñas de cifrado de bóveda ansible https://github.com/Smile-SA/ansible-vault-manager

Maneja múltiples plataformas de almacenamiento de llavero con complementos (por ahora solo se implementa AWS SSM). La integración de Morehover con un proyecto Ansible actual es muy fácil ...

gillg
fuente
Ayudaría si hace que lo más fácil sea más concreto en lugar de agregar algo genérico. Leí el archivo README de la página de github, pero ¿podría cambiar la respuesta para que contenga un ejemplo claro? Me gustaría probarlo.
030