TP 6. AppRole de bout en bout

Énoncé de travail pratique

Les commandes ne figurent pas dans les énoncés : elles se construisent à partir du chapitre déclencheur indiqué ci-dessous. Le laboratoire et le livret de corrections ne sont pas encore publiés. Voir les limites du livrable

Chapitre déclencheur : 13. Durée : 2 h.

Objectifs

Construire la chaîne d'authentification applicative complète : rôle durci, identité pré-créée, livraison du secret_id sous enveloppe, script de connexion, vérification par l'audit, rotation et révocation. Un volet optionnel ajoute l'authentification humaine par OIDC.

Prérequis

TP 5 terminé. Chapitre 13 lu. Conteneur app-01 démarré.

Étapes

1. Créer le rôle durci. Activez approle et créez le rôle billing avec : les policies billing-kv, une durée de token d'une heure plafonnée à quatre, une borne d'origine sur l'adresse d'app-01, un secret_id valable dix minutes et utilisable une seule fois.

2. Pré-créer l'identité. Créez l'entité billing dans la couche Identity, puis l'alias correspondant à ce rôle. Notez soigneusement quelle valeur sert d'identifiant d'alias pour AppRole : ce point surprend et se vérifie plutôt qu'il ne se devine.

3. Livrer sous enveloppe. Générez un secret_id sous enveloppe de deux minutes et déposez le jeton d'enveloppe dans un fichier accessible à app-01 uniquement.

4. Se connecter depuis l'application. Depuis app-01, écrivez et exécutez le script fourni en squelette : il ouvre l'enveloppe, se connecte avec le role_id et le secret_id, range le token dans un fichier en mémoire aux permissions strictes, lit un secret, puis se termine.

5. Vérifier. Contrôlez trois choses : la lecture a réussi ; une lecture hors périmètre est refusée depuis le même token ; le journal d'audit relie l'opération à l'entité billing et non à un identifiant anonyme.

6. Échouer volontairement. Refaites l'étape 3 mais consommez l'enveloppe depuis admin-01 avant qu'app-01 ne le fasse. Constatez l'échec côté application, et décrivez ce que l'exploitant doit conclure et faire.

7. Rotation et révocation. Listez les accessors de secret_id du rôle, détruisez-en un, et constatez l'effet. Puis révoquez le token applicatif en cours par son accessor et mesurez le temps nécessaire pour que l'application redevienne opérationnelle.

8. Volet optionnel : OIDC. Avec kc-01, configurez la méthode OIDC contre le domaine de test fourni, créez un groupe externe correspondant au groupe ops de l'annuaire et attachez-lui une policy. Connectez-vous avec un compte de l'annuaire et vérifiez que les droits proviennent de l'appartenance, sans qu'aucun objet n'ait été créé pour cet utilisateur dans Vault.

Résultats attendus

Une application qui obtient un token sans qu'aucun secret durable ne soit stocké sur son disque, une identité unique dans l'audit, un refus hors périmètre, une interception détectée et traitée, une rotation de secret_id effectuée. Le volet optionnel donne une connexion humaine dont les droits proviennent d'un groupe de l'annuaire.

Erreurs possibles et diagnostic

La connexion échoue avec un refus alors que les identifiants semblent bons : la borne d'origine rejette votre adresse, ou le secret_id a expiré ; les deux se distinguent par le message. L'alias d'entité ne correspond à rien : vous avez utilisé le mauvais identifiant, et l'audit vous montrera l'entité anonyme créée automatiquement. Le token fonctionne mais l'audit ne montre pas l'entité attendue : votre alias a été créé après la première connexion, qui a fabriqué sa propre entité, nettoyez et recommencez. Le script laisse le token dans un fichier persistant : relisez les exigences de l'étape 4.

Questions

1. Combien de secrets durables votre application détient-elle à la fin du TP, et lesquels ?
2. Quel est exactement le coût de la révocation d'urgence que vous avez mesurée à l'étape 7, et comment le réduiriez-vous sans affaiblir la sécurité ?
3. Dans le volet optionnel, qu'est-ce qui se passe côté Vault lorsqu'une personne quitte le groupe ops dans l'annuaire ?