Aller au contenu

TP 4. Écrire, tester et raffiner des policies

É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 : 11. Durée : 2 h.

Objectifs

Écrire des autorisations qui accordent exactement ce qu'il faut, les éprouver sous une identité dédiée en vérifiant autant les refus que les succès, tomber dans le piège des chemins de données et de métadonnées pour ne plus jamais y tomber, et raffiner une policy d'administration trop large.

Prérequis

TP 3 terminé. Chapitre 11 lu.

Étapes

1. Une première policy naïve. Écrivez billing-kv en accordant la lecture sur secret/billing/prod/*. Créez un compte userpass de test portant cette seule policy, connectez-vous avec, et tentez de lire secret/billing/prod/db. Constatez le refus, puis expliquez-le avant de corriger : la réponse est dans la structure des chemins que vous avez manipulée au TP 3.

2. Corriger et compléter. Réécrivez la policy sur les chemins réels. Ajoutez ce qu'il faut pour que le porteur puisse lister les secrets de son périmètre sans pouvoir lire ceux des autres. Vérifiez les deux comportements.

3. Construire la grille de refus. Sous le token de test, tentez : la lecture d'un secret hors périmètre, l'écriture dans son propre périmètre, la destruction d'une version, la lecture de sys/policies. Consignez les quatre résultats. Une policy dont les refus n'ont pas été testés n'a pas été testée.

4. Comprendre les jokers. Créez deux policies expérimentales, l'une utilisant le joker de fin de chemin, l'autre le joker de segment, et déterminez expérimentalement lequel autorise secret/data/billing/prod/db et lequel autorise secret/data/billing/prod/interne/db. Formulez la règle en une phrase.

5. Éprouver la priorité du refus. Attribuez à un même compte deux policies dont l'une accorde et l'autre refuse explicitement le même chemin. Constatez le résultat et déduisez-en la règle de composition.

6. Raffiner admin. La policy admin du TP 2 accorde plus que nécessaire. Réécrivez-la pour qu'elle permette d'administrer : méthodes d'authentification, policies, montages, identités, audit ; sans permettre de lire les valeurs des secrets applicatifs, tout en conservant l'accès aux métadonnées pour l'inventaire. Testez que l'administrateur peut lister et voir les propriétaires, et ne peut pas lire un mot de passe.

7. Détecter les chemins nécessaires. Exécutez une commande de votre choix avec l'option qui affiche la policy minimale requise, et comparez le résultat à ce que vous auriez écrit spontanément.

Résultats attendus

billing-kv accorde la lecture des données de production et l'énumération, rien d'autre, avec quatre refus constatés. La règle des deux jokers est formulée et démontrée. La priorité du refus est constatée. admin raffinée est en place, avec la preuve qu'elle ne lit pas les valeurs applicatives. Toutes les policies sont enregistrées dans conf/policies/ avec un commentaire d'intention.

Erreurs possibles et diagnostic

Tout est refusé alors que la policy semble correcte : vous testez sous un token qui ne la porte pas ; vérifiez les policies effectives du token avant de suspecter la policy elle-même. La lecture fonctionne mais pas l'énumération : les deux relèvent de familles de chemins différentes. Le raffinement d'admin vous verrouille : vous avez retiré un droit nécessaire à l'administration elle-même ; la cérémonie du TP 2 sait produire un token pour réparer, ce qui est précisément sa raison d'être. La policy affichée par l'option de détection paraît trop large : elle décrit ce que la commande a réellement demandé, ce qui est instructif.

Questions

  1. Formulez en une phrase la règle des chemins réels, telle que vous la donneriez à un collègue pour lui éviter deux heures de recherche.
  2. Pourquoi votre admin raffinée conserve-t-elle l'accès aux métadonnées alors qu'elle perd l'accès aux données ? Quel usage cela sert-il ?
  3. Un administrateur peut-il, avec votre admin raffinée, obtenir la valeur d'un secret applicatif ? Décrivez le chemin qu'il emprunterait et ce qui le trahirait.