Sur nos conteneurs de travail nous ne souhaitons pas que l’utilisateur aient les droits root, nous allons, à l’aide d’un playbook Ansible, créer un nouvel utilisateur nommé worker.
Voici un playbook pour créer l’utilisateur worker sur les machines du groupe calcul_distribue :
---
# Création de l'utilisateur worker sur les machines de calcul distribué
- name: Configuration des workers
hosts: calcul_distribue
become: true # Pour avoir les privilèges root
tasks:
- name: Création de l'utilisateur worker
ansible.builtin.user:
name: worker
state: present
shell: /bin/bash
system: false
create_home: true
# groups: sudo # Décommenter si vous voulez ajouter l'utilisateur au groupe sudo
- name: Configuration SSH pour l'utilisateur worker
ansible.builtin.authorized_key:
user: worker
state: present
key: "{{ lookup('file', '/home/deployer/.ssh/id_ed25519.pub') }}"
# Optionnel : Configuration sudo sans mot de passe
# - name: Configuration des droits sudo
# ansible.builtin.lineinfile:
# path: /etc/sudoers.d/worker
# line: "worker ALL=(ALL) NOPASSWD:ALL"
# create: yes
# mode: '0440'
# validate: /usr/sbin/visudo -cf %s
Ce playbook :
- Cible uniquement les machines du groupe
calcul_distribue - Crée l’utilisateur
workeravec un home directory - Configure l’accès SSH avec votre clé publique
- Contient des options commentées pour donner les droits sudo si nécessaire
Exécutons ce playbook :
deployer@ubuntu-deploy:~/homelab_julia_pve_tf_ansible$ ANSIBLE_REMOTE_USER=root ansible-playbook -i dynamic-in
ventory.proxmox.yml create-worker-user.yml
PLAY [Configuration des workers] *****************************************************************************
TASK [Gathering Facts] ***************************************************************************************
ok: [ubuntu-lxc-4]
ok: [ubuntu-lxc-1]
ok: [ubuntu-lxc-5]
ok: [ubuntu-lxc-3]
ok: [ubuntu-lxc-2]
TASK [Création de l'utilisateur worker] **********************************************************************
changed: [ubuntu-lxc-4]
changed: [ubuntu-lxc-1]
changed: [ubuntu-lxc-5]
changed: [ubuntu-lxc-2]
changed: [ubuntu-lxc-3]
TASK [Configuration SSH pour l'utilisateur worker] ***********************************************************
changed: [ubuntu-lxc-1]
changed: [ubuntu-lxc-4]
changed: [ubuntu-lxc-5]
changed: [ubuntu-lxc-3]
changed: [ubuntu-lxc-2]
PLAY RECAP ***************************************************************************************************
ubuntu-lxc-1 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
ubuntu-lxc-2 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
ubuntu-lxc-3 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
ubuntu-lxc-4 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
ubuntu-lxc-5 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Vous pouvez ensuite tester l’accès :
ssh -i /home/deployer/.ssh/id_ed25519 worker@192.168.1.201Remarque :
La fonction lookup('file', '/home/deployer/.ssh/id_ed25519.pub') va lire le contenu du fichier de clé publique SSH spécifié.
Par exemple, si votre fichier id_ed25519.pub contient :
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM9svI8Zy/sJ1... deployer@ubuntu-deploy
Le lookup va récupérer cette chaîne de caractères et l’utiliser comme valeur pour la variable key.
On peut aussi écrire la clé directement dans le playbook :
---
- name: Configuration des workers
hosts: calcul_distribue
become: true
tasks:
- name: Création de l'utilisateur worker
ansible.builtin.user:
name: worker
state: present
shell: /bin/bash
create_home: true
- name: Configuration SSH pour l'utilisateur worker
ansible.builtin.authorized_key:
user: worker
state: present
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM9svI8Zy/sJ1... deployer@ubuntu-deploy"
Les deux approches sont équivalentes, mais utiliser lookup est plus maintainable car :
- La clé est gérée dans un fichier séparé
- Si la clé change, pas besoin de modifier le playbook
- C’est plus sécurisé que d’avoir la clé directement dans le code