dex
v2.41.1
Dex ist ein Identitätsdienst, der OpenID Connect verwendet, um die Authentifizierung für andere Apps voranzutreiben.
Dex fungiert über „Konnektoren“ als Portal zu anderen Identitätsanbietern. Dadurch kann Dex die Authentifizierung auf LDAP-Server, SAML-Anbieter oder etablierte Identitätsanbieter wie GitHub, Google und Active Directory verschieben. Clients schreiben ihre Authentifizierungslogik einmal, um mit Dex zu kommunizieren, dann verwaltet Dex die Protokolle für ein bestimmtes Backend.
ID-Tokens sind eine von OpenID Connect eingeführte OAuth2-Erweiterung und die Hauptfunktion von Dex. ID-Tokens sind JSON-Web-Tokens (JWTs), die von Dex signiert und als Teil der OAuth2-Antwort zurückgegeben werden, die die Identität des Endbenutzers bestätigt. Ein Beispiel-JWT könnte wie folgt aussehen:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg
ID-Tokens enthalten Standardansprüche, die bestätigen, welche Client-App den Benutzer angemeldet hat, wann das Token abläuft und welche Identität der Benutzer hat.
{
"iss" : " http://127.0.0.1:5556/dex " ,
"sub" : " CgcyMzQyNzQ5EgZnaXRodWI " ,
"aud" : " example-app " ,
"exp" : 1492882042 ,
"iat" : 1492795642 ,
"at_hash" : " bi96gOXZShvlWYtal9Eqiw " ,
"email" : " [email protected] " ,
"email_verified" : true ,
"groups" : [
" admins " ,
" developers "
],
"name" : " Jane Doe "
}Da diese Token von Dex signiert sind und standardbasierte Ansprüche enthalten, können andere Dienste sie als Dienst-zu-Dienst-Anmeldeinformationen verwenden. Zu den Systemen, die bereits von dex ausgegebene OpenID Connect ID-Token nutzen können, gehören:
Einzelheiten zum Anfordern oder Validieren eines ID-Tokens finden Sie unter „Apps schreiben, die Dex verwenden“ .
Dex läuft nativ auf jedem Kubernetes-Cluster unter Verwendung benutzerdefinierter Ressourcendefinitionen und kann die API-Serverauthentifizierung über das OpenID Connect-Plugin steuern. Clients wie kubernetes-dashboard und kubectl können im Namen von Benutzern agieren, die sich über jeden von Dex unterstützten Identitätsanbieter beim Cluster anmelden können.
Wenn sich ein Benutzer über Dex anmeldet, wird die Identität des Benutzers normalerweise in einem anderen Benutzerverwaltungssystem gespeichert: einem LDAP-Verzeichnis, einer GitHub-Organisation usw. Dex fungiert als Shim zwischen einer Client-App und dem Upstream-Identitätsanbieter. Der Client muss nur OpenID Connect verstehen, um Dex abzufragen, während Dex eine Reihe von Protokollen für die Abfrage anderer Benutzerverwaltungssysteme implementiert.
Ein „Connector“ ist eine von Dex verwendete Strategie zur Authentifizierung eines Benutzers gegenüber einem anderen Identitätsanbieter. Dex implementiert Konnektoren, die auf bestimmte Plattformen wie GitHub, LinkedIn und Microsoft sowie auf etablierte Protokolle wie LDAP und SAML abzielen.
Abhängig von den Konnektoren können Einschränkungen in den Protokollen verhindern, dass Dex Aktualisierungstoken ausgibt oder Gruppenmitgliedschaftsansprüche zurückgibt. Da SAML beispielsweise keine nicht interaktive Möglichkeit zum Aktualisieren von Behauptungen bietet, stellt Dex, wenn sich ein Benutzer über den SAML-Connector anmeldet, kein Aktualisierungstoken an seinen Client aus. Für Clients, die Offlinezugriff benötigen, wie z. B. kubectl , ist Aktualisierungstokenunterstützung erforderlich.
Dex implementiert die folgenden Konnektoren:
| Name | unterstützt Aktualisierungstoken | unterstützt die Behauptung der Gruppe | unterstützt den Anspruch „preferred_username“. | Status | Notizen |
|---|---|---|---|---|---|
| LDAP | Ja | Ja | Ja | stabil | |
| GitHub | Ja | Ja | Ja | stabil | |
| SAML 2.0 | NEIN | Ja | NEIN | stabil | WARNUNG: Nicht gewartet und wahrscheinlich anfällig für Authentifizierungsumgehungen (#1884) |
| GitLab | Ja | Ja | Ja | Beta | |
| OpenID Connect | Ja | Ja | Ja | Beta | Beinhaltet Salesforce, Azure usw. |
| OAuth 2.0 | NEIN | Ja | Ja | Alpha | |
| Ja | Ja | Ja | Alpha | ||
| Ja | NEIN | NEIN | Beta | ||
| Microsoft | Ja | Ja | NEIN | Beta | |
| AuthProxy | NEIN | Ja | NEIN | Alpha | Authentifizierungs-Proxys wie Apache2 mod_auth usw. |
| Bitbucket Cloud | Ja | Ja | NEIN | Alpha | |
| OpenShift | Ja | Ja | NEIN | Alpha | |
| Atlassian Crowd | Ja | Ja | Ja * | Beta | Der Anspruch „preferred_username“ muss über config konfiguriert werden |
| Gitea | Ja | NEIN | Ja | Beta | |
| OpenStack Keystone | Ja | Ja | NEIN | Alpha |
Stabil, Beta und Alpha sind definiert als:
Alle Änderungen oder veralteten Connector-Funktionen werden in den Versionshinweisen bekannt gegeben.
Einzelheiten zum Melden von Schwachstellen finden Sie in unserer Sicherheitsrichtlinie.
Wenn alle Codierungen und Tests abgeschlossen sind, führen Sie bitte die Testsuite aus:
make testallFür die beste Entwicklererfahrung installieren Sie Nix und direnv.
Alternativ können Sie Go und Docker manuell oder mit einem Paketmanager installieren. Installieren Sie die restlichen Abhängigkeiten, indem Sie make deps ausführen.
Informationen zum Veröffentlichungsprozess finden Sie in der Veröffentlichungsdokumentation.
Das Projekt ist unter der Apache-Lizenz, Version 2.0, lizenziert.
