Ansible: cómo clonar un repositorio como otro usuario

Estoy tratando de escribir reglas de implementación con Ansible. Algunos de los pasos son:

1. Actualizar y actualizar el servidor
2. Crea un usuario llamado harry
3. Agregar claves públicas y privadas a harry
4. Clonar un repositorio Git de bitbucket.org

Quiero clonar el repositorio como harry usuario en su directorio de inicio (es por eso que estoy copiando sus claves públicas y privadas). El problema es que no es posible especificar un usuario con el que se debe ejecutar el clon de git. Entonces, Ansible intentó clonar el repositorio como raíz y falló porque no tiene derechos para acceder al repositorio.

Cómo resuelves esto ?

Según la documentación de Ansible en Escalada de privilegiosAnsible tiene limitaciones para convertirse en un usuario sin privilegios, ya que expone un agujero de seguridad a Harry.

Uso de Ansible git módulo, puede especificar usar la clave privada de Harry del usuario privilegiado de Ansible usando el key_file parámetro y usando become_user permite que los archivos clonados pasen a ser propiedad de Harry. Por ejemplo:

- name: Clone bitbucket repo
  git:
    repo: git@bitbucket.org:your-repo.git
    dest: /var/www/
    version: master
    accept_hostkey: yes
    key_file: /home/harry/.ssh/id_rsa
  become: yes
  become_user: harry

Puede especificar un usuario para cada tarea en su libro de jugadas:

- name: Clone bitbucket repo
  git: ...
  become: yes
  become_user: harry

Para más detalles ver Escalada de privilegios de Ansible.

Una alternativa más segura a colocar su clave privada en un servidor remoto es habilitar el reenvío de clave ssh en la configuración sshd en el servidor y su configuración ssh localmente. La llave nunca sale de su caja local.

sí, puedes hacer que funcione con el reenvío ssh

siempre que el usuario en el que te conviertas en el clon de git sea parte de sudoers, por lo que no necesita usar sudo para ejecutar git

Entonces, además de todas las configuraciones requeridas para el reenvío de claves, hay un truco que incluso se menciona en los documentos de Ansible. El proceso de alto nivel es el siguiente: habilite el reenvío de agentes en la máquina de control habilite la aceptación de la clave del agente en la máquina de destino cree un usuario y agréguelo (o ella:) al grupo sudoers use el módulo git de ansible para clonar el repositorio, conviértase en: su-usuario-sudoer

Además, para evitar cualquier permiso denegado en el host, simplemente clónelo en ~/algo. Siempre puede copiar o vincular a cualquier lugar que desee.

aquí está el enlace donde se muestra la parte del libro de jugadas para agregar usuarios a sudoers, es básicamente copiar y pegar: Ansible: cree un usuario con privilegios sudo

Funciona de maravilla

Además, asegúrese de agregar su clave pública SSH en la configuración general de BitBucket, no en el por proyecto. De lo contrario, su clave ssh solo funcionará en un repositorio específico. Pero si agrega la clave ssh en la configuración general de bitbucket, funcionará en todos sus repositorios

a continuación se muestra el código que lo hace funcionar, el usuario suduer es “implementador”

# the tasks to CREATE A SUDOER GROUP


- name: Make sure we have a 'wheel' group
    group:
      name: wheel
      state: present
    become: yes

  - name: Allow 'wheel' group to have passwordless sudo
    lineinfile:
      dest: /etc/sudoers
      state: present
      regexp: '^%wheel'
      line: '%wheel ALL=(ALL) NOPASSWD: ALL'
      validate: 'visudo -cf %s'
    become: yes

  - name: Add sudoers users to wheel group
    user: name=deployer groups=wheel append=yes state=present createhome=yes
    become: yes


 # tasks to ADD REPO with Ansible's GIT MODULE
  - name: Add  Git Repo - BitBucket 
    git:
      repo: 'git@bitbucket.org:<your_username>/<your_repo>.git'
      dest: ~/code  # note this destination, you will avoid permissions issues
      accept_hostkey: yes # btw, this is for the ssh key forwarding
      recursive: no
    become: deployer # this guy (or gal) is a sudoer by now

# “Truco” adicional para cambiar los permisos en archivos Y carpetas de una sola vez, tiene que ver con la X mayúscula y a qué se aplica y qué no. También recogido de otro stackoverflow

- name: Set perms on new Code repo to deployer:deployer dirs-0755 and files-0644
    file:
      path: ~/code
      state: directory
      owner: deployer 
      group: deployer 
      mode: u=rwX,g=rX,o=rX
      recurse: yes
    become: yes

Sí, con el reenvío ssh funciona. Si su libro de jugadas se ha “convertido en: sí” activado globalmente, asegúrese de desactivarlo para la tarea de git. La razón por la que no funciona cuando se ha “convertido en: sí” es porque la escalada de privilegios de raíz destruye el reenvío ssh. No creo que necesites convertirte en sudoer. Porque si su máquina de control Ansible se autentica con Bitbucket usando la clave ssh (usted agrega la clave ssh en el repositorio), esta autenticación se pasa a través del reenvío de ssh. Puede probarlo mediante ssh en su destino y emitiendo “ssh -T git@bitbucket.org”. Verá en el resultado que Bitbucket acepta el destino como el usuario de la máquina de control de Ansible. Así que simplemente ejecute la tarea con explícito “convertirse en: no”. Estoy de acuerdo con la clonación en ~/algo en el objetivo. De lo contrario, causará problemas de permisos.
[Edit: one more thing to make it work – ⁃ Repo URL should be the ssh one not https one, without ssh:// (despite what is written in the Ansible Manual examples)]
En cuanto a la seguridad, como se mencionó anteriormente, el reenvío ssh es el mejor.

Simplemente podemos hacer que el usuario Harry (www-data en mi ejemplo) accesible por ssh con las mismas claves_autorizadas que el raíz. No será problema de seguridad, si puedes conectarte a raíz puedes hacer más de todos modos si te conectas como Harry.

remote_user: root
tasks:
  - name: Create /var/www/.ssh
    file:
      state: directory
      owner: www-data
      group: www-data
      path: /var/www/.ssh
      mode: 0700

  - name: Copy authorized_keys to www-data
    copy:
      remote_src: yes
      src: ~/.ssh/authorized_keys
      dest: /var/www/.ssh/
      mode: 0400
      owner: www-data

  - name: Ensure www-data has shell
    lineinfile:
      path: /etc/passwd
      regexp: '^www-data:'
      line: 'www-data:x:33:33:www-data:/var/www:/bin/bash'

  - name: chown -R www-data /var/www
    file:
      owner: www-data
      path: /var/www
      recurse: yes

  - name: Git checkout application
    git:
      repo: git@gitlab.com:harry/project.git
      dest: "/var/www/project_root_dir"
      accept_hostkey: yes
    remote_user: www-data