Ansible: repositorios privados de git: reenvío de agente SSH frente a copia de clave SSH privada

Recientemente comencé a jugar con Ansible y parece muy agradable. No tengo mucha experiencia en DevOps y nunca tuve que manejar escenarios complejos. Comencé a crear mi libro de jugadas Ansible para reemplazar mi herramienta de implementación actual: Deployer PHP. Desafortunadamente, estoy atrapado en la clonación del repositorio de git. Ahora, sé que necesito una clave pública agregada para permitir el acceso al repositorio de git y aquí viene mi pregunta.

¿Debo usar el reenvío de agente SSH (de esta manera puedo usar mis claves SSH locales) o debo almacenar la clave SSH privada (encriptada, agregada al control de origen) dentro de mi proyecto ansible y copiarla usando Ansible en mi nodo objetivo? Sé que la pregunta puede ser muy amplia, así que lo que me interesa son las implicaciones de seguridad de ambos enfoques.

También puede considerar encriptar el archivo que contiene su clave SSH privada usando Ansible Vault.

Algunos enlaces:

http://docs.ansible.com/ansible/latest/playbooks_vault.html

https://therealmarv.com/ansible-vault-file-handling/

https://www.calazan.com/how-to-deploy-encrypted-copies-of-your-ssl-keys-and-other-files-with-ansible-and-openssl/

Si su repositorio de git es un github privado, puede usar los métodos de github (la implementación de claves es muy poderosa).

Si sus repositorios no están alojados en github o no proporcionan una función clave de implementación de solo lectura, las dos opciones que mencionó son valiosas.

Chico DevOps soltero

Si usted es la única persona que trabaja en el proyecto y su máquina / máquinas son las únicas desde las que podrá ejecutar (sin herramientas de CD como jenkins y amigos), puede usar la opción de reenvío de agente: es menos probable que usted olvida tu clave privada sin cifrar.

Pequeño equipo

Si usted es un equipo de personas que trabajan en el mismo libro de jugadas Ansible o varias personas que ejecutan el libro de jugadas, entonces tiene ambas opciones:

• mantener la opción de reenvío de agente; cada compañero de equipo ejecuta el script desde su máquina.

• cree un par de claves de despliegue, cargue la clave de publicación y cifre lo privado con bóveda como lo sugiere Berlin . La clave está encriptada y el alcance de la clave privada está restringido a solo 1 o pocos repositorios. El problema con este enfoque es que debe rotar la contraseña de la bóveda cada vez que un compañero de equipo abandona el equipo.

Nunca pondría mi clave privada personal, que tiene un amplio alcance, en un lugar posiblemente inseguro. El cifrado de bóveda es tan bueno como las personas que lo usan y hay muchas claves / contraseñas en texto claro :)

¿Debo usar el reenvío de agente SSH (de esta manera puedo usar mis claves SSH locales)

Sí, eso podría ser una opción.

¿Debo almacenar la clave SSH privada (encriptada, agregada al control de origen) dentro de mi proyecto ansible y copiarla usando Ansible en mi nodo de destino?

No

/server/823956/ansible-security-best-practices

Para los servidores, no permita el acceso de root a través de ssh. Muchas auditorías se burlan de esto.

Para ansible, deje que cada administrador use su propia cuenta personal en cada servidor de destino y déjelo sudo con contraseñas. De esta manera no se comparte contraseña entre dos personas. Puede verificar quién hizo qué en cada servidor. Depende de usted si las cuentas personales permiten iniciar sesión con contraseña, solo con clave ssh, o si requieren ambas.

En resumen, use una clave ssh con contraseña. Deje que cada usuario use sus propias claves ssh. Nunca permita el acceso a sudo a través de ssh.

Puede escribir su clave privada en una circunstancia: si configura su repositorio de modo que solo permita el acceso de lectura para esa clave en particular, y no se preocupe por la legibilidad pública del repositorio. En este caso, puede almacenar fácilmente su clave privada; obviamente, cree una clave desechable sin frase de contraseña. Pero como dije, solo si está bien con el acceso público a ese repositorio.

Si ese no es el caso, entonces probablemente esté atrapado con el agente SSH. No es ideal, ya que rootpuede tomar el zócalo, pero si se encuentra en una especie de entorno benevolente (es decir, no hay un servidor web atacable en ningún lugar cercano), entonces debería estar bien.