Einen Auftrag mit eingeschränktem Schlüssel wiederherstellen

Einführung

Der offengelegte Support-Schlüssel ist widerrufen. Der Dienst ist verfügbar, doch der Zusammenfassungsauftrag kann sich nicht authentifizieren, weil seine private Konfiguration noch den alten Wert enthält. Für den ausstehenden Stapel daily fehlt weiterhin die Zusammenfassung.

Du lernst Scopes kennen, stellst einen Ersatz aus, aktualisierst die private Worker-Konfiguration und führst den Geschäftsvorgang aus. Außerdem testest du den weiterhin verbotenen Kundenzugriff und den unabhängigen Monitor. Dieses Lab stellt einen eigenen Zustand nach der Eindämmung bereit und verwendet die vorherige VM nicht weiter.

Zugangsdaten mit Leserechten testen

In diesem Schritt unterscheidest du ungültige Zugangsdaten von gültigen mit unzureichenden Rechten. Die neue Umgebung beginnt nach der Eindämmung: key_support_old ist widerrufen, der Auftrag nutzt noch seinen alten Geheimwert und daily wurde nicht verarbeitet. Dateien oder VM des vorherigen Labs werden nicht benötigt. Schlüssel und Operator-Token gehören zu dieser VM; ermittle die Werte hier, statt Zugangsdaten einer früheren Umgebung wiederzuverwenden.

Workstation ist das Wartungsterminal in /home/labex/project/repository. Integration läuft als keyworker in /home/labex/project. Key Manager ist die Verwaltungsoberfläche des Anbieters. Die lokale Übungs-API unter http://127.0.0.1:8000 hat ein synthetisches, kursspezifisches Verhalten.

Ein Scope erlaubt eine benannte Operation. Minimale Rechte bedeuten, nur nötige Aktionen zuzulassen und unabhängige Aktionen auszuschließen. Das Zusammenfassungsprogramm liest Tickets und veröffentlicht Zusammenfassungen; es liest kein Kundenverzeichnis.

Einen Berechtigungsfehler erkennen

Ein vorbereiteter Demo-Leseschlüssel ist gültig, darf aber nicht veröffentlichen. Sende in Workstation damit eine Veröffentlichungsanfrage. curl -X POST wählt die Schreiboperation, -H übergibt Header, -d den JSON-Textkörper, -s verbirgt Fortschritt und -w zeigt den Status. Das leere Objekt {} genügt, da der Anbieter zuerst die Berechtigung ablehnt und erst danach den Inhalt prüfen würde: Der Header Content-Type: application/json teilt dem Dienst mit, dass der Anfrageinhalt JSON verwendet.

curl -s -w '\nHTTP %{http_code}\n' -X POST -H 'Authorization: Bearer lab_demo_read_only' -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:8000/v1/summaries

{"error":"Missing scope","required":"summaries:write"}
HTTP 403

Hier bedeutet 403, dass die Zugangsdaten authentifiziert sind, aber der nötige Scope fehlt. 401 weist dagegen die Zugangsdaten selbst zurück. Ein Leseschlüssel erledigt keinen Lese-und-Schreibauftrag; ein Vollzugriffsschlüssel erlaubt zu viel. Dein Ersatz braucht die beiden Geschäfts-Scopes aus der Tabelle.

Einen eigenen Ersatz ausstellen

In diesem Schritt stellst du einen eigenen Ersatz mit den zuvor ausgewählten beiden Scopes aus. Seinen Geheimwert speicherst du im nächsten Schritt privat. Der Name ist eine hilfreiche Kennzeichnung; nur die Scopes bestimmen die Rechte.

Eigene Zugangsdaten ausstellen

Zeige in Workstation das Operator-Token mit dem dateilesenden Befehl cat an:

cat /home/labex/.config/keylab/operator-token

Trage es in Key Manager unter Operator token ein, wähle Sign in, danach Open Key Manager. Operator-Anmeldung und Anwendungsschlüssel sind getrennt. Prüfe, ob key_support_old bereits Revoked ist.

Trage unter Issue a key für Name den Wert Support summary replacement ein. Wähle nur tickets:read und summaries:write, dann Issue key. Die Oberfläche zeigt eine nicht geheime ID sowie Secret shown once. Kopiere den mit lab_key_ beginnenden Geheimwert, bevor du die Seite verlässt. Der Anbieter speichert einen Hash statt eines wieder abrufbaren Geheimwerts. Ein Hash ist ein Einweg-Fingerabdruck: Er ermöglicht den Vergleich eines übergebenen Werts, ohne das gespeicherte Original anzuzeigen.

Geht der Wert verloren, widerrufe den unbenutzten Schlüssel anhand seiner ID und stelle einen neuen aus. Verwende weder den offengelegten Wert erneut noch erweitere Rechte zur Behebung eines Kopierfehlers.

Die private Laufzeitkonfiguration speichern

In diesem Schritt speicherst du den Ersatz in der privaten Laufzeitdatei des Dienstkontos und prüfst deren Zugriffsrechte. Verwende für alle folgenden Befehle Integration.

Eine Laufzeitkonfiguration ist die Datei, die das Programm beim Ausführen liest. Dieser Worker liest /home/labex/project/runtime/job.ini bei jedem Aufruf; ein Neustart ist unnötig. Die Beispieldatei im Repository ist eine andere Datei. Zeige in Integration die aktuelle Konfiguration:

cat /home/labex/project/runtime/job.ini

[integration]
api_key = lab_key_support_exposed

Halte Geheimwerte aus Repository und Befehlsverlauf heraus. Bash read nimmt einen Wert an einer Eingabeaufforderung an: -r erhält wörtliche Zeichen, -s verbirgt die Eingabe und -p zeigt eine Aufforderung. API_KEY ist eine vorübergehende Shellvariable. Führe den Befehl in Integration aus, füge den neuen Geheimwert an der Aufforderung ein und drücke Enter. Die Eingabe bleibt unsichtbar:

read -r -s -p 'Replacement key: ' API_KEY

printf schreibt formatierten Text. \n erzeugt Zeilenumbrüche, %s setzt den Variablenwert ein, doppelte Anführungszeichen erhalten ihn als ein Argument und > ersetzt die genannte Datei. Die vorhandene private Datei gehört keyworker, dem Konto dieses Terminals:

printf '[integration]\napi_key = %s\n' "$API_KEY" > /home/labex/project/runtime/job.ini

Setze mit chmod die Zugriffsrechte. Modus 600 erlaubt nur dem Eigentümer Lesen und Schreiben; Gruppe und andere Konten erhalten keinen Zugriff:

chmod 600 /home/labex/project/runtime/job.ini

ls -l zeigt Eigentümer und Rechte, ohne den Geheimwert auszugeben:

ls -l /home/labex/project/runtime/job.ini

Achte auf -rw------- und Eigentümer keyworker. Größe und Datum können variieren. Eine Shellvariable allein aktualisiert die Datei nicht; erst die gespeicherte Laufzeitdatei lässt den nächsten Worker-Aufruf die neuen Zugangsdaten verwenden.

Lass dieses Integration-Terminal offen. API_KEY gehört zu dieser Shell, nicht zu allen Terminals. Der nächste Schritt nutzt die Variable für unabhängige Anfragen und entfernt sie danach. Schließt du das Terminal oder verbindest es neu, wiederhole diesen Schritt mit dem aktuellen Geheimwert aus job.ini, den der obige cat-Befehl zeigt.

Den Geschäftslauf abschließen und prüfen

In diesem Schritt verarbeitest du den ausstehenden Stapel daily und testest erlaubte und verbotene Aktionen. Der Worker ist vorbereitet: Lass /opt/keylab/worker.py unverändert. Du stellst Zugangsdaten wieder her, statt das Programm zur Umgehung der Authentifizierung umzubauen.

Starte in Integration den zugewiesenen Stapel:

python3 /opt/keylab/worker.py daily

Read batch: daily (3 items)
{"batch":"daily","count":3,"subjects":["Reset password","Invoice copy","Delivery question"]}
Received batch: daily
Receiving key ID: ...

Die empfangende ID muss zur Ersatz-ID in Key Manager passen. Prüfe bei 401, ob der gespeicherte Geheimwert zum aktiven Ersatz gehört; vergleiche bei 403 die Scopes mit der Endpoint-Tabelle. Widerrufe gegebenenfalls einen falsch berechtigten Ersatz, stelle einen korrekten aus, aktualisiere die private Datei und wiederhole den Stapel. Die Wiederholung ersetzt den Empfangsdatensatz, statt doppelte Zusammenfassungen zu erzeugen.

Den tatsächlichen Empfängerdienst prüfen

Bleibe im selben Integration-Terminal. Die Variable API_KEY aus dem vorigen Schritt ist hier noch verfügbar; du musst den einmal angezeigten Geheimwert nicht erneut eingeben.

Verwende den nur lesenden Ergebnis-Endpoint. Eine Pipeline | übergibt die Antwort an das nächste Programm; python3 -m json.tool startet Pythons JSON-Formatierer für gut lesbare Einrückung:

curl -s -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/results | python3 -m json.tool

Suche daily, seine drei Betreffzeilen in payload und die key_id deines Ersatzes. Dieser Datensatz stammt von der empfangenden API, nicht aus einer lokalen Erfolgsdatei. Das Backend protokolliert auch die Zugangsdaten für das Lesen der Quelldaten.

Teste nun den verbotenen Zugriff auf das Kundenverzeichnis:

curl -s -w '\nHTTP %{http_code}\n' -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/customers

{"error":"Missing scope","required":"customers:read"}
HTTP 403

Diese erwartete Ablehnung bestätigt die Einschränkung. Entferne die temporäre Shellvariable mit unset, sobald du sie nicht mehr brauchst; die gespeicherte Laufzeitdatei bleibt unverändert:

unset API_KEY

Prüfe in Workstation, ob der alte Schlüssel unbrauchbar und der Monitor gesund bleibt:

curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' http://127.0.0.1:8000/v1/tickets

{"error":"Invalid or revoked key"}
HTTP 401

curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_monitor_only' http://127.0.0.1:8000/v1/health

{"status":"ok","integration":"monitor"}
HTTP 200

Abschließend listet git status --short geänderte oder nicht verfolgte Repository-Dateien kompakt auf:

git status --short

Der angeleitete Weg erzeugt keine Ausgabe, da du nur die private Laufzeitdatei bearbeitet hast. Speichere den Ersatz nie in einem Beispiel oder Commit. Wie das erste Lab zeigt, kann der Verlauf Geheimwerte nach dem Entfernen ihrer sichtbaren Zeilen erhalten.

Zusammenfassung

Du hast Authentifizierungsfehler von fehlenden Rechten unterschieden, ein Lese- und Schreibrechtepaar gewählt, einen einmal angezeigten Geheimwert privat gespeichert und die ausstehende Zusammenfassung abgeschlossen. Du hast Empfangsdatensatz, Ablehnung des alten Schlüssels, verbotenen Kundenzugriff und Monitor-Verfügbarkeit geprüft. Eine wirksame Rotation stellt legitime Arbeit wieder her und beendet den Zugriff der offengelegten Zugangsdaten.