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

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.

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.

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í.

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.

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 ...