Secrets, Tokens und OIDC

Secrets, Tokens und OIDC

0:00 Das sicherste Cloud-Geheimnis ist das, was gar nicht erst gespeichert wird. Dieser Satz beschreibt das Ziel dieses Moduls. Wir beginnen bei der klassischen Verwaltung von Geheimnissen und ihren Grenzen — und die Maskierung im Log ist eine deutlich dünnere Sicherung, als viele annehmen. Dann kommt das Token, das jeder Job automatisch bekommt, und die Kunst, ihm möglichst wenig Rechte zu geben.

0:22 Und zum Schluss der Weg, der gespeicherte Cloud-Schlüssel überflüssig macht: OpenID Connect. Das ist die Stelle, an der aus einer funktionierenden Pipeline eine wird, die man auch prüfen kann.

Secrets, Tokens und OIDC

0:34 Zweites Modul des dritten Tages. Drei Ebenen: Wo liegen Geheimnisse und Konfigurationswerte, wie beschränkt man die Rechte des automatischen Tokens, und wie ersetzt man langlebige Cloud-Schlüssel durch etwas, das nur Minuten lebt. Am Ende hat die Beetkarte keinen gespeicherten Cloud-Zugangsschlüssel mehr — und trotzdem darf sie in Produktion ausrollen.

Secrets und Variablen verwalten

0:54 Fangen wir mit der Ablage an. Es gibt drei Ebenen für Geheimnisse und eine wichtige Alternative für alles, was gar keines ist. Geheimnisse lassen sich am Repository, an der Organisation oder an einem Environment hinterlegen — und die dritte Variante ist die interessanteste, weil sie zusätzlich durch die Schutzregeln aus dem letzten Modul gedeckt ist.

1:15 Alles, was keinen Schutz braucht, gehört dagegen in Variablen und darf im Klartext im Log stehen. Diese Unterscheidung ist keine Formalie: Wer alles zum Geheimnis erklärt, macht die Fehlersuche unnötig schwer, weil sich nichts mehr nachvollziehen lässt. Und wer zu wenig schützt, erfährt es meist auf unangenehme Weise. Die Tabelle sortiert nach Reichweite: von der ganzen Organisation bis zur einzelnen Umgebung. Die Faustregel dazu ist einfach — je enger die Reichweite, desto besser.

1:43 Ein Produktionszugang gehört ans Environment und nirgendwo sonst, denn dort schützt ihn die Freigaberegel. Und beachten Sie die Fußzeile: Strukturierte Werte wie JSON gehören nie in ein einzelnes Geheimnis. Der Grund ist technisch — die Maskierung ersetzt bekannte Zeichenketten, und wenn ein Werkzeug das JSON in Teilen ausgibt, greift sie für diese Teile nicht.

2:04 Zerlegen Sie solche Werte lieber in einzelne Geheimnisse. Diese Frage stellt sich, sobald ein Workflow mehr braucht als das eigene Repository. Ein persönliches Token hängt an einem Menschen — und verschwindet, wenn dieser Mensch das Unternehmen verlässt. Das ist der Moment, in dem plötzlich Pipelines stehen, deren Zusammenhang niemand mehr kennt.

2:25 Eine GitHub App gehört der Organisation, hat fein einstellbare Rechte und stellt kurzlebige Token aus. Sie ist etwas aufwendiger einzurichten und in fast allen Fällen die bessere Wahl. Und der letzte Punkt gilt sowieso: Für alles innerhalb des Repositories brauchen Sie beides nicht. Der erste Punkt ist eine der unangenehmsten Überraschungen: Ein kodiertes Geheimnis wird von der Maskierung nicht mehr erkannt und steht im Klartext im Log.

2:50 Wer solche Umwandlungen macht, muss den umgewandelten Wert ausdrücklich zusätzlich maskieren. Der zweite ist das übervorsichtige Gegenstück, das die Diagnose behindert. Der dritte ist eine halbe Reaktion auf einen Vorfall — das neue Geheimnis ist gesetzt, das alte aber nie widerrufen und weiterhin gültig. Und der vierte ist der Universalschlüssel, der irgendwann in jeder Pipeline steckt.

GITHUB_TOKEN und Least Privilege

3:13 Jetzt zum Token, das Sie längst benutzt haben, ohne es zu hinterlegen. Es ist bequem — und genau deshalb lohnt ein genauer Blick auf seine Rechte. Zu Beginn jedes Jobs stellt GitHub ein Token aus, das auf das Repository des Workflows begrenzt ist und mit dem Job endet. Auf gehosteten Runnern lebt es maximal sechs Stunden, auf selbst gehosteten bis zu vierundzwanzig.

3:35 Seine Rechte legen Sie auf Workflow- oder Jobebene fest — und jetzt kommt der wichtige Teil: Sobald Sie irgendeinen Bereich nennen, fallen alle anderen auf null. Das klingt streng und ist tatsächlich sehr praktisch, weil es die Voreinstellung umdreht: Sie sagen, was gebraucht wird, statt zu erraten, was zu viel ist. Das Muster hier ist einfach und wirkungsvoll. Oben werden alle Rechte entzogen — die leeren geschweiften Klammern sind kein Tippfehler, sondern eine Aussage.

4:02 Und dann bekommt jeder Job zurück, was er tatsächlich braucht: Lesen für den Code, Schreiben für die Pakete, und ein Recht für das OIDC-Token, um das es gleich geht. Wenn Sie das in einem bestehenden Projekt einführen, scheitert der erste Lauf garantiert — und das ist der eigentliche Nutzen der Übung, denn Sie erfahren dabei, welche Rechte Ihre Pipeline wirklich zieht.

4:23 Der erste Punkt ist der, der die Sache ernst macht: Ein Token mit Schreibrecht auf den Inhalt kann die Workflow-Dateien selbst ändern. Damit kann kompromittierter Code seine eigene Prüfung entfernen — dauerhaft, nicht nur für diesen Lauf. Der zweite Punkt beschreibt die Vererbung: Was im Job läuft, erbt dessen Rechte, egal ob es Ihr Testkommando ist oder eine fremde Action.

4:44 Deshalb gehören Rechte an den Job und nicht an den Workflow — so bleibt der Schaden lokal. Und Läufe aus Forks sind ohnehin abgesichert. Der erste Punkt ist der häufigste Entwurfsfehler: Alles steht am Workflow, und der Deployment-Job erbt Rechte, die eigentlich nur der Build-Job brauchte. Der zweite ist die Abkürzung, die man aus Frust nimmt — ein einzelner Schritt scheitert, also bekommt der ganze Workflow Schreibrechte auf alles.

5:09 Der dritte umgeht die Frage komplett, indem ein persönliches Token die Sache regelt; damit sind Sie schlechter dran als vorher. Und der vierte ist Altlast: Ein Schritt wird entfernt, sein Recht bleibt stehen, und niemand räumt es je auf.

OIDC statt langlebiger Zugangsschlüssel

5:23 Und jetzt zum interessantesten Mechanismus dieses Seminars. Er löst ein Problem, das die meisten Teams als unvermeidlich hinnehmen: den Cloud-Schlüssel, der jahrelang im Tresor liegt. Die Idee funktioniert wie ein Werksausweis. Statt jedem Mitarbeiter einen Generalschlüssel mitzugeben, zeigt er seinen Ausweis am Empfang und bekommt eine Tageskarte.

5:45 GitHub stellt Ihrem Job ein signiertes Token aus, das beschreibt, wer da anfragt: welches Repository, welcher Branch, welche Umgebung, welcher Workflow. Der Cloud-Anbieter prüft diese Angaben gegen eine hinterlegte Vertrauensbeziehung und gibt dafür ein kurzlebiges Zugangstoken aus. Ergebnis: Es gibt keinen dauerhaften Schlüssel mehr, der gestohlen werden könnte — denn er existiert nicht.

6:08 Vier Schritte, und der dritte ist der, wo die Sicherheit entsteht. Der Job fordert das Token an, der Anbieter prüft die Angaben darin gegen das, was Sie ihm als vertrauenswürdig hinterlegt haben — und erst dann gibt es Zugang. Alles hängt also an der Qualität dieser hinterlegten Regel. Ist sie eng gefasst, kann nur ein bestimmter Branch eines bestimmten Repositories in Produktion schreiben.

6:31 Ist sie weit gefasst, haben Sie den gespeicherten Schlüssel durch etwas ersetzt, das jeder Branch bekommt. Dazu gleich mehr. Sieben Zeilen, und kein einziges Geheimnis darin — das ist der Punkt. Oben das Recht, das OIDC-Token anzufordern; ohne dieses Recht scheitert alles Weitere mit einer Meldung, die man leicht der Cloud-Rolle anlastet.

6:51 Unten die Anmeldung, die statt Zugangsdaten nur die Rolle nennt, die übernommen werden soll. Der Rollenname steht hier als Konfigurationsvariable, weil er kein Geheimnis ist — man kann damit nichts anfangen, ohne die Vertrauensbeziehung zu erfüllen. Für Azure, Google Cloud oder Vault sieht das Muster praktisch gleich aus.

7:11 Hier entscheidet sich der Sicherheitsgewinn. Das Token enthält eine Angabe, die Repository und Branch oder Umgebung beschreibt, und Ihre Cloud-Regel prüft genau diese Angabe. Fassen Sie sie so eng wie möglich: für Produktion an die Umgebung binden, nicht nur an den Branch — denn die Umgebung bringt die Freigaberegel aus Modul elf gleich mit.

7:30 Wer stattdessen das ganze Repository erlaubt, hat eine unangenehme Konsequenz gebaut: Dann darf jeder Branch, den irgendjemand anlegt, in Ihrer Produktionsumgebung arbeiten. Der erste Punkt ist der eben beschriebene zu weite Trust, und er ist der häufigste Fehler bei OIDC-Einführungen. Der zweite ist der halbe Umstieg: OIDC ist eingerichtet, aber der alte Schlüssel liegt noch im Tresor und ist weiterhin gültig — dann haben Sie Aufwand betrieben, ohne das Risiko zu senken.

7:58 Der dritte betrifft die Prüfung der Zielgruppe des Tokens, die auf Anbieterseite konfiguriert wird. Und der vierte ist eine Frage der Reichweite: Das Recht zum Anfordern des Tokens gehört an den einzelnen Job, nicht großzügig nach oben.

Übung

8:12 In der Übung entziehen Sie der Beetkarte erst alle Rechte und geben nur zurück, was sie braucht — und ersetzen dann den gespeicherten Cloud-Schlüssel. Zwei Teile, ein Ziel: Ein kompromittierter Job soll möglichst wenig ausrichten können. Der erste Teil ist die Rechtediät, und der erste Schritt daraus ist der lehrreichste — der Lauf scheitert, und Sie sehen schwarz auf weiß, welche Rechte Ihre Pipeline tatsächlich braucht.

8:35 Der zweite Teil ersetzt den Cloud-Schlüssel, eng gebunden an Branch und Umgebung. Wichtig ist der Schluss: Der alte Schlüssel wird entfernt und beim Anbieter widerrufen. Zur Vertiefung wenden Sie den Trust auf einen anderen Branch an — der Fehlschlag ist dann der Beweis, dass die Bindung greift. Die Schritte eins und zwei sind die Rechtediät, und sie funktioniert nur in dieser Reihenfolge: erst leeren, dann gezielt zurückgeben.

9:00 Wer umgekehrt vorgeht, streicht am Ende doch nur das Offensichtliche. Die Schritte drei und vier richten OIDC ein, wobei Schritt vier der eigentliche Sicherheitsgewinn ist — die enge Bindung. Und Schritt fünf ist der, den man aus Vorsicht gern aufschiebt: den alten Schlüssel wirklich löschen und widerrufen. Solange er existiert, haben Sie zwei Wege in die Cloud, und den unsicheren überwacht niemand.

9:23 Der erste Punkt ist der halbe Umstieg, der leider häufig ist. Der zweite ist die Versuchung im Seminar wie im Projekt: Der Trust wird großzügig gefasst, damit es endlich läuft — und bleibt dann so. Der dritte kostet Sie eine halbe Stunde Fehlersuche an der falschen Stelle, weil das fehlende Recht wie ein Problem der Cloud-Rolle aussieht.

9:42 Und der vierte ist der grundsätzliche: Eine Einstellung, die nie durch einen Lauf bestätigt wurde, ist eine Vermutung. Im nächsten Modul geht es dann um die Sicherheit der Workflows selbst.