AWX : concevoir des job templates qui ne deviennent pas une console distante dangereuse

AWX apporte vite une interface confortable pour lancer Ansible. C’est précisément ce qui peut le rendre dangereux. Un playbook générique, un inventaire trop large, un compte SSH trop privilégié et quelques variables libres suffisent à transformer une plateforme d’automatisation en console distante avec historique centralisé mais contrôles faibles.

Le scénario traité ici est celui d’une équipe qui veut exposer quelques opérations Linux récurrentes : vérifier l’état d’un serveur, redémarrer un service approuvé, installer un paquet validé, appliquer un rôle de configuration sur un groupe limité. L’objectif n’est pas de permettre à AWX de tout faire. L’objectif est de publier des actions bornées, compréhensibles et vérifiables.

Partir des actions autorisées

La première erreur est de créer un template AWX à partir d’un playbook existant sans redéfinir le périmètre. Un playbook d’administrateur peut être souple. Un job template exposé à une équipe doit être contraint. Il faut commencer par l’action métier ou opérationnelle : ce bouton doit faire quoi, sur quelles machines, avec quel compte et quelle preuve de résultat ?

Actions exposées au démarrage
Vérifier l'espace disque sur production_web
Redémarrer nginx ou telegraf sur production_web
Installer un paquet validé sur production_tools
Appliquer le rôle linux_baseline sur préproduction

Actions non exposées
Redémarrer un groupe libre
Exécuter une commande shell arbitraire
Modifier le réseau
Changer des secrets
Rebooter un inventaire complet

Cette liste doit vivre près du dépôt Ansible ou dans la documentation d’exploitation. Sans elle, AWX devient une collection de boutons dont la portée dépend de la mémoire des administrateurs.

Réduire les variables libres

Une variable libre dans AWX est parfois utile, mais chaque champ ouvert augmente le risque. Pour un redémarrage de service, il vaut mieux vérifier une liste blanche dans le playbook que laisser un nom de service arbitraire. Pour une installation de paquet, il vaut mieux limiter le scope aux dépôts et environnements attendus.

---
- name: Restart an approved service
hosts: "{{ target_group }}"
become: true
vars:
  allowed_services:
    - nginx
    - telegraf
    - chronyd
tasks:
  - name: Reject unauthorized service
    ansible.builtin.fail:
      msg: "Service not allowed by this job"
    when: service_name not in allowed_services

  - name: Restart approved service
    ansible.builtin.service:
      name: "{{ service_name }}"
      state: restarted

  - name: Collect service facts
    ansible.builtin.service_facts:

  - name: Show service state
    ansible.builtin.debug:
      msg: "{{ service_name }} state: {{ ansible_facts.services[service_name + '.service'].state | default('unknown') }}"

Le contrôle doit exister dans le code, pas seulement dans l’interface. Une option AWX peut être modifiée. Un playbook versionné, relu et testé garde la règle au bon endroit.

Séparer les credentials par niveau de risque

Un compte unique avec NOPASSWD: ALL est confortable au début et mauvais pour l’exploitation. AWX doit utiliser des credentials adaptés au type de job. Un job de lecture n’a pas besoin de sudo. Un job de maintenance peut avoir un sudo limité. Un job plus sensible doit être rare, visible et associé à un inventaire restreint.

Credential read-only
Jobs de vérification
Pas de sudo

Credential maintenance
Redémarrage de services approuvés
Installation de paquets validés
Sudo limité aux commandes nécessaires

Credential restricted-admin
Changements plus sensibles
Inventaires limités
Usage surveillé et documenté

La vraie barrière est sur les machines cibles. AWX stocke et présente le credential, mais sudoers décide ce que le compte peut réellement faire. C’est là qu’il faut éviter les droits globaux par facilité.

Empêcher les inventaires trop larges

Un template qui accepte n’importe quel inventaire devient imprévisible. Le template de redémarrage d’un service web doit cibler le groupe web attendu, pas tout le parc. Les inventaires doivent refléter les risques : préproduction, production, bastions, bases, outils, zones restreintes.

all:
children:
  production_web:
    hosts:
      web01.example.local:
      web02.example.local:
  production_tools:
    hosts:
      tools01.example.local:
  restricted:
    hosts:
      bastion01.example.local:
      db01.example.local:

Les groupes restreints ne doivent pas être une convention orale. Ils doivent apparaître dans l’inventaire, dans la documentation et dans la configuration des templates. Un job de maintenance standard ne devrait pas pouvoir cibler un bastion par accident.

Ajouter une preuve après l’action

Un job AWX utile ne se contente pas d’exécuter une commande. Il doit montrer le résultat. Après un redémarrage, collecter l’état du service. Après une installation, afficher la version. Après une configuration, valider le fichier ou tester le daemon. Le rapport AWX devient alors une trace opérationnelle.

- name: Collect package facts
ansible.builtin.package_facts:
  manager: auto

- name: Display installed version
ansible.builtin.debug:
  msg: "{{ package_name }} version: {{ ansible_facts.packages[package_name][0].version }}"
when: package_name in ansible_facts.packages

Cette preuve change la manière de relire les changements. L’équipe ne voit pas seulement que le playbook est vert. Elle voit ce qui a été touché, où, et quel contrôle a été exécuté.

Conclusion

AWX est plus sûr quand il expose peu d’actions mais de bonnes actions. Un job template doit être pensé comme une interface d’exploitation : périmètre clair, variables limitées, credential adapté, inventaire précis et validation visible. Le but n’est pas de cacher Ansible derrière une interface. Le but est de rendre quelques opérations répétables sans donner un accès implicite à tout le parc.

La bonne base est modeste : cinq templates utiles, trois niveaux de credentials, des inventaires qui empêchent les erreurs évidentes et des playbooks qui refusent les paramètres non autorisés. Avec cette discipline, AWX devient un outil contrôlé plutôt qu’une console distante avec un bouton lancer.