Einen Auftrag mit einem eingeschränkten API-Schlüssel wieder ausführen

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.

Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.

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. Wechsle zum Tab Workstation. Sende 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. Der Header Content-Type: application/json teilt dem Dienst mit, dass der Anfrageinhalt JSON verwendet. Das leere Objekt {} genügt, da der Anbieter zuerst die Berechtigung ablehnt und erst danach den Inhalt prüfen würde:

Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.

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.

Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.

Ein Name ist eine hilfreiche Kennzeichnung; nur die Scopes bestimmen die Rechte.

Eigene Zugangsdaten ausstellen

Wechsle zum Tab Workstation. Zeige das Operator-Token mit cat an, das eine Datei ausgibt:

Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.

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

Wechsle zum Tab Key Manager. Trage den Wert unter Operator token ein, wähle Sign in und dann Open Key Manager. Die Operator-Authentifizierung ist von Anwendungsschlüsseln getrennt. Bestätige, dass 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.

Wähle Issue key. Die Oberfläche zeigt eine nicht geheime Schlüssel-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. Wähle für alle folgenden Befehle den Tab Integration.

Wähle zu Beginn dieses Schritts den Tab Integration in der Lab-Oberfläche aus.

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. Wechsle zum Tab Integration. Zeige die aktuelle Konfiguration:

Wechsle zum Tab Integration, bevor du den folgenden Befehl ausführst.

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 folgenden Befehl im Tab 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.

Wähle zu Beginn dieses Schritts den Tab Integration in der Lab-Oberfläche aus.

Wechsle zum Tab Integration. Starte den zugewiesenen Stapel:

Wechsle zum Tab Integration, bevor du den folgenden Befehl ausführst.

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. Wechsle bei Bedarf zu Key Manager, widerrufe einen falsch berechtigten Ersatz und stelle einen korrekt berechtigten aus. Wechsle zurück zu Integration und wiederhole Schritt 3 mit dem neuen Geheimwert, bevor du den Stapel erneut ausführst. 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.

Falls du zu Key Manager gewechselt bist, um Schlüssel-IDs zu vergleichen oder Scopes zu korrigieren, wechsle jetzt zurück zum Tab Integration. 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

Wechsle zum Tab Workstation. Prüfe, ob der alte Schlüssel unbrauchbar und der Monitor gesund bleibt:

Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.

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.