Introduction
Un rapport de règlement a besoin d'accéder à la base de données pendant son exécution. Une fois la tâche terminée, ses identifiants enregistrés doivent cesser d'ouvrir de nouvelles connexions. Un message d'acceptation du service de secrets ne suffit pas à prouver ce résultat.
Cet environnement MarketLedger indépendant démarre avec les permissions correctes sur la vue. Vous exécuterez le rapport, révoquerez son bail OpenBao précis, observerez l'expiration naturelle d'un bail distinct et reprendrez l'activité en obtenant de nouveaux identifiants. La boutique et son rapport d'inventaire indépendant doivent rester utilisables. Le TP guidé précédent a enseigné les champs des identifiants et la politique de rapport limitée ; aucun fichier ni état de session n'est repris.
Partir de la boutique fonctionnelle et de la politique de rapport correcte
Dans cette étape, vous identifierez l'activité normale et les deux rôles de rapport avant de démarrer le décompte de l'un ou l'autre bail. Utilisez Terminal tout au long du TP. Entrez dans l'espace de travail indépendant :
cd /home/labex/project/market-report
cat affiche l'exemple fonctionnel préparé :
cat demo.tsv
Le règlement couvre 2026-10-28 : Birch a deux commandes payées totalisant 4700 centimes, Elm une totalisant 2000 et Maple une totalisant 2700. La commande annulée est exclue. Le rapport utilise reporting.daily_settlement ; les e-mails privés des clients et les références bancaires sont hors de son périmètre.
Le client de boutique préparé communique avec le véritable service de boutique. Ses arguments identifient une nouvelle commande, un vendeur et un montant en centimes. Passez une commande normale pour la date commerciale synthétique suivante, 2026-10-29 :
python3 shop.py place --order O201 --vendor V101 --cents 600
Cette commande plus récente n'appartient pas au règlement de la veille. Si vous répétez la commande, le service refuse le doublon ; utilisez python3 shop.py list pour voir la commande existante au lieu de la supprimer.
Le fichier env.sh fourni contient les adresses locales des services et lit le jeton d'opérateur restreint depuis son fichier privé. source charge ces affectations dans le shell courant ; export les rend accessibles aux commandes enfants. Un nouveau terminal doit les charger à nouveau :
source env.sh
Le jeton d'opérateur autorise les requêtes OpenBao ; ce n'est pas un mot de passe de base de données. Ce jeton peut obtenir et révoquer les baux précis des rôles settlement-report et settlement-short. Il ne peut ni gérer le rapport d'inventaire indépendant, ni lire la connexion d'administrateur de la base.
Lisez les instructions correctes de création de comptes :
cat role.sql
Elles créent un accès généré avec l'expiration du mot de passe fournie, accordent la recherche dans le schéma et l'accès en lecture à la vue de règlement, et conservent l'audit SQL natif. Gardez ces instructions et les configurations des deux rôles inchangées dans ce TP.
Le rôle de rapport normal dure dix minutes par défaut. Un rôle préparé distinct, settlement-short, dure trente secondes et possède les mêmes permissions sur la vue. Aucun décompte ne démarre avant votre demande d'identifiants. Vous n'avez pas à parcourir la leçon à toute vitesse avant l'expiration d'identifiants créés par l'initialisation.
Vous pouvez émettre les identifiants de ces rôles, exécuter la requête de rapport fournie, enregistrer le rapport et les réponses privées d'identifiants, et révoquer les baux de rapport précis que vous avez obtenus. Préservez les enregistrements d'origine de la base, la boutique, le rôle d'inventaire indépendant et son bail, la requête fournie, l'environnement, le jeton d'opérateur et l'environnement d'exécution préparé. Ne révoquez jamais tout un préfixe de baux.
Pour une faute de frappe dans un chemin, revenez avec le cd absolu ci-dessus, exécutez ls et réessayez avec le vrai nom du fichier. Cette reprise fonctionne sans réinitialiser l'environnement.
Exécuter le règlement avec de nouveaux identifiants temporaires
Dans cette étape, vous produirez un véritable rapport avant de mettre fin à l'accès de cette tâche. Restez dans Terminal, avec env.sh chargé.
umask 077 rend les nouveaux fichiers privés pour votre compte. bao read -format=json demande de véritables identifiants dynamiques et produit du JSON ; > l'enregistre dans un fichier au lieu d'afficher son mot de passe. Cette émission démarre le décompte du bail de dix minutes :
umask 077
bao read -format=json database/creds/settlement-report > lease.json
jq sélectionne les champs JSON. Lisez l'identifiant de bail non secret, la durée et le nom d'utilisateur généré de la base :
jq '.lease_id, .lease_duration, .data.username' lease.json
L'identifiant de bail identifie cette émission dans OpenBao ; le nom d'utilisateur identifie son compte PostgreSQL. Aucun des deux n'est le jeton d'opérateur. N'écrasez pas cette réponse simplement pour l'inspecter à nouveau : vous aurez besoin de son identifiant de bail précis pour mettre fin à l'accès.
L'option -r retire les guillemets JSON. Les substitutions de commande entre guillemets chargent le nom d'utilisateur et le mot de passe générés dans l'environnement du client de base de données sans afficher le mot de passe :
export PGUSER="$(jq -r .data.username lease.json)"
export PGPASSWORD="$(jq -r .data.password lease.json)"
psql -X ignore les fichiers personnels de démarrage de psql, -v ON_ERROR_STOP=1 arrête sur les erreurs SQL et -c fournit une commande SQL. Demandez à la véritable connexion quelle identité elle utilise :
psql -X -v ON_ERROR_STOP=1 -c 'SELECT current_user;'
Votre nouveau nom d'utilisateur généré est attendu. -f report.sql lit la requête préparée ; > enregistre sa véritable sortie séparée par des tabulations :
psql -X -v ON_ERROR_STOP=1 -f report.sql > settlement.tsv
cat settlement.tsv
Les trois lignes de vendeurs sont attendues, avec les mêmes nombres de commandes payées et les mêmes totaux que dans l'exemple fonctionnel. Exécutez le contrôle de résultat en lecture seule :
sudo python3 /opt/labex-report/verify.py result
Le contrôleur préparé utilise sudo pour lire les éléments natifs protégés et tester le SQL de politique dans un environnement isolé sous compte ordinaire. Il n'émet pas vos identifiants réels et ne génère pas le rapport. Une démonstration copiée sans véritable requête de rapport sous l'identité émise ne passe pas.
Si votre lecture prend du temps et que l'accès expire avant l'exécution du rapport, demandez un remplacement une seule fois, rechargez les deux variables de base de données et relancez les commandes d'identité et de rapport. Pour une émission existante à laquelle vous comptez encore mettre fin explicitement, conservez sa réponse sous un nom de fichier distinct avant d'en demander une autre. Chaque remplacement utilisé pour exécuter le rapport doit lui aussi avoir son bail précis terminé ; l'achèvement se fonde sur la dernière exécution réelle du rapport.
Révoquer le bail précis de la tâche terminée
Dans cette étape, vous mettrez fin à l'accès de la tâche de rapport et testerez une nouvelle connexion avec les anciens identifiants enregistrés. Restez dans Terminal.
bao lease revoke demande la révocation d'une émission. La substitution entre guillemets $(jq -r .lease_id lease.json) fournit l'identifiant complet du bail enregistré. Utilisez cet identifiant précis, pas un nom d'utilisateur de base de données ni un préfixe contenant d'autres baux. Si cette émission de dix minutes a déjà expiré pendant votre lecture, la révocation peut signaler que son bail est introuvable. Pour l'exercice de révocation explicite, conservez cette ancienne réponse, obtenez de nouveaux identifiants du rôle normal sous un autre nom de fichier, rechargez les deux variables de base de données, relancez le rapport et utilisez le nom du fichier de remplacement dans la commande et la sonde ci-dessous. Une émission déjà expirée ne prouve pas votre révocation explicite :
bao lease revoke "$(jq -r .lease_id lease.json)"
La CLI peut indiquer que les opérations de révocation ont été mises en file d'attente. Cette réponse seule n'établit pas que PostgreSQL a refusé l'ancien accès.
La sonde préparée access.py lit les identifiants enregistrés et ouvre une nouvelle connexion TCP authentifiée par mot de passe. --wait-denied 10 accorde jusqu'à dix secondes pour obtenir un refus de mot de passe. Elle distingue ce refus d'une base indisponible ou d'une requête SQL refusée ; arrêter le serveur ne peut pas la satisfaire :
python3 /opt/labex-report/access.py lease.json --wait-denied 10
Le message PostgreSQL password authentication failed est attendu, suivi de la confirmation que ces identifiants enregistrés ne peuvent pas ouvrir une nouvelle connexion. La sonde signale le code psql natif 2. La sonde elle-même renvoie une réussite uniquement après avoir confirmé le refus attendu.
echo $? affiche le code de sortie de la commande immédiatement précédente. Ici, le résultat attendu est 0 : la sonde a confirmé avec succès l'échec souhaité, plutôt que psql ne se soit connecté avec succès :
echo $?
Contrôlez la tâche terminée :
sudo python3 /opt/labex-report/verify.py finished
Le contrôle exige une révocation native réussie du bail précis, l'événement correspondant de révocation terminée, un échec ultérieur de nouvelle authentification et un accès PostgreSQL effectivement inutilisable. Il conserve également le rapport complet et les fonctions indépendantes de boutique et de rapport. Il ne révoque rien à votre place.
Cet exercice teste les nouvelles connexions de commandes clientes de courte durée. L'expiration du mot de passe ne force pas la fermeture de toutes les connexions déjà ouvertes, et cette leçon ne prétend pas vider tous les pools de connexions en production.
Observer l'expiration naturelle d'un bail distinct
Dans cette étape, vous distinguerez l'expiration naturelle de votre révocation explicite. Utilisez Terminal avec le même opérateur OpenBao restreint.
Le rôle préparé settlement-short possède un TTL de trente secondes. Vous demanderez ses identifiants et testerez immédiatement une véritable lecture autorisée en une seule opération, afin que la lecture de l'explication suivante ne consomme pas sa durée utile. && n'exécute la sonde que si l'émission des identifiants réussit :
bao read -format=json database/creds/settlement-short > short-lease.json && python3 /opt/labex-report/access.py short-lease.json
Un nom d'utilisateur généré, la véritable vue de règlement à trois lignes et Native psql exit: 0 sont attendus. Ce nom d'utilisateur et cet identifiant de bail diffèrent de ceux de la tâche explicitement révoquée. La sonde en lecture seule ne crée pas votre fichier de rapport et ne termine pas la tâche de rapport à votre place.
Laissez maintenant ce bail expirer de lui-même. Ne révoquez pas et ne renouvelez pas short-lease.json. La sonde suivante ouvre à répétition de nouvelles connexions, en attendant jusqu'à quarante secondes un véritable refus d'authentification par mot de passe :
python3 /opt/labex-report/access.py short-lease.json --wait-denied 40
Si votre lecture avant cette commande a pris plus de trente secondes, le refus peut apparaître immédiatement. Il s'agit toujours d'une expiration naturelle : l'opération combinée précédente a déjà prouvé que les identifiants fonctionnaient initialement. Sinon, la sonde attend l'expiration. L'échec PostgreSQL natif et la confirmation de la sonde sont attendus, comme précédemment.
Une erreur de connexion indiquant que le serveur est indisponible ne prouve pas l'expiration. Si l'émission initiale ou sa lecture immédiate a échoué, examinez cette erreur avant de réessayer l'opération combinée. Ne présentez pas un mot de passe invalide et inutilisé comme preuve de l'expiration d'identifiants fonctionnels. Le contrôle final exige la véritable lecture réussie avec le rôle court, l'événement natif d'expiration et le refus ultérieur d'authentification.
Le décompte du bail a été démarré par votre demande, pas par l'initialisation, et aucune étape ne vous impose de saisir des commandes dans une fenêtre de démarrage fortuite.
Reprendre avec de nouveaux identifiants et terminer aussi leur accès
Dans cette étape, vous terminerez une nouvelle tentative de rapport après que les anciens identifiants ont cessé de fonctionner. Restez dans Terminal. La reprise consiste à obtenir de nouveaux identifiants via le service autorisé ; modifier une ancienne réponse ne renouvelle pas son identité de base de données.
Enregistrez la nouvelle émission du rôle normal sous un autre nom pour conserver les éléments précédents :
bao read -format=json database/creds/settlement-report > recovery-lease.json
Chargez cette nouvelle identité et exécutez le même véritable rapport :
export PGUSER="$(jq -r .data.username recovery-lease.json)"
export PGPASSWORD="$(jq -r .data.password recovery-lease.json)"
psql -X -v ON_ERROR_STOP=1 -f report.sql > settlement.tsv
cat settlement.tsv
Le résultat métier complet reste inchangé. Le nom d'utilisateur de base de données est nouveau, ce qui constitue la reprise attendue après la fin d'une ancienne émission.
Mettez également fin au bail précis de cette tâche de remplacement :
bao lease revoke "$(jq -r .lease_id recovery-lease.json)"
python3 /opt/labex-report/access.py recovery-lease.json --wait-denied 10
Si vous relancez le rapport avec un autre accès de remplacement, mettez aussi fin à ce bail précis. Le contrôle final utilise l'identité de la dernière exécution réelle du rapport ; un compte révoqué auparavant ne prouve donc pas qu'une tâche ultérieure a pris fin.
Le client de boutique préparé utilise son identité d'écriture indépendante. Confirmez que la commande normale du jour est conservée :
python3 shop.py list
Exécutez le contrôle final du cycle de vie :
sudo python3 /opt/labex-report/verify.py lifecycle
Il lit les événements natifs existants d'émission, de requête, de révocation et d'authentification avant de procéder à des sondes de préservation en lecture seule. Vous devez obtenir une confirmation d'éléments distincts de révocation explicite, d'expiration naturelle et de reprise avec des identifiants de remplacement, les anciens identifiants testés ne pouvant plus ouvrir de nouvelles connexions. Les données d'origine du rapport, la boutique et les identifiants d'inventaire indépendants doivent rester intacts.
Si une commande de rapport échoue parce qu'un remplacement a expiré pendant votre lecture, conservez cette réponse, demandez un autre remplacement sous un nouveau nom de fichier, rechargez ses variables de base de données, relancez le rapport et mettez fin à ce nouveau bail précis. Utilisez les mêmes commandes enseignées avec ce nom de fichier. Ne prolongez pas l'expiration de l'ancien nom d'utilisateur et ne révoquez pas tout un préfixe de rôle.
Résumé
Vous avez exécuté un véritable rapport, mis fin à son bail précis, observé l'expiration naturelle d'identifiants distincts et repris l'activité avec une nouvelle identité émise dont vous avez aussi terminé l'accès de tâche. Vous avez distingué une demande mise en file d'attente d'un refus réel de la base, et un service arrêté d'un mot de passe refusé.
Le résultat est volontairement limité aux nouvelles connexions authentifiées par mot de passe dans cet environnement préparé. Il n'affirme pas que toutes les sessions déjà ouvertes ou tous les pools de production ont été fermés. Le challenge combine la politique de permissions et le cycle de vie d'une tâche terminée pour une autre vue de rapport.
