Einführung
Ein Support-Auftrag liest Kundentickets und veröffentlicht eine kurze Zusammenfassung. Jemand hat seinen API-Schlüssel aus dem aktuellen Repository-Beispiel entfernt, doch Anfragen mit diesem Wert funktionieren weiterhin. Du untersuchst als zuständige Wartungsperson die Warnung.
Zuerst lernst du den normalen Anfrageablauf kennen, dann findest du historische Hinweise, identifizierst die Zugangsdaten und widerrufst sie. Du arbeitest mit einem lokalen Übungsanbieter, zwei vorbereiteten Terminalrollen und Key Manager. Grundlegende Terminalkenntnisse genügen; Git, API-Anfragen und Schlüsselwiderruf werden erklärt.
Ein Ticket über die API lesen
In diesem Schritt sendest du eine Ticket-Leseanfrage und lernst, ihre Antwort zu erkennen. Ein Support-Ticket ist die Hilfsanfrage eines Kunden. Ein Zusammenfassungsauftrag ist ein vorbereitetes Programm, das einen Stapel Tickets liest und eine kurze Zusammenfassung an den Dienst zurücksendet. Integration bedeutet hier, dass ein Programm mit einem anderen zusammenarbeitet.
Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.
Dieses Lab verwendet einen lokalen Übungsanbieter mit synthetischen Kunden und Schlüsseln. Die API führt echte Authentifizierung und Berechtigungsprüfungen durch, bildet aber keinen Cloudanbieter nach. Echte Konten und externe Ziele werden nicht verwendet.
Die beiden Terminalrollen verwenden
Workstation ist dein Wartungsterminal. Es öffnet /home/labex/project/repository mit Beispielkonfigurationen. Integration läuft als keyworker, dem Eigentümer der privaten Laufzeitkonfiguration. Verwende für jeden Befehl das genannte Terminal; ein Verzeichniswechsel ändert das Konto nicht. Der Tab Key Manager verwaltet Zugangsdaten über eine separate Operator-Anmeldung.
In Workstation zeigt pwd das aktuelle Verzeichnis; ls listet dessen Dateinamen auf:
Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.
pwd
/home/labex/project/repository
ls
Du solltest README.md und summary-example.ini sehen. Das sind Repository-Beispiele, nicht die private Datei, die der laufende Auftrag liest.
Die Anfrageschnittstelle verstehen
Eine API ist die Schnittstelle eines Dienstes für Programmanfragen. Ein Endpoint verbindet eine Operation mit einem Pfad. Hier liest GET /v1/tickets Tickets und POST /v1/summaries veröffentlicht eine Zusammenfassung. http://127.0.0.1:8000 adressiert den lokalen Dienst dieser VM: 127.0.0.1 bedeutet diesen Rechner, 8000 ist der lauschende Port.
Anfragen tragen einen API-Schlüssel, also einen geheimen Wert zur Authentifizierung eines Programms. Er wird im Header Authorization gesendet, einem benannten Metadatum der Anfrage. Dieser Anbieter erwartet Bearer gefolgt vom Geheimwert. Halte die synthetischen Übungsschlüssel von echten Zugangsdaten getrennt.
Wechsle zum Tab Workstation. Sende eine Leseanfrage. curl sendet eine HTTP-Anfrage, -s blendet den Fortschritt aus und -H übergibt einen Header. Einfache Anführungszeichen halten Leerzeichen und das Abfragezeichen ? zusammen. batch=demo wählt den Übungsdatensatz:
curl -s -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
Die Antwort ist JSON, ein Format aus benannten Feldern und Werten. batch benennt den Datensatz, items ist eine Liste und das Ticket besitzt id und subject. request_id ist eine wechselnde Audit-Kennung, kein Geheimwert. Suche den Betreff Delivery question.
Eine Demo-Zusammenfassung veröffentlichen
In diesem Schritt verwendest du den vorbereiteten Worker, um die gelesenen Tickets als Zusammenfassung beim Dienst abzugeben. Der vorige Schritt las nur Daten; dieses Programm veröffentlicht zusätzlich das Ergebnis.
Wähle zu Beginn dieses Schritts den Tab Integration in der Lab-Oberfläche aus.
Wechsle zum Tab Integration. Starte den Worker für denselben Demonstrationsstapel. python3 führt das gelieferte Python-Programm aus; der Pfad benennt es und demo ist das Stapelargument. Für diesen Kurs musst du Python weder schreiben noch verstehen:
Wechsle zum Tab Integration, bevor du den folgenden Befehl ausführst.
python3 /opt/keylab/worker.py demo
Read batch: demo (1 items)
{"batch":"demo","count":1,"subjects":["Delivery question"]}
Received batch: demo
Receiving key ID: key_support_old
Die erste Anfrage las die Eingabe, die zweite veröffentlichte die Zusammenfassung. Received batch bedeutet, dass die empfangende API sie angenommen hat. Eine Schlüssel-ID wie key_support_old ist eine nicht geheime Kennung, anders als der Geheimwert im Header. Dieser Lauf zeigt den Normalbetrieb und erledigt nicht den zugewiesenen Stapel des späteren Wiederherstellungs-Labs.
Den historischen Schlüssel finden und widerrufen
In diesem Schritt findest du die historischen Zugangsdaten, ordnest ihre ID dem Anbieter-Eintrag zu und widerrufst genau diesen Schlüssel. Eine sichtbare Zeile zu löschen kann sie aus der aktuellen Datei entfernen, ohne die Zugangsdaten ungültig zu machen.
Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.
Erst die Gegenwart, dann die Vergangenheit lesen
Wechsle zum Tab Workstation. Zeige das aktuelle Beispiel mit cat an. Eine INI-Datei gruppiert Einstellungen unter Abschnitten in eckigen Klammern wie [integration]; jede Einstellung besteht aus Name, Gleichheitszeichen und Wert:
Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.
cat summary-example.ini
[integration]
key_id = key_support_old
api_key = SET_AT_RUNTIME
Der Platzhalter ist für ein teilbares Beispiel sinnvoll, sagt aber nichts über ältere Kopien oder den Schlüsselstatus beim Dienst aus.
Git speichert Projekt-Snapshots als Commits. Ein Repository enthält aktuelle Dateien und den Commit-Verlauf. git log zeigt die neuesten Commits zuerst; --oneline liefert eine kurze Zeile je Commit. Die globale Option --no-pager schreibt direkt ins Terminal, ohne einen interaktiven Betrachter zu öffnen:
git --no-pager log --oneline
Du siehst Document prepared worker, Remove credential from current example und Add integration example. Die kurzen Kennungen links können abweichen.
HEAD bezeichnet den neuesten Commit, HEAD~2 den zwei Commits davor. git show zeigt ein historisches Objekt; der Doppelpunkt trennt Revision und Dateiname:
git --no-pager show HEAD~2:summary-example.ini
[integration]
key_id = key_support_old
api_key = lab_key_support_exposed
Der ursprüngliche Geheimwert lässt sich weiterhin abrufen. Das aktuelle Beispiel zu löschen oder den lokalen Verlauf umzuschreiben teilt der API nicht mit, dass sie bereits kopierten Werten nicht mehr vertrauen soll.
Die Zugangsdaten dem Anbieter-Eintrag zuordnen
Key Manager verwendet ein Operator-Token als separate Wartungsberechtigung. Ein Anwendungsschlüssel kann keine Schlüssel verwalten. Wechsle zum Tab Workstation. Zeige das vorbereitete lokale Token an:
cat /home/labex/.config/keylab/operator-token
Wechsle zum Tab Key Manager, füge den Wert unter Operator token ein, wähle Sign in, danach Open Key Manager. Speichere dieses Token nicht im Repository. Wird die Anmeldung abgelehnt, wähle im selben Tab Return to Key Manager, wechsle zu Workstation, um das Operator-Token dieser VM erneut zu kopieren, und dann zurück zu Key Manager, um es erneut zu versuchen. Suche die Zeile key_support_old mit Status Active. Ihre Scopes beschreiben erlaubte Aktionen; im nächsten Lab lernst du deren Auswahl.
Suche unter Recent API requests eine erfolgreiche Anfrage dieses Schlüssels. Status 200 bedeutet eine angenommene Leseanfrage. Der Verlauf belegt die Offenlegung und die Anfrage die Funktionsfähigkeit der Zugangsdaten; beides identifiziert nicht den Urheber früherer Anfragen. Ein Bericht oder kopiertes Protokoll ist nicht erforderlich.
Den identifizierten Schlüssel widerrufen
Widerrufe nur den betroffenen Schlüssel. Ablehnung und unabhängige Verfügbarkeit testest du im nächsten Schritt. Der Widerruf ändert die Annahmeentscheidung des Anbieters; Kopien des Geheimwerts kann er nicht löschen.
Wechsle zum Tab Workstation. Fordere die Demo-Tickets erneut an und zeige diesmal den HTTP-Status. -w ergänzt formatierten Text, \n beginnt eine neue Zeile und %{http_code} setzt den Antwortstatus ein:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
Die Antwort endet mit HTTP 200. Wechsle zum Tab Key Manager. Wähle Revoke für key_support_old. Prüfe die ID sorgfältig: Alle Schlüssel zu widerrufen würde andere Aufgaben unterbrechen. Die Zeile sollte jetzt Revoked anzeigen.
Eindämmung und Verfügbarkeit testen
In diesem Schritt testest du, dass die alten Zugangsdaten abgelehnt werden und API sowie unabhängiger Monitor verfügbar bleiben. Der Manager-Status ist hilfreich, doch echte Anfragen belegen die Zugriffsgrenze.
Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.
Wiederhole dieselbe Anfrage im Tab Workstation:
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?batch=demo'
{"error":"Invalid or revoked key"}
HTTP 401
Bei dieser API bedeutet 401, dass die übergebenen Zugangsdaten nicht authentifiziert werden können. Diese erwartete Ablehnung bestätigt die Eindämmung. Ein Verbindungsfehler würde dagegen bedeuten, dass der Dienst nicht erreichbar ist; ihn zu stoppen behebt das Problem nicht.
Wechsle zum Tab Integration. Starte den Worker erneut:
Wechsle zum Tab Integration, bevor du den folgenden Befehl ausführst.
python3 /opt/keylab/worker.py demo
HTTP 401: {"error":"Invalid or revoked key"}
Dieser Befehl soll mit einem Fehlerstatus enden. Der Auftrag liest weiterhin den widerrufenen Wert aus seiner privaten Datei und kann keine Eingabe mehr lesen. Während der Eindämmung ist eine vorübergehende Pause zulässig. Das nächste Lab beginnt mit diesem Zustand und stellt den Auftrag wieder her.
Wechsle zurück zum Tab Workstation. Prüfe den unabhängigen Monitor. Er verwendet eigene Zugangsdaten und den Health-Endpoint:
Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.
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
Du hast den Zugriff der offengelegten Zugangsdaten entfernt und dabei Dienst sowie unabhängige Integration verfügbar gehalten. Eine weitergehende gültige Wiederherstellung wird in diesem Lab ebenfalls akzeptiert.
Zusammenfassung
Du hast eine funktionierende Integration verfolgt, Schlüssel-ID und Geheimwert unterschieden, einen Geheimwert aus dem Git-Verlauf abgerufen und die zugehörigen Zugangsdaten widerrufen. Du hast die tatsächliche Ablehnung und unabhängige Verfügbarkeit getestet. Eine gelöschte Zeile machte den Schlüssel nicht ungültig; der Widerruf schon. Im nächsten Lab stellst du den Auftrag mit einem eigenen, eingeschränkten Ersatz wieder her.
