AWS stellt IAMs OIDC-Discovery-Endpunkte hinter PrivateLink
Serguey Asael Shinder2 Min. LesezeitAWS hat die OpenID-Connect-Discovery-Endpunkte der ausgehenden Identitätsföderation in IAM über Interface-VPC-Endpunkte erreichbar gemacht; angekündigt wurde das am 25. September. Sowohl das Discovery-Dokument mit den Metadaten als auch das JSON Web Key Set mit den Prüfschlüsseln lassen sich jetzt über AWS PrivateLink abrufen, der Verkehr bleibt also im AWS-Netz. Die Funktion gibt es in allen kommerziellen Regionen, in GovCloud (US) und in den chinesischen Regionen; Kosten entstehen nur im Rahmen der üblichen PrivateLink-Preise.
Die ausgehende Föderation dreht das gewohnte Verhältnis um. Nicht ein externer Identitätsanbieter stellt Tokens aus, die AWS akzeptiert, sondern ein Workload in AWS holt sich beim Security Token Service ein kurzlebiges JSON Web Token und legt es einem anderen Dienst vor. Der prüft die Signatur gegen Schlüssel, die an den OIDC-Discovery-Endpunkten veröffentlicht sind. Ziel ist, keine langlebigen API-Schlüssel für Fremdsysteme mehr speichern zu müssen. Bisher musste die prüfende Seite diese Endpunkte allerdings über das öffentliche Internet erreichen. Ein Prüfdienst in einer VPC ohne Internetausgang - bei regulierten Workloads der Normalfall - kam an die Schlüssel gar nicht heran und brauchte dafür eigens einen NAT-Weg oder einen Proxy.
Was das bedeutet
Eine kleine Ankündigung, die eine echte Lücke in einem Muster schließt, das AWS stark vorantreibt. Wer beide Seiten in AWS betreibt - etwa einen Workload in einem Konto, der ein Token an einen selbst betriebenen Dienst in den privaten Subnetzen eines anderen Kontos schickt -, kann den Prüfdienst jetzt vollständig isolieren. Bisher war die einzige öffentliche Netzabhängigkeit des ganzen Ablaufs ausgerechnet die Komponente, deren Aufgabe die Sicherheit ist.
Damit lohnt es sich, eine frühere Entscheidung zu überprüfen. Teams, die auf die ausgehende Föderation verzichtet und statische Zugangsdaten behalten haben, weil ihre Prüfdienste keinen Internetzugang hatten, haben diesen Grund nicht mehr. Bei der Umstellung gilt: Ein JWKS-Endpunkt wird von Prüfdiensten zwischengespeichert. Eine vernünftige Cache-Dauer wählen, Schlüsselrotation durch erneutes Laden bei unbekannter Key-ID abfangen statt nur per Timer, und testen, was passiert, wenn der VPC-Endpunkt ausfällt - ein Prüfdienst, der keine Schlüssel laden kann, muss ablehnen, nicht durchwinken.
Für externe Dienste - etwa einen SaaS-Anbieter, der Tokens aus den AWS-Workloads seiner Kunden prüft - ändert sich nichts: Er sitzt außerhalb der eigenen VPC und nutzt weiter die öffentlichen Endpunkte. Die Neuerung hilft dort, wo der Prüfdienst einem selbst gehört.