Einführung
Ein Abrechnungsbericht braucht während seiner Ausführung Datenbankzugriff. Sobald der Auftrag abgeschlossen ist, sollen seine gespeicherten Zugangsdaten keine neuen Verbindungen mehr öffnen können. Eine Annahmemeldung eines Dienstes zur Verwaltung von Secrets reicht als Nachweis dieses Ergebnisses nicht aus.
Diese unabhängige MarketLedger-Umgebung beginnt mit den richtigen Sichtberechtigungen. Du führst den Bericht aus, widerrufst seine genaue OpenBao-Lease, beobachtest das natürliche Ablaufen einer separaten Lease und stellst den Zugriff mit einer neuen Anmeldung wieder her. Der Shop und sein unabhängiger Inventarbericht müssen nutzbar bleiben. Das vorherige geführte Lab hat die Zugangsdatenfelder und die eingeschränkte Berichtsrichtlinie vermittelt; Dateien oder Sitzungszustand werden nicht übernommen.
Mit dem funktionierenden Shop und der richtigen Berichtsrichtlinie beginnen
In diesem Schritt ermittelst du den normalen Geschäftsbetrieb und die zwei Berichtsrollen, bevor du eine ihrer Lease-Uhren startest. Verwende durchgehend Terminal. Gehe in das unabhängige Arbeitsverzeichnis:
cd /home/labex/project/market-report
cat gibt das vorbereitete funktionierende Beispiel aus:
cat demo.tsv
Die Abrechnung umfasst 2026-10-28: Birch hat zwei bezahlte Bestellungen mit insgesamt 4700 Cent, Elm eine mit 2000 und Maple eine mit 2700. Die stornierte Bestellung ist ausgeschlossen. Der Bericht verwendet reporting.daily_settlement; private Kunden-E-Mails und Bankreferenzen liegen außerhalb seines Umfangs.
Der vorbereitete Shopclient spricht mit dem echten Shopdienst. Seine Argumente bezeichnen eine neue Bestellung, einen Anbieter und einen Betrag in Cent. Gib eine normale Bestellung für das nächste synthetische Handelsdatum 2026-10-29 auf:
python3 shop.py place --order O201 --vendor V101 --cents 600
Diese spätere Bestellung gehört nicht in die gestrige Abrechnung. Wiederholst du den Befehl, lehnt der Dienst das Duplikat ab; sieh dir mit python3 shop.py list die bestehende Bestellung an, statt sie zu löschen.
Das bereitgestellte env.sh enthält die lokalen Dienstadressen und liest das eingeschränkte Operator-Token aus seiner privaten Datei. source lädt diese Zuweisungen in die aktuelle Shell; export stellt sie untergeordneten Befehlen zur Verfügung. Ein neues Terminal muss sie erneut laden:
source env.sh
Das Operator-Token autorisiert OpenBao-Anfragen; es ist kein Datenbankpasswort. Dieses Token kann die genauen Leases der Rollen settlement-report und settlement-short beziehen und widerrufen. Es kann weder den unabhängigen Inventarbericht verwalten noch die Datenbankadministratorverbindung lesen.
Lies die korrekten Kontoerstellungsanweisungen:
cat role.sql
Sie erstellen eine generierte Anmeldung mit dem übergebenen Passwortablaufzeitpunkt, erlauben das Nachschlagen im Schema und gewähren Lesezugriff auf die Abrechnungssicht und erhalten die native SQL-Protokollierung. Lass diese Anweisungen und beide Rollenkonfigurationen in diesem Lab unverändert.
Die normale Berichtsrolle hat standardmäßig zehn Minuten. Eine separat vorbereitete Rolle settlement-short gilt dreißig Sekunden und hat dieselben Sichtberechtigungen. Keine Uhr startet, bevor du Zugangsdaten anforderst. Du musst nicht durch die Lektion hetzen, bevor bei der Einrichtung erstellte Zugangsdaten ablaufen.
Du darfst Zugangsdaten dieser Rollen ausstellen lassen, die bereitgestellte Berichtsabfrage ausführen, den Bericht und private Zugangsdatenantworten speichern sowie die genauen Berichts-Leases widerrufen, die du bezogen hast. Erhalte die ursprünglichen Datenbankdatensätze, den Shop, die unabhängige Inventarrolle samt Lease, die bereitgestellte Abfrage, Umgebung, Operator-Token und vorbereitete Laufzeitumgebung. Widerrufe niemals ein ganzes Lease-Präfix.
Bei einem Tippfehler im Pfad kehre mit dem obigen absoluten cd zurück, führe ls aus und versuche es mit dem tatsächlichen Dateinamen erneut. Diese Wiederherstellung funktioniert ohne Zurücksetzen der Umgebung.
Die Abrechnung mit einer neuen temporären Anmeldung ausführen
In diesem Schritt erstellst du einen echten Bericht, bevor du den Zugriff dieses Auftrags beendest. Bleibe in Terminal mit geladenem env.sh.
umask 077 macht neu erstellte Dateien nur deinem Konto zugänglich. bao read -format=json fordert echte dynamische Zugangsdaten an und gibt JSON aus; > speichert es in einer Datei, statt das Passwort auszugeben. Diese Ausstellung startet die zehnminütige Lease-Uhr:
umask 077
bao read -format=json database/creds/settlement-report > lease.json
jq wählt JSON-Felder aus. Lies die nicht geheime Lease-ID, Dauer und den generierten Datenbankbenutzernamen:
jq '.lease_id, .lease_duration, .data.username' lease.json
Die Lease-ID identifiziert diese Ausstellung in OpenBao; der Benutzername identifiziert ihre PostgreSQL-Anmeldung. Keines von beiden ist das Operator-Token. Überschreibe diese Antwort nicht bloß, um sie erneut anzusehen: Du brauchst ihre genaue Lease-ID zum Beenden des Zugriffs.
Die Option -r entfernt JSON-Anführungszeichen. Befehlsersetzungen in Anführungszeichen laden den generierten Benutzernamen und das Passwort in die Umgebung des Datenbankclients, ohne das Passwort auszugeben:
export PGUSER="$(jq -r .data.username lease.json)"
export PGPASSWORD="$(jq -r .data.password lease.json)"
psql -X ignoriert persönliche psql-Startdateien, -v ON_ERROR_STOP=1 stoppt bei SQL-Fehlern, und -c übergibt einen SQL-Befehl. Frage die echte Verbindung, welche Identität sie verwendet:
psql -X -v ON_ERROR_STOP=1 -c 'SELECT current_user;'
Erwarte deinen neu generierten Benutzernamen. -f report.sql liest die vorbereitete Abfrage; > speichert ihre tatsächliche tabulatorgetrennte Ausgabe:
psql -X -v ON_ERROR_STOP=1 -f report.sql > settlement.tsv
cat settlement.tsv
Erwarte alle drei Anbieterzeilen mit denselben Anzahlen bezahlter Bestellungen und Summen wie im funktionierenden Beispiel. Führe die schreibgeschützte Ergebnisprüfung aus:
sudo python3 /opt/labex-report/verify.py result
Die vorbereitete Prüfung verwendet sudo, um geschützte native Nachweise zu lesen und Richtlinien-SQL in einer isolierten Testumgebung mit gewöhnlichem Konto zu testen. Sie stellt deine eigentlichen Zugangsdaten nicht aus und erzeugt den Bericht nicht. Ein kopiertes Beispiel ohne echte Berichtsabfrage unter der ausgestellten Identität besteht nicht.
Liest du langsam und die Anmeldung läuft vor der Berichtsausführung ab, fordere nur einmal Ersatz an, lade beide Datenbankvariablen erneut und wiederhole die Identitäts- und Berichtsbefehle. Für eine vorhandene Ausstellung, die du weiterhin ausdrücklich beenden möchtest, bewahre ihre Antwort unter einem separaten Dateinamen auf, bevor du eine weitere anforderst. Für jeden Ersatz, mit dem der Bericht ausgeführt wird, muss ebenfalls die eigene genaue Lease beendet werden; der Abschluss verwendet die letzte echte Berichtsausführung.
Die genaue Lease des abgeschlossenen Auftrags widerrufen
In diesem Schritt beendest du den Zugriff des Berichtsauftrags und testest eine neue Verbindung mit den gespeicherten alten Zugangsdaten. Bleibe in Terminal.
bao lease revoke fordert den Widerruf einer Ausstellung an. Die Ersetzung $(jq -r .lease_id lease.json) in Anführungszeichen übergibt die vollständige gespeicherte Lease-ID. Verwende genau diese ID, keinen Datenbankbenutzernamen und kein Präfix, das andere Leases enthält. Ist diese zehnminütige Ausstellung während des Lesens bereits abgelaufen, kann der Widerruf melden, dass ihre Lease nicht mehr gefunden wird. Bewahre für die Übung zum ausdrücklichen Widerruf diese alte Antwort auf, beziehe Ersatzzugangsdaten der normalen Rolle unter einem neuen Dateinamen, lade beide Datenbankvariablen erneut, führe den Bericht erneut aus und verwende den Ersatzdateinamen im Befehl und der Probe unten. Eine bereits abgelaufene Ausstellung ist kein Nachweis deines ausdrücklichen Widerrufs:
bao lease revoke "$(jq -r .lease_id lease.json)"
Die CLI kann melden, dass Widerrufsvorgänge eingereiht wurden. Diese Antwort allein belegt nicht, dass PostgreSQL die alte Anmeldung abgelehnt hat.
Die vorbereitete Probe access.py liest die gespeicherten Zugangsdaten und öffnet eine neue passwortauthentifizierte TCP-Verbindung. --wait-denied 10 lässt bis zu zehn Sekunden für eine Passwortablehnung zu. Sie unterscheidet diese Ablehnung von einer nicht verfügbaren Datenbank oder einer abgelehnten SQL-Abfrage; den Server zu stoppen kann sie nicht erfüllen:
python3 /opt/labex-report/access.py lease.json --wait-denied 10
Erwarte die PostgreSQL-Meldung password authentication failed, gefolgt von der Bestätigung, dass diese gespeicherten Zugangsdaten keine neue Verbindung öffnen können. Die Probe meldet den nativen psql-Status 2. Die Probe selbst meldet erst Erfolg, nachdem sie die erwartete Ablehnung bestätigt hat.
echo $? gibt den Rückgabestatus des unmittelbar vorherigen Befehls aus. Erwarte hier 0: Die Probe hat den beabsichtigten Fehlschlag erfolgreich bestätigt, nicht psql erfolgreich verbunden:
echo $?
Prüfe den abgeschlossenen Auftrag:
sudo python3 /opt/labex-report/verify.py finished
Die Prüfung verlangt einen nativen erfolgreichen Widerruf der genauen Lease, das zugehörige abgeschlossene Widerrufsereignis, einen späteren neuen Authentifizierungsfehler und eine tatsächlich unbenutzbare PostgreSQL-Anmeldung. Außerdem bewahrt sie den vollständigen Bericht und die unabhängigen Shop-/Berichtsfunktionen. Sie widerruft nichts für dich.
Diese Übung testet neue Verbindungen kurzlebiger Clientbefehle. Das Ablaufen eines Passworts erzwingt nicht das Schließen jeder bereits offenen Verbindung, und diese Lektion behauptet nicht, alle produktiven Verbindungspools zu leeren.
Eine separate Lease natürlich ablaufen lassen
In diesem Schritt unterscheidest du natürliches Ablaufen von deinem ausdrücklichen Widerruf. Verwende Terminal mit demselben eingeschränkten OpenBao-Operator.
Die vorbereitete Rolle settlement-short hat eine TTL von dreißig Sekunden. Du forderst ihre Zugangsdaten an und testest sofort einen echten erlaubten Lesezugriff in einem Vorgang, damit das Lesen der folgenden Erklärung keine nutzbare Zeit verbraucht. && führt die Probe nur aus, wenn die Zugangsdaten-Ausstellung erfolgreich ist:
bao read -format=json database/creds/settlement-short > short-lease.json && python3 /opt/labex-report/access.py short-lease.json
Erwarte einen generierten Benutzernamen, die tatsächliche Abrechnungssicht mit drei Zeilen und Native psql exit: 0. Benutzername und Lease-ID unterscheiden sich vom ausdrücklich widerrufenen Auftrag. Die schreibgeschützte Probe erstellt deine Berichtsdatei nicht und schließt den Berichtsauftrag nicht für dich ab.
Lass diese Lease nun von selbst ablaufen. Widerrufe oder erneuere short-lease.json nicht. Die folgende Probe öffnet wiederholt neue Verbindungen und wartet bis zu vierzig Sekunden auf eine echte Passwortauthentifizierungsablehnung:
python3 /opt/labex-report/access.py short-lease.json --wait-denied 40
Hast du vor diesem Befehl länger als dreißig Sekunden gelesen, kann die Ablehnung sofort erscheinen. Es ist trotzdem natürliches Ablaufen: Der vorherige kombinierte Vorgang hat bereits bewiesen, dass die Zugangsdaten anfangs funktionierten. Andernfalls wartet die Probe bis zum Ablauf. Erwarte wie zuvor den nativen PostgreSQL-Fehler und die Bestätigung der Probe.
Ein Verbindungsfehler, der einen nicht verfügbaren Server meldet, beweist keinen Ablauf. Scheitert die anfängliche Ausstellung oder ihr sofortiger Lesezugriff, untersuche diesen Fehler vor dem erneuten Versuch des kombinierten Vorgangs. Stelle ein unbenutztes ungültiges Passwort nicht als Nachweis dar, dass funktionierende Zugangsdaten abgelaufen sind. Die Abschlussprüfung verlangt den tatsächlichen erfolgreichen Lesezugriff der kurzen Rolle, das native Ablaufereignis und die spätere Authentifizierungsablehnung.
Die Lease-Uhr wurde durch deine Anforderung gestartet, nicht durch die Einrichtung, und kein Schritt verlangt Eingaben innerhalb eines zufälligen Startzeitfensters.
Mit einer neuen Anmeldung wiederherstellen und auch ihren Zugriff beenden
In diesem Schritt schließt du einen späteren Berichtsversuch ab, nachdem die alten Zugangsdaten nicht mehr funktionieren. Bleibe in Terminal. Wiederherstellen bedeutet, neue Zugangsdaten über den autorisierten Dienst zu beziehen; das Bearbeiten einer alten Antwort erneuert ihre Datenbankidentität nicht.
Speichere die neue Ausstellung der normalen Rolle unter einem anderen Namen, damit die bisherigen Nachweise erhalten bleiben:
bao read -format=json database/creds/settlement-report > recovery-lease.json
Lade diese neue Identität und führe denselben echten Bericht aus:
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
Das vollständige Geschäftsergebnis bleibt unverändert. Der Datenbankbenutzername ist neu; das ist der erwartete Wiederherstellungsweg nach dem Ende einer alten Ausstellung.
Beende auch die genaue Lease dieses Ersatzauftrags:
bao lease revoke "$(jq -r .lease_id recovery-lease.json)"
python3 /opt/labex-report/access.py recovery-lease.json --wait-denied 10
Führst du den Bericht mit einer weiteren Ersatzanmeldung erneut aus, beende auch deren genaue Lease. Die Abschlussprüfung verwendet die Identität hinter der letzten echten Berichtsausführung; ein früher widerrufenes Konto beweist deshalb nicht, dass ein späterer Auftrag beendet ist.
Der vorbereitete Shopclient verwendet seine unabhängige Schreibidentität. Bestätige, dass die heutige normale Bestellung erhalten bleibt:
python3 shop.py list
Führe die abschließende Lebenszyklusprüfung aus:
sudo python3 /opt/labex-report/verify.py lifecycle
Sie liest die vorhandenen nativen Ausstellungs-, Abfrage-, Widerrufs- und Authentifizierungsereignisse, bevor sie schreibgeschützte Erhaltungsproben ausführt. Erwarte die Bestätigung getrennter Nachweise für ausdrücklichen Widerruf, natürliches Ablaufen und Wiederherstellung mit einer Ersatzanmeldung; die getesteten alten Zugangsdaten können keine neuen Verbindungen öffnen. Die ursprünglichen Berichtsdaten, der Shop und die unabhängigen Inventarzugangsdaten müssen intakt bleiben.
Scheitert ein Berichtsbefehl, weil ein Ersatz während des Lesens abgelaufen ist, bewahre diese Antwort auf, fordere einen weiteren Ersatz unter einem neuen Dateinamen an, lade seine Datenbankvariablen erneut, führe den Bericht erneut aus und beende diese neue genaue Lease. Verwende dieselben vermittelten Befehle mit diesem Dateinamen. Verlängere weder den Ablaufzeitpunkt des alten Benutzernamens noch widerrufe ein ganzes Rollenpräfix.
Zusammenfassung
Du hast einen echten Bericht ausgeführt, seine genaue Lease beendet, das natürliche Ablaufen separater Zugangsdaten beobachtet und den Zugriff mit einer neu ausgestellten Identität wiederhergestellt, deren Auftragszugriff du ebenfalls beendet hast. Du hast eine eingereihte Anfrage von einer tatsächlichen Datenbankablehnung und einen gestoppten Dienst von einem abgelehnten Passwort unterschieden.
Das Ergebnis ist bewusst auf neue passwortauthentifizierte Verbindungen in dieser vorbereiteten Umgebung begrenzt. Es behauptet nicht, dass jede bereits offene Sitzung oder jeder produktive Verbindungspool beendet wurde. Die Challenge kombiniert Berechtigungsrichtlinie und Lebenszyklus abgeschlossener Aufträge für eine andere Berichtssicht.
