lunes, 12 de agosto de 2019

Automatizar la creación de usuarios en nuestros servidores

A veces nos toca crear un usuarios -o varios- en uno o varios servidores. Si tenemos muchos servidores, ir de uno en uno no es efectivo. Nos tiraríamos mucho tiempo. Así pues, tenemos que buscar una manera de forma casi obligada de automatizar este proceso.



Lo que vamos a utilizar será ansible y sus playbooks para automatizar estas tareas. Recordad que en /etc/ansible/hosts tendremos que tener nuestros servidores. Así pues y con eso en mente, vamos a crear nuestro playbook para automatizar la tarea de creación de usuarios.

- hosts: all
  vars:
    username: test
  tasks:
  - name: "Instalar zsh en caso de no estar instalado"
    apt:
      name: zsh
      state: present
  - name: "Creando grupo {{ username }} en caso de que no exista"
    group:
      name: "{{ username }}"
      state: present
  - name: "Creando usuario {{ username }} en (all) server(s)"
    user:
      # echo -n "RANDOM PASSWORD" | mkpasswd --method=sha-512 -s
      name: "{{ username }}"
      group: "{{ username }}"
      groups: su
 password: "$6$ZnM9e3lWH$m.rIk/0qKYPvLt45wBCTX/Ga46bd7Ud.sFNNggDYil7IZVfTbfHT2R1gL6Q9XupT/ohJZBIUziClIyUvCLB3v/"
      shell: /bin/zsh
      append: yes
      update_password: on_create
      state: present

Vamos por partes:

1. Hosts lo que nos está indicando es sobre qué servidores queremos aplicar las tareas de nuestro playbook. En este caso y como suelo hacer casi siempre, yo suelo especificar "all", ya que después al ejecutar el playbook podremos realizar algunas especificaciones.
2. En vars lo que estamos haciendo es añadir algunas variables, en este caso el nombre del usuario que vamos a crear. Esto nos va a servir para después llamarlo con {{ username }}, sustituyéndose por "test".
3. En tasks lo que vamos a hacer será enumerar las tareas que queremos realizar. Es recomendable que añadamos el campo -name para asignar un nombre a modo de comentario y así saber qué se está ejecutando.
4. Con group, lo que hacemos es especificar la tarea "Group", que no es otra más que crear un grupo que, por nombre tenga el mismo que el que hemos establecido en la variable username.
5. Con user lo que hacemos es especificar la tarea "user", que es la propia para crear el usuario con sus distintos grupos y, además, su contraseña, pero ¿Qué es esa contraseña? Pues la hemos generado de manera muy sencilla.

hippi3c0w% echo -n "1234567" | mkpasswd --method=sha-512 -s
$6$ZnM9e3lWH$m.rIk/0qKYPvLt45wBCTX/Ga46bd7Ud.sFNNggDYil7IZVfTbfHT2R1gL6Q9XupT/ohJZBIUziClIyUvCLB3v/
hippi3c0w% 

Lo que hemos tenido que hacer es escribir en un echo la contraseña y hashearla con el comando mkpasswd para no escribirla en texto claro en el archivo .yml. Este resultado será el que tendremos que poner en nuestro playbook.

Antes de seguir, hay quien pueda decir que me he saltado la task de instalar zsh. No, pero lo único que hay que comentar es que basta con introducir que la task es "apt", pues ejecutará un apt-get install.

6. El campo o directiva shell es bastante intuitivo, simplemente especificamos con qué shell va a iniciar sesión. Para este usuario he especificado que sea zsh.

7. update_password. Con esta directiva lo que vamos a hacer es especificar si queremos que su contraseña se cambie siempre o solamente con se cree un usuario nuevo. Como es evidente, escogeremos on_create para no matar la contraseña de todos los usuarios.
8. Con append lo que haremos es especificar si queremos que el usuario que creamos pertenezca a los grupos que hemos especificado en "groups" o no.

Es decir, que por un lado tenemos que, cuando creamos un usuario lo que hacemos es instalar zsh si no está instalado y crear el grupo y el usuario en cuestión. Puede parecer que lo hemos automatizado mucho, pero podríamos automatizarlo aún más.

Por ejemplo podríamos personalizar su oh my zsh y su perfil de tmux y añadir su clave ssh tan sólo ejecutando este playbook con estas tasks correspondientes.

Pero veamos el resultado que tendríamos si ejecutamos este playbook


Es cierto que en nuestro comando para ejecutar el playbook hemos tenido que especificar algunas opciones como:

- Opción -u: Con esto explicamos con qué usuario de nuestro servidor nos queremos conectar.

- Opción -b: Con esto indicamos que vamos a validar el become (antes podíamos escribir --ask-sudo-pass y ya bastaba, pero ahora en las nuevas versiones no).

- Opción --become-user: Con este lo que estamos haciendo, en realidad, es escalar privilegios para ser root (si nuestro usuario está dentro de sudoers -que debería si somos SysAdmins).

- Opción --become-pass: Con esto especificamos que queremos que nos pregunte por la contraseña de sudo de este usuario para que así podamos ejecutar los comandos como los de apt o useradd

Pero ¿Ha creado realmente el usuario? Pues vamos a verlo lanzando de nuevo ansible.

hippi3c0w% ansible all -m shell -a "cat /etc/passwd | grep test" -u [remote_user] -b --become-user=root --ask-become-pass --limit [specific_server]
SUDO password:
94.130.164.233 | CHANGED | rc=0 >>
test:x:1003:1003::/home/test:/bin/zsh

hippi3c0w% 
 
Lo que he ejecutado ha sido un ansible normal que liste el archivo /etc/passwd y que busque el usuario "test" que hemos tenido que crear para comprobar si se ha creado correctamente o no. Además lo que hecho es, para no buscar en todos los servidores, buscar solamente en uno con --limit seguido del nombre del servidor que tengamos en nuestro /etc/ansible/hosts.

Así de simple, por lo que podemos tener un gran abanico de playbooks y lanzarlos y realizar instalaciones, creaciones de usuarios, actualizaciones de servidores,etc de forma desatendida y automatizada ahorrando mucho tiempo.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...