Zusammenfassung

  • id-token: write erlaubt einem GitHub-Actions-Job oder -Workflow, einen OIDC JSON Web Token anzufordern; GitHub stellt klar, dass diese Einstellung nicht selbst Schreibrechte auf externe Ressourcen verleiht.
  • Der Cloud-Anbieter prüft die konfigurierten Vertrauensbedingungen gesondert und kann den JWT gegen einen kurzlebigen Zugriffstoken tauschen. Die spätere Ressourcenentscheidung ist erneut eine andere Kontrollfläche.
  • Eine belastbare Aussage über Cloud-Autorisierung verbindet Workflow-Revision und begrenzte Claims, Revision der Vertrauensrichtlinie, Austausch- und Sitzungsnachweis, Kontext der effektiven Berechtigungen, Ressourcenentscheidung und eine zeitlich getrennte Zielbeobachtung.

„Die Pipeline hat über OIDC Cloud-Zugriff“ kann eine nützliche Kurzbeschreibung der Umsetzung sein. Irreführend wird sie, wenn sie mehrere unabhängig gesteuerte Entscheidungen zu einem Urteil verdichtet. GitHub Actions kann einem Job, der einen Token anfordern darf, einen OpenID-Connect-Identitätstoken ausstellen. Ein Cloud-Anbieter kann so eingerichtet sein, dass er dem Aussteller GitHub vertraut und ausgewählte Claims prüft. Ein erfolgreicher Tausch kann dem Job eine kurzlebige Cloud-Berechtigung geben.

Danach bewertet der Cloud-Dienst die konkrete Anfrage aber noch anhand von Rolle, Ressourcenrichtlinie, Berechtigungsgrenze, Sitzungsrichtlinie, Organisationskontrolle, Anfragekontext und gewünschter Aktion. Jeder Abschnitt hat einen eigenen Akteur, Zeitpunkt und Nachweisort.

GitHub markiert die erste Grenze deutlich. id-token: write lässt einen Workflow einen OIDC-JWT anfordern und verwenden; daraus folgt keine Befugnis, andere Ressourcen zu verändern. Wer die Einstellung in einer Release-Prüfung sieht, hat daher keinen Beleg für die endgültige Berechtigung. Bekannt ist nur ein enger Sachverhalt: Der Job war berechtigt, einen GitHub-Identitätstoken anzufordern. Ob die Anfrage erfolgte, welche audience erbat, welche Claims zurückkamen, ob ein Cloud-Anbieter ihnen vertraute oder ob eine Ressource später eine Aktion akzeptierte, folgt daraus nicht.

Das Cloud-Vertrauensverhältnis ist eine eigene Konfiguration und Entscheidung. GitHubs Anleitung für Cloud-Anbieter sagt, dass der Anbieter Token-Claims validiert und bei Erfolg einen für den Job verfügbaren Zugriffstoken bereitstellt. Die Richtlinie des Anbieters macht subject, audience, Repository-Identität, Referenz auf einen wiederverwendbaren Workflow oder einen anderen verfügbaren Claim zur Aufnahmebedingung. Ein Token kann korrekt aufgebaut und dennoch an einer Vertrauensbedingung scheitern. Eine Bedingung kann zu weit sein; ein erwarteter Claim kann fehlen oder sich ändern.

Ein Cloud-Token kann ausgegeben werden und dennoch enger beschränkt sein, als eine Release-Verantwortliche annimmt. Umgekehrt kann eine Ressourcenrichtlinie die Aktion verweigern, obwohl der föderierte Tausch erfolgreich war.

AWS macht die Trennung anschaulich. GitHubs AWS-Anleitung beschreibt eine AWS-Vertrauensbeziehung und empfiehlt, den OIDC-Bedingungsschlüssel sub in einer Rollen-Vertrauensrichtlinie auszuwerten. Das Vorhandensein eines GitHub-sub-Claims ist damit kein Nachweis einer AWS-Rollensitzung. Und eine Rollensitzung ist kein Nachweis aller Berechtigungen, die sie im Kontext einer bestimmten Anfrage wirksam hatte. Rollenrichtlinie, Berechtigungsgrenze, Sitzungsrichtlinie, Organisationsbeschränkung, Ressourcenrichtlinie und explizite Verweigerung können eine einzelne Entscheidung prägen. Dieser Beitrag prüft kein AWS-Konto; er zeigt, warum die pauschale Aussage „OIDC hat die Bereitstellung autorisiert“ zu viel offenlässt.

Wiederverwendbare Workflows geben einen weiteren Grund, die tatsächlichen Verknüpfungen zu bewahren. GitHub dokumentiert, dass das Token eines Jobs in einem wiederverwendbaren Workflow gewöhnliche Jobinformationen enthält und job_workflow_ref enthalten kann; die Unterstützung benutzerdefinierter Claims unterscheidet sich zwischen Cloud-Anbietern. Ein Workflow-Name im Repository beweist nicht, dass der vertrauende Anbieter diesen Wert geprüft hat. Ein Aufrufer kann GitHub bekannt sein, ohne in dem Claim zu erscheinen, den eine Cloud-Vertrauensbedingung auswerten kann. Eine spätere Anpassung von subject-Claims kann auch das vom Anbieter erwartete Format verändern. Das sind Konfigurationsfakten, die festzuhalten sind, keine Lücken, die das beruhigende Wort „föderiert“ schließen könnte.

Deshalb braucht Cloud-Autorisierung einen siebenfachen Beleg. Bewahren Sie die genaue Workflow-Revision, die auslösende Ref, die Jobidentität und den Kontext von id-token: write. Bewahren Sie einen begrenzten Datensatz der angeforderten audience und der resultierenden Claims auf, ohne einen verwendbaren Token offenzulegen. Bewahren Sie die damals geltende Version des Cloud-Identitätsanbieters und der Vertrauensrichtlinie auf. Bewahren Sie Tauschergebnis, Rollen- oder Sitzungsidentität und Ablaufzeit auf. Bewahren Sie den für die beabsichtigte Aktion relevanten Kontext effektiver Berechtigungen auf. Bewahren Sie Ressourcenentscheidung und Anfragedatensatz auf. Schließlich bewahren Sie eine Zielbeobachtung zu einem getrennten Zeitpunkt auf. Kontonamen, Ressourcenkennungen und Werte können geschützt bleiben; entscheidend ist nicht die Veröffentlichung von Zugangsdaten, sondern der Erhalt der Verbindungen zwischen den Entscheidungen.

Quellen

  1. GitHub Docs — OpenID Connect bei Cloud-Anbietern konfigurieren
  2. GitHub Docs — OpenID-Connect-Referenz
  3. GitHub Docs — OpenID Connect in Amazon Web Services konfigurieren
  4. GitHub Docs — OpenID Connect mit wiederverwendbaren Workflows verwenden