Usuarios

Este rol de Ansible gestiona cuentas de usuario y controla su acceso con claves SSH.

Se utiliza para desplegar una o más aplicaciones en un servidor. Soporta la creación de cuentas para desplegar y ejecutar la aplicación, así como cuentas para administradores de sistema y desarrolladores.

Básicamente, es un envoltorio opinado sobre el Módulo de usuario de Ansible.

Tipos de usuario

El rol permite crear los siguientes tipos de cuentas de usuario:

• Administradores de sistema globales / equipo de operaciones

Estos usuarios tienen sus propias credenciales en el servidor con permisos sudo. Los añadimos al grupo wheel o admin, y luego les permitimos ejecutar sudo sin necesidad de contraseña.

Cuando provisionamos un servidor, creamos automáticamente cuentas para nuestro equipo de administración de sistemas, independientemente del proyecto.

• Administradores de proyecto / usuarios avanzados

Estos usuarios tienen los mismos derechos que los administradores globales, pero se configuran en base a proyectos o servidores, controlados con variables de grupo / hosts de inventario. Normalmente, el líder técnico del proyecto sería un administrador.

• Cuenta de despliegue

Esta cuenta se usa para desplegar la aplicación en el servidor. Posee los archivos de software de la aplicación y tiene permisos de escritura en los directorios de despliegue y configuración.

Las cuentas de aplicación y de despliegue no tienen permisos sudo, aunque podemos hacer una regla en /etc/sudoers.d/ para permitirles ejecutar comandos, por ejemplo, reiniciar la aplicación con systemctl. Esto lo maneja el rol que instala y configura la aplicación, no este rol.

Por ejemplo, crea un archivo como /etc/sudoers.d/deploy-foo:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl start foo, /bin/systemctl stop foo, /bin/systemctl restart foo, /bin/systemctl status foo

• Cuenta de aplicación

La aplicación se ejecuta bajo esta cuenta de usuario.

Esta cuenta tiene acceso de escritura a los directorios que necesita durante la ejecución, por ejemplo, para los logs, y tiene acceso de solo lectura a su código y archivos de configuración.

• Desarrolladores

Los desarrolladores pueden necesitar acceder a la cuenta de usuario de despliegue o de aplicación para ver los logs y depurarlos. Añadimos las claves SSH de los desarrolladores a las cuentas, permitiéndoles iniciar sesión a través de SSH.

• Usuarios de proyecto

Estos usuarios son como los administradores, pero no tienen permisos sudo. Un ejemplo podría ser una cuenta para que un cliente pueda iniciar sesión y ejecutar consultas en la base de datos, pero no necesitan derechos de administrador. Puedes darles permisos para, por ejemplo, acceder a los archivos de logs de la aplicación añadiéndolos al grupo de la aplicación y configurando los permisos de archivo.

Configuración

Por defecto, este rol no hace nada. Necesitas añadir variables de configuración para que realice alguna acción. Normalmente, eso sería a través de variables de grupo, por ejemplo, inventory/group_vars/app_servers, una sección vars en un playbook, o una combinación de ambas.

Puedes tener configuraciones diferentes a nivel de host o grupo para, por ejemplo, dar acceso de inicio de sesión a los desarrolladores en el entorno de desarrollo pero no en producción.

Cuentas de aplicación

La cuenta que despliega la aplicación. Opcional, si no se especifica, la cuenta de despliegue no se creará.

users_deploy_user: deploy
users_deploy_group: deploy

La cuenta que ejecuta la aplicación. Opcional, si no se especifica, la cuenta de la aplicación no se creará.

users_app_user: foo
users_app_group: foo

Cuentas de usuario

users_users define los nombres de las cuentas Unix y las claves SSH para los usuarios.

Es una lista de diccionarios con cuatro campos:

• user: Nombre de la cuenta Unix
• name: Nombre del usuario. Opcional, para documentación.
• key: archivo de clave pública SSH. Colócalos en, por ejemplo, el directorio files de tu playbook.
• github: ID de GitHub del usuario. El rol obtiene las claves del usuario de https://github.com/{{ github }}.keys

Ejemplo:

users_users:
  - user: jake
    name: "Jake Morrison"
    github: reachfh
  - user: ci
    name: "Servidor CI"
    key: ci.pub

Listas de usuarios

Después de definir las cuentas de usuario en users_users, configura listas de usuarios, especificando el ID utilizado en la clave user. Por defecto, estas están vacías, así que si no especificas usuarios, no se crearán.

Usuarios administradores globales con una cuenta Unix separada y permisos sudo.

users_global_admin_users:
 - jake

Usuarios administradores a nivel de proyecto con una cuenta Unix separada y permisos sudo.

users_admin_users:
 - fred

Usuarios de proyecto con una cuenta Unix separada pero sin permisos sudo.

users_regular_users:
 - bob

Usuarios (claves SSH) que pueden acceder a la cuenta de despliegue.

users_deploy_users:
 - ci

Usuarios (claves SSH) que pueden acceder a la cuenta de aplicación.

users_app_users:
 - fred

Configuración de grupos

Puedes especificar grupos adicionales a los que diferentes tipos de usuarios pertenecerán. Por defecto, estas listas están vacías, pero puedes usarlas para afinar el acceso a la aplicación.

Normalmente configuramos SSH para que una cuenta de usuario deba ser miembro de un grupo sshusers, o SSH no permitirá que nadie inicie sesión.

Agrega esto a /etc/ssh/sshd_config

AllowGroups sshusers sftpusers

Luego añade sshusers a users_admin_groups, por ejemplo:

users_admin_groups:
  - sshusers

Grupos Unix que los usuarios administradores deberían tener.

El rol siempre se agregará al grupo wheel o admin, dependiendo de la plataforma. Si hay usuarios administradores definidos, entonces este rol configura sudo con un archivo /etc/sudoers.d/00-admin para que los usuarios administradores puedan ejecutar sudo sin contraseña.

users_admin_groups:
  - sshusers

Grupos Unix que los usuarios regulares deberían tener:

users_regular_groups:
  - sshusers

Grupos Unix que la cuenta de despliegue debería tener:

users_deploy_groups:
  - sshusers

Grupos Unix que la cuenta de la aplicación debería tener:

users_app_groups:
  - sshusers

Eliminando usuarios

Este rol define usuarios que crea con "ansible-" en el comentario. Esto permite rastrear cuándo se añaden o eliminan usuarios de las listas y eliminar las cuentas.

También puedes especificar cuentas en la lista users_delete_users y serán eliminadas. Esto es útil para limpiar cuentas heredadas.

Puedes controlar si eliminar el directorio home del usuario al eliminar la cuenta con las variables users_delete_remove y users_delete_force. Consulta la documentación de Ansible para más detalles. Por seguridad, estas variables son no por defecto, pero si estás gestionando los usuarios del sistema con este rol, probablemente querrás configurarlas en yes.

users_delete_remove: yes
users_delete_force: yes

El rol puede opcionalmente eliminar claves autorizadas de usuarios del sistema como 'root' o 'ubuntu'. Esto es útil por razones de seguridad para evitar respaldo de claves root, una vez que has configurado usuarios administradores con nombre.

users_remove_system_authorized_keys: true

Setup

La secuencia normal es ejecutar este rol como la primera acción en una nueva instancia. Eso crea usuarios administradores y configura sus claves para que puedan ejecutar otros roles que configuran el servidor. Un rol específico del proyecto es responsable de preparar el servidor para la aplicación, por ejemplo, creando directorios e instalando dependencias. Normalmente, desplegamos la aplicación desde un servidor de construcción o CI, sin sudo, usando la cuenta de usuario de despliegue.

Aquí hay un playbook típico:

- name: Gestionar usuarios
  hosts: '*'
  vars:
    users_app_user: foo
    users_app_group: foo
    users_deploy_user: deploy
    users_deploy_group: deploy
    users_users:
      - user: jake
        name: "Jake Morrison"
        github: reachfh
    users_app_users:
      - jake
    users_deploy_users:
      - jake
  roles:
    - { role: cogini.users, become: true }

Agrega el host al archivo inventory/hosts.

[web-servers]
web-server-01

Agrega el host a .ssh/config o a un archivo ssh.config específico del proyecto.

Host web-server-01
    HostName 123.45.67.89

En un servidor físico donde comenzamos con una cuenta de root y sin claves SSH, necesitamos inicializar el servidor la primera vez, especificando la contraseña con -k.

ansible-playbook -k -u root -v -l web-server-01 playbooks/manage-users.yml --extra-vars "ansible_host=123.45.67.89"

En macOS, el comando -k requiere la utilidad askpass, que no se instala por defecto, por lo que recae en paramiko, que no entiende .ssh/config, así que especificamos ansible_host manualmente.

En ejecuciones siguientes, después de que los usuarios administradores estén configurados, usa:

ansible-playbook -u $USER -v -l web-server-01 playbooks/manage-users.yml

Eliminando usuarios heredados

Define cuentas de usuario heredadas para eliminar en la lista users_delete_users, por ejemplo:

ansible-playbook -u $USER -v -l web-servers playbooks/manage-users.yml --extra-vars "users_delete_users=[fred] users_delete_remove=yes users_delete_force=yes"

Licencia

MIT

Información del Autor

Jake Morrison en Cogini