Wie Snyk Authentifizierungsstrategien mit Gloo Edge vereinheitlicht

Snyk unterstützt mehrere Authentifizierungsstrategien (authN) für seine APIs. Historisch gesehen waren API-Schlüssel die primäre Form der Authentifizierung. In jüngerer Zeit haben wir jedoch die Authentifizierung mit signierten JWTs eingeführt, die im Rahmen einer OAuth-Integration erstellt werden. Diese Methode wird derzeit sowohl von unseren AWS-CodePipeline- als auch von unseren Bitbucket-Integrationen verwendet.

Zu Beginn setzte Snyk auf eine Hub-and-Spoke-Architektur mit einem zentralen Monolithen, der die Authentifizierungsentscheidungen traf. Das funktionierte hervorragend, während Snyk seine Markttauglichkeit ermittelte und schnell iterierte. Mit dem Wachstum unseres Unternehmens und unserer Kundenbasis stieg jedoch auch der Bedarf an einer serviceorientierten Architektur (SOA). Diese Architekturänderung hätte allerdings bedeutet, dass jeder Service Authentifizierungsentscheidungen treffen muss. Jeder Service hätte also mehrere Authentifizierungsstrategien kennen müssen – auf Dauer wäre das umständlich und schwer skalierbar geworden.

Um unseren Weg hin zur SOA zu unterstützen, kamen wir zu dem Schluss, dass ein einzelner Entscheidungspunkt, der Authentifizierungsstrategien in ein kryptografisch abgesichertes Identitätstoken umwandelt, die sicherste und pragmatischste Lösung ist. Services könnten dieses Token dann nutzen und validieren, ohne sich mit der Komplexität der Unterstützung mehrerer Authentifizierungsstrategien auseinandersetzen zu müssen. Einfach gesagt: Ein zentraler Entscheidungspunkt trifft eine Authentifizierungsentscheidung und gibt anschließend ein signiertes JWT weiter, das der Rest des Systems verwenden kann.

Dafür mussten wir eine neue Ebene in unserem System einführen, die Anfragen authentifizieren und das vereinheitlichte Token erstellen kann. Hier kommt Gloo Edge ins Spiel, eine Art API-Gateway.

Alles mit Gloo zusammenbringen!

Was sind API-Gateways?

Wir sind zwar keine Autorität auf dem Gebiet der API-Gateways, können Ihnen aber eine einfache Liste ihrer Funktionen geben:

• Anfragevalidierung

• Ratenbegrenzung

• Authentifizierung (oder die Möglichkeit, sie zu erweitern!)

• Und vieles, vieles mehr! (Wir haben ja gesagt, dass wir keine Autorität sind …)

Und jetzt kommt der Clou: All das findet am Edge statt! Wenn eine Ihrer Apps eine der oben genannten Aufgaben übernimmt, können Sie diese wahrscheinlich an Ihr API-Gateway auslagern. So können Sie Codezeilen entfernen – etwas, worüber sich alle Engineers freuen! ?

Wir haben uns verschiedene API-Gateways angesehen und uns entschieden, Gloo Edge (in diesem Artikel kurz Gloo) zu verwenden, um uns auf unserem Weg zu einer Plattform zu unterstützen. In diesem Blogbeitrag geht es nicht darum, wie oder warum wir uns für Gloo entschieden haben. Das ist ein Thema für einen zukünftigen Blogbeitrag!

Was ist Gloo Edge?

Gloo Edge ist ein von Solo.io entwickeltes API-Gateway. Es abstrahiert Envoy und ermöglicht Ihnen, Kubernetes Custom Resource Definitions (CRDs) zur Erstellung von Envoy-Konfigurationen zu verwenden – der Einstieg ist also besonders einfach. Wenn Sie Kubernetes-Konfigurationen schreiben können, können Sie wahrscheinlich auch mit den eigenen CRDs von Gloo Envoy-Konfigurationen erstellen.

Wenn Sie mehr darüber erfahren möchten, was Gloo ist und wie es Envoy nutzt, lesen Sie die Gloo-Edge-Dokumentation (sie ist wirklich sehr gut!).

Gloo Edge bei Snyk implementieren

In den folgenden Abschnitten beschreiben wir einige der Arbeiten, mit denen wir Gloo vor die API geschaltet und für einige wirklich interessante Partnerintegrationen verfügbar gemacht haben!

Einen Migrationspfad finden (wenn Ihre API bereits genutzt wird)

Die Snyk API empfängt kontinuierlich Datenverkehr, daher kam es nicht infrage, einfach Gloo davonzuschalten. Wie oben erwähnt, authentifizierte die Kunden-API Anfragen bisher ausschließlich mit API-Schlüsseln. Durch die Umstellung auf JWTs und API-Schlüssel am API-Gateway entstand jedoch eine Trennung zwischen Alt und Neu.

Glücklicherweise war die Gruppe bereits daran interessiert, unsere API-Domain von https://snyk.io/api/ auf https://api.snyk.io umzustellen. Wir wollten jedoch nicht alle Anfragen von unserem ursprünglichen DNS auf die neue Domain umleiten, wenn wir davor das neue API-Gateway schalten würden. Stattdessen führen wir für das API-Gateway eine gewichtete Canary-Version mit prozentualer Verteilung über unsere alte API-Domain ein.

Mit anderen Worten: Das API-Gateway verarbeitet derzeit einen Teil des Datenverkehrs über unser ursprüngliches DNS. Der Rest wird an den Monolithen weitergeleitet, der die Authentifizierungsentscheidungen trifft.

Gloo unterstützt Canary-Releases direkt. Da wir jedoch noch nicht den gesamten API-Datenverkehr über das Gateway leiten, verwenden wir hierfür stattdessen das Traffic-Shifting-Muster von Envoy Proxy. Die folgende Abbildung zeigt auf sehr hoher Ebene, wie das funktioniert und wie es auch für Sie relevant sein könnte.

JWT-Validierung an den Edge verlagern

Obwohl der zuvor erwähnte OAuth-PoC OAuth implementierte, war er zu eng an unseren Identity-Hub gekoppelt (und in unserem Monolithen implementiert). Diese neue Authentifizierungsbibliothek musste das vom Identity-Hub gesendete JWT validieren. Das umfasst unter anderem:

• Validierung der JWT-Nutzdaten (sub, iat, aud)

• Validierung der JWT-Signatur über JWKs-Endpunkte (JSON Web Key Sets)

Auch wenn dies technisch gesehen eine triviale Herausforderung ist, erfordert es normalerweise einiges an Code (weniger als 100 Codezeilen), Tests nicht mitgerechnet. Dasselbe lässt sich erreichen, indem Sie Ihrer VirtualService in Gloo weniger als 20 Codezeilen hinzufügen:

1jwtStaged:
2 beforeExtAuth:
3   providers:
4     snyk:
5       issuer: <a valid jwt issuer> # where did the token come from?
6       audiences:
7         - <a valid jwt audience> # what service expects the token?
8       tokenSource:
9         headers: # Regex currently not supported
10           - header: Authorization
11             prefix: "Bearer"
12           - header: Authorization
13             prefix: "bearer"
14       jwks:
15         remote:
16           upstreamRef:
17             name: <upstream name>
18             namespace: <upstream namespace>
19           url: <a valid jwks endpoint>

Diese Konfiguration extrahiert das JWT aus dem Header und führt einige grundlegende JWT-Validierungen durch, bevor sie das JWT an ein External-Auth-Plugin (ExtAuth) weitergibt (dazu später mehr!):

• Validieren, dass die aktuelle Zeit innerhalb der iat- (issued at) und exp- (expiration) Claims des JWT liegt

• Die Audience validieren

• Den Issuer validieren

• Die Signatur über einen externen JWKs-Endpunkt (Upstream) validieren

Wir konnten einen Großteil der Validierung aus dem Monolithen an den Edge verlagern! Ziemlich cool, oder? ??

Authentifizierungsstrategien vereinheitlichen

Auch wenn wir die JWT-Validierung am Edge durchführen, haben wir unserem System nur geholfen, indem wir diese Aufgabe aus dem Monolithen ausgelagert haben. Wie Sie dem Titel und der Einleitung dieses Artikels entnehmen können, reicht es nicht aus, nur die JWT-Validierung an den Edge zu verlagern. Wir möchten außerdem alle Authentifizierungsentscheidungen an den Edge auslagern, sodass Gloo sie auf Grundlage des vom Benutzer bereitgestellten Schlüsselmaterials treffen kann.

Dafür haben wir ein External-Authorization-Plugin (ExtAuth) eingeführt, eine besondere Art von Plugin, das von Gloo entwickelt wurde (nur in der Enterprise-Suite verfügbar), in Go geschrieben und in einen Envoy-External-Authorization-Filter kompiliert ist. Das Plugin ermittelt zunächst, welche Art von Schlüsselmaterial der Benutzer bereitgestellt hat, und stellt seine Identität fest. Sobald die Identität feststeht, signiert das Plugin das Token kryptografisch und übermittelt es an die nachgelagerte API. Diese validiert die Token-Signatur und führt den angeforderten Vorgang im Namen des Benutzers aus. Die folgende Abbildung zeigt ein einfaches Beispiel dafür.

Mit anderen Worten: Zu diesem Zeitpunkt haben wir ein internes Token erstellt, das von jedem Service in unserem Cluster verwendet werden kann und Benutzerinformationen enthält, die einem Benutzer in unserer Benutzerdatenbank zugeordnet werden können! Von Gloo weitergeleitete Services stellen sicher, dass das JWT von Gloo signiert wurde. Das mag nach wenig klingen, aber bisher mussten wir explizit Benutzerdaten von unserem Monolithen anfordern, um in jedem einzelnen Service Informationen zur Identität eines Benutzers zu erhalten.

Darüber hinaus können unsere Services mit Gloo eine Authentifizierungsmethode verwalten, während Gloo die Komplexität der Verwaltung mehrerer Authentifizierungsstrategien am Edge übernimmt.

Das lässt sich mit relativ wenig Aufwand und wenigen Codezeilen umsetzen (der Großteil ist von Solo erstellter Boilerplate-Code) – im Vergleich dazu, für jeden Service eigene Authentifizierungsstrategien implementieren zu müssen.

Zukünftige Arbeiten

In den kommenden Sprints wird sich das Extensibility-Team auf zwei zentrale Bereiche rund um unser API-Gateway konzentrieren:

• Gloo nach und nach den gesamten API-Datenverkehr verarbeiten lassen (sprich: Canary-Release!).Wir möchten damit beginnen, „normalen“ Datenverkehr, der nicht spezifisch für Partner ist, über unser API-Gateway zu leiten. Dafür müssen wir die erforderlichen Maßnahmen zur Beobachtbarkeit und Alarmierung einrichten und sicherstellen, dass unsere Bereitschafts-Engineers die neue Infrastruktur unterstützen können. Außerdem müssen wir einen Teil des Datenverkehrs, den der aktuelle Ingress der API empfängt, an den Envoy-Proxy von Gloo weiterleiten.

• Gloo so erweitern, dass es Anfragen am Edge validieren kann.Diese Funktion wird derzeit nicht direkt von Gloo unterstützt.

Wir hoffen, dass dieser Beitrag für Sie hilfreich war, wenn Sie den Einsatz von Gloo in Ihrer Umgebung erwägen! In zukünftigen Blogbeiträgen sehen wir uns an, wie Gloo unseren Engineering- und Produktteams eine hervorragende Grundlage für die Beobachtbarkeit bietet und wie Gloo uns dazu gebracht hat, unsere CI/CD-Praktiken bei Snyk zu verbessern.

Möchten Sie Teil eines Engineering-Teams sein, das an der Spitze der Entwicklung steht? Wir stellen weltweit ein.