AWX : les premières actions d'administration

Une installation neuve d'AWX contient un seul compte, admin, qui peut tout faire, et dont le mot de passe est resté en clair dans le fichier de configuration de l'installeur. C'est la page à ouvrir immédiatement après l'installation. Elle sécurise ce compte, puis structure la plateforme : une organisation, une équipe, un utilisateur restreint, et la délégation du droit d'exécuter un job sans lui donner accès aux identifiants.

Nous vérifierons cette promesse par l'expérience, pas sur parole : à la fin, l'utilisateur créé verra un job template, zéro identifiant, et se verra refuser toute modification.

Ce que vous allez apprendre

• Sécuriser le compte administrateur livré par l'installeur
• Comprendre où vivent les droits dans AWX, et pourquoi ils ne sont pas globaux
• Créer une organisation, une équipe et un utilisateur non administrateur
• Accorder un rôle d'exécution à une équipe plutôt qu'à une personne
• Vérifier ce que voit réellement un utilisateur restreint
• Appliquer les réglages de sécurité à faire dès le premier jour

Prérequis

• Une plateforme AWX ou Ascender fonctionnelle. Voir Installer Ascender sur k3s.
• Le compte admin et son mot de passe.

L'ordre de lecture

Les quatre premières étapes se font sur une plateforme vide, juste après l'installation. La cinquième, la délégation des droits, a besoin d'un job template sur lequel accorder un rôle : elle suppose que vous avez suivi entre-temps Premiers pas avec AWX. Le parcours complet est donc : installer, sécuriser admin, créer les comptes, faire tourner un premier job, puis déléguer.

Où vivent les droits

C'est la notion qui déroute le plus. Dans AWX, un rôle n'est pas attaché à une personne, il est porté par un objet. On ne dit pas « Alice est opératrice », on dit « l'équipe Ops détient le rôle Execute sur ce job template ».

Chaque objet expose ses propres rôles. Sur un job template, ils sont au nombre de trois, et l'API les décrit sans ambiguïté :

Admin     Can manage all aspects of the job template
Execute   May run the job template
Read      May view settings for the job template

La hiérarchie qui structure le tout tient en trois niveaux :

Niveau	Rôle dans le modèle	Bon usage
Organisation	frontière d'isolation	une par entité qui ne doit rien voir des autres
Équipe	vecteur de droits	accorder les rôles ici, jamais aux personnes
Utilisateur	identité	rattaché à une ou plusieurs équipes

Glissez pour voir

Accordez les rôles aux équipes, jamais aux personnes

Attribuer un rôle directement à un utilisateur fonctionne, et devient ingérable dès la troisième personne : plus rien n'est auditable, et le départ d'un collaborateur laisse des droits orphelins. Une équipe, même à un seul membre, rend les droits lisibles et transférables.

Étape 1 - Sécuriser le compte administrateur

C'est la toute première chose à faire, avant de créer quoi que ce soit d'autre. Le mot de passe d'admin a été fixé en clair dans le fichier de configuration de l'installeur, il traîne dans l'historique de votre shell, et il ouvre un compte capable de lire tous les identifiants et de lancer n'importe quel playbook sur n'importe quelle machine du parc.

Changez-le depuis l'interface, dans Accès > Utilisateurs (Access > Users), puis admin, onglet Détails (Details), Modifier (Edit).

L'interface suit la langue de votre navigateur. Ce guide donne le libellé français, puis le terme anglais entre parenthèses, qui reste celui de l'API et de la documentation officielle.

Créez ensuite votre propre compte administrateur nominatif, avec le type Administrateur du système (System Administrator), et cessez d'utiliser le compte partagé. Un journal d'activité qui n'affiche que admin n'identifie personne et n'a aucune valeur d'audit. Le compte admin d'origine reste utile comme accès de secours, avec un mot de passe long rangé dans un coffre.

Étape 2 - Créer une organisation

Une installation neuve contient une organisation nommée Default. Elle convient à un lab, jamais à une plateforme partagée : tout ce qui y vit est visible par tous ceux qui y sont rattachés.

Ouvrez Accès > Organisations (Access > Organizations), puis Ajouter (Add), et créez Infrastructure. L'organisation devient la frontière d'isolation : projets, inventaires, identifiants et job templates lui appartiennent.

Étape 3 - Créer une équipe

Dans Accès > Équipes (Access > Teams), puis Ajouter (Add), créez l'équipe Ops et rattachez-la à l'organisation Infrastructure.

Une équipe ne donne aucun droit par elle-même. Elle est le conteneur auquel vous accorderez des rôles, et dans lequel vous placerez des utilisateurs.

Étape 4 - Créer un utilisateur restreint

Dans Accès > Utilisateurs (Access > Users), puis Ajouter (Add), créez alice. Le point décisif est le champ Type d'utilisateur (User Type) : laissez-le sur Utilisateur normal (Normal User). Ni Administrateur du système, ni Auditeur système.

Rattachez ensuite alice à l'équipe Ops, depuis l'onglet Utilisateurs (Users) de l'équipe.

À ce stade, alice ne voit rien. Elle peut se connecter, et son interface est vide. C'est le comportement attendu : dans AWX, on ne retire pas des droits, on en accorde.

Étape 5 - Déléguer l'exécution

Nous allons donner à l'équipe Ops le droit de lancer le job template Collecter les faits, sans lui donner le droit de le modifier, ni d'accéder à la clé SSH qu'il utilise.

Cette étape est la seule qui suppose un job template existant : on ne peut pas accorder un rôle sur un objet qui n'existe pas. Si votre plateforme est encore vide, créez d'abord ce template en suivant Premiers pas avec AWX, puis reprenez ici.

1. Ouvrez le job template Collecter les faits, onglet Accès (Access), puis Ajouter (Add).

2. Choisissez Équipes (Teams), sélectionnez Ops.

3. Cochez le rôle Execute, et uniquement celui-là. Les noms de rôles viennent de l'API et restent en anglais.

4. Enregistrez (Save).

Étape 6 - Vérifier, plutôt que croire

C'est l'étape que l'on saute, et c'est la seule qui prouve quelque chose. Connectez-vous avec alice, ou interrogez l'API en son nom.

TOKEN=$(curl -sk -u "alice:MotDePasseAlice" -X POST \
  https://ascender.lab.local/api/v2/tokens/ \
  -H "Content-Type: application/json" -d '{}' | jq -r .token)

# Ce qu'elle voit
curl -sk -H "Authorization: Bearer $TOKEN" \
  https://ascender.lab.local/api/v2/job_templates/ | jq .count
curl -sk -H "Authorization: Bearer $TOKEN" \
  https://ascender.lab.local/api/v2/credentials/ | jq .count

1     # un job template : celui sur lequel son équipe a le rôle Execute
0     # aucun identifiant

Et si elle tente de modifier le template auquel elle a pourtant accès :

curl -sk -o /dev/null -w "%{http_code}\n" -X PATCH \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"renomme"}' \
  https://ascender.lab.local/api/v2/job_templates/23/

403

Alice peut lancer le job. Elle ne peut ni le modifier, ni voir la clé SSH qui l'exécute. C'est toute la promesse d'AWX, et elle tient.

Les réglages à faire dès le premier jour

Trois paramètres, dans Paramètres (Settings), méritent d'être posés avant les premiers utilisateurs.

La durée de vie des sessions et le nombre de sessions simultanées par utilisateur limitent l'exposition d'un poste laissé ouvert. La valeur par défaut est confortable, donc permissive.

La durée de vie des jetons OAuth2 conditionne combien de temps un jeton volé reste exploitable. Un jeton d'API qui n'expire jamais est un mot de passe permanent.

Enfin, le message d'avertissement à la connexion permet d'afficher une mention légale ou un rappel de la politique interne, souvent exigé en entreprise.

Pièges courants

Piège	Conséquence	Correctif
Tout le monde reste System Administrator	aucune traçabilité, aucun garde-fou	comptes nominatifs, Normal User par défaut
Rôles accordés aux personnes	droits orphelins au départ d'un collaborateur	accorder à des équipes
Tout vit dans l'organisation Default	les équipes voient le travail des autres	une organisation par frontière d'isolation
Rôle Admin accordé pour « débloquer »	l'utilisateur peut modifier le playbook exécuté	accorder Execute, et rien de plus
Continuer à se connecter en admin	le journal d'activité n'identifie personne	créer son propre compte administrateur

Glissez pour voir

À retenir

• Dans AWX, un rôle est porté par un objet, pas par une personne. On accorde Execute sur un job template.
• La hiérarchie est organisation, équipe, utilisateur : l'organisation isole, l'équipe porte les droits, l'utilisateur les hérite.
• Accordez les rôles aux équipes, jamais directement aux personnes, sous peine de droits orphelins et inauditables.
• Un utilisateur neuf ne voit rien : AWX accorde des droits, il n'en retire pas.
• Le rôle Execute suffit pour lancer un job. Il ne donne accès ni au playbook, ni aux identifiants, et interdit toute modification (HTTP 403).
• Vérifiez toujours en vous connectant avec le compte restreint : c'est la seule preuve que le modèle de droits fait ce que vous croyez.
• Abandonnez le compte admin partagé au profit de comptes nominatifs, sinon le journal d'activité ne vaut rien.

Prochaines étapes

Premiers pas avec AWX Créer un identifiant, un inventaire, un projet et lancer son premier job.

AWX : concepts et avenir du projet Le pivot du hub, et pourquoi Ascender pour installer aujourd'hui.

Installer Ascender sur k3s Monter la plateforme de zéro, en HTTPS.

Formation Ansible Les playbooks, rôles et inventaires qu'AWX orchestre.

×

📖 Voir la documentation →