La gestion des privilèges dans les systèmes informatiques est un défi majeur.
Une mauvaise configuration peut entraîner des failles de sécurité critiques.
Cet article explore comment Ansible utilise des paramètres comme become pour sécuriser l’escalade des privilèges.
Devenez un expert d'Ansible et simplifiez vos tâches d'administration.
Gérer les privilèges
L’escalade des privilèges permet à un utilisateur ou à un processus d’acquérir des permissions supplémentaires, telles que celles de l’utilisateur root, pour effectuer des tâches spécifiques nécessitant des droits élevés. C’est un processus crucial en administration système pour assurer la sécurité et la gestion efficace des systèmes informatiques.
- Le mot clé become :Le mot-clé become est défini sur yes pour permettre l’escalade des privilèges afin d’assurer que le service httpd est démarré. Voici un exemple :
- name: Assurer que le service httpd est démarré
service:
name: httpd
state: started
become: yes
Cela permet à Ansible d’exécuter cette tâche avec les privilèges nécessaires, souvent en utilisant sudo , pour garantir que le service httpd est opérationnel sur l’hôte cible.
- Le mot become_user :Le paramètrebecome_userest configuré pour exécuter une commande en tant qu’utilisateur Apache avec les privilèges requis :
- name : Exécuter une commande en tant qu’utilisateur Apache
command: somecommand
become: yes
become_user: apache
Cela permet à Ansible d’élever les privilèges et d’exécuter somecommand en tant qu’utilisateur apache, assurant ainsi que la commande est exécutée avec les autorisations appropriées sur l’hôte cible.
- Le mot become_method :Le paramètrebecome_methodremplace la méthode par défaut définie dansansible.cfget permet d’exécuter une commande en tant qu’utilisateurnobody:
- name: Exécuter une commande en tant que nobody
command: somecommand
become: yes
become_method: su
become_user: nobody
Cela configure Ansible pour utiliser la méthode su afin d’élever les privilèges et d’exécuter somecommand avec l’utilisateur nobody sur l’hôte cible.
- Le mot remote_user :Le paramètreremote_userspécifie le nom d’utilisateur utilisé pour la connexion SSH :
- name: Mon Play
hosts: all
remote_user: admin
tasks:
- name: Assurer la présence de httpd
yum:
name: httpd
state: present
become: true
become_user: webuser
Cela définit Ansible pour se connecter à tous les hôtes avec l’utilisateur admin via SSH . Ensuite, il assure que le paquet httpd est présent en utilisant yum , en s’élevant avec les privilèges de webuser lorsque nécessaire.
Voici les fonctionnalités que le mot-clé become fournit dans Ansible. Cependant, il présente des limites et des risques :
- Il permet l’exécution d’actions en tant qu’utilisateur non privilégié, ce qui restreint les opérations possibles.
- Il peut limiter l’accès au fichier de module selon les permissions de l’utilisateur que Ansible doit devenir.
Pour bien comprendre cette fonctionnalité du mot clé become, passons maintenant dans le cas pratique en dvelopper quelques exemples des playbook avec ce mot clé.
Comme premier exemple, noous allons executer le playbook suivant en le mettant dans le fichier become-playbook.yml :
- hosts: servers
tasks:
- name: Install apache
apt:
name: apache2
state: present
become: true
Pour l’exécuter, nous allons utiliser la commande : ansible-playbook -v become-playbook.yml . Habituellement, nous ajouterions — become à la fin de la commande, mais comme nous avons déjà spécifié become: true dans le playbook , celui-ci s’exécutera automatiquement avec les privilèges nécessaires et nous fournira le résultat comme suit :
Nous allons approfondir en modifiant le playbook pour inclure un remote_user et une tâche que cet utilisateur ne pourrait normalement pas exécuter. Voici le playbook modifié :
- hosts: servers
remote_user : ubuntu
tasks:
- name: Install apache
apt:
name: apache2
state: present
become: true
become_user: ubuntu
- name: display apache version
command: /user/sbin/apache2 -v
bacome_user: nobody
Ce playbook ne pourra pas exécuter la deuxième tâche display apache version car l’utilisateur become_user: nobody n’est pas autorisé à le faire. Copions-le dans le fichier become_user-playbook. yml et exécuter pour voir le résultat.
Parfait, la tâche n’a pas été exécutée car l’utilisateur become_user: nobody n’est pas autorisé. Pour corriger cela, il suffit de remplacer become_user: nobody par become_user: ubuntu , ce qui devrait résoudre le problème comme ceci :
Formez-vous gratuitement avec Alphorm !
Maîtrisez les compétences clés en IT grâce à nos formations gratuites et accélérez votre carrière dès aujourd'hui.
FAQ
Comment fonctionne l'escalade des privilèges dans Ansible ?
Comment utiliser le mot-clé become dans Ansible ?
Quelles sont les limites de l'utilisation de become dans Ansible ?
Comment configurer Ansible pour exécuter des commandes avec become_user ?
Comment corriger les erreurs d'exécution avec become_user ?
Conclusion
L’utilisation appropriée de l’escalade des privilèges dans Ansible est cruciale pour la sécurité des systèmes. Quelles autres stratégies utilisez-vous pour renforcer la sécurité des privilèges dans vos configurations Ansible?
