Implementierung der OpenID Connect-Authentifizierung für Kubernetes mit Okta und NGINX Ingress Controller

Wir haben schon oft darüber geschrieben, wie wichtig es ist, Ihre Apps und APIs im heutigen Klima der Ransomware und Bot-gesteuerten Angriffe zu schützen. Neben Mechanismen wie der Web Application Firewall (WAF) sind die Authentifizierung von Benutzeridentitäten und die Durchsetzung von Autorisierungskontrollen wichtige Möglichkeiten zum Schutz Ihrer Geschäftsanwendungen.

Der direkteste Weg zur Implementierung von Authentifizierung und Autorisierung besteht in den Anwendungen selbst. Dies kann zwar funktionieren, wenn Ihre Benutzerbasis klein ist und Ihre App keine häufigen Updates erfordert, bei großem Maßstab wird es jedoch schnell unhaltbar. Wenn sich Ihre Benutzer beispielsweise für jede der zahlreichen Apps einen anderen Kontonamen und ein anderes Passwort merken müssen, werden sie beim Anmelden häufig mit der frustrierenden Meldung „Benutzername oder Passwort falsch“ begrüßt. Dies führt dazu, dass sie auf unsichere Lösungen wie leicht zu erratende Passwörter vom Typ „abc123“ zurückgreifen. Und wir alle haben schon Monitore gesehen, die mit einem Kranz aus Post-it®-Notizen mit Passworterinnerungen geschmückt waren!

Single Sign-On (SSO)-Technologien können diese Probleme teilweise lösen, indem sie die Verwendung einzelner Benutzernamen und Passwörter durch einen einzigen Satz von Anmeldeinformationen ersetzen. Benutzer melden sich nur einmal mit einem Identitätsanbieter (IdP) an, um Zugriff auf viele Apps zu erhalten. Allerdings müssen Entwickler in ihren Apps noch immer Code für die Schnittstelle zum SSO-System einbinden, was eine große Herausforderung darstellen kann, insbesondere bei zunehmender Komplexität der Anwendungen.

Wenn Unternehmen wachsen und die Anforderungen einer stetig wachsenden Benutzerbasis erfüllen müssen, ist es von entscheidender Bedeutung, Anforderungen, die nicht spezifisch für die Funktionalität einer App sind – wie etwa Authentifizierung und Autorisierung – aus der Anwendungsebene auszulagern. Ein idealer Ort für die zentrale Authentifizierung und Autorisierung in Kubernetes ist der Ingress-Controller , der den gesamten in den Cluster eingehenden Datenverkehr prüfen und an die entsprechenden Dienste weiterleiten kann. Dadurch müssen Entwickler keine Authentifizierungslogik mehr erstellen, verwalten und replizieren und können mithilfe der nativen Kubernetes-API problemlos SSO-Technologien auf der Eingangsebene nutzen.

In diesem Blog zeigen wir, wie man eine vollwertige SSO-Lösung mit dem NGINX Plus-basierten NGINX Ingress Controller als Weiterleitungspartei implementiert und den OIDC Authorization Code Flow mit Okta als vorkonfiguriertem Identitätsanbieter (IdP) unterstützt.

Notiz: Diese Funktion ist mit dem auf Open Source basierenden NGINX Ingress Controller nicht verfügbar.

Voraussetzungen

Dieser Blog setzt voraus, dass Sie Erfahrung mit der Arbeit in Kubernetes-Umgebungen haben. Darüber hinaus benötigen Sie Folgendes:

• Eine Kubernetes-Umgebung – NGINX Ingress Controller wird auf Vanilla Kubernetes sowie zahlreichen Kubernetes-Plattformen unterstützt, darunter Amazon Elastic Kubernetes (EKS), Bare Metal, Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher Kubernetes Engine und Red Hat OpenShift.
• NGINX Plus-basierter NGINX Ingress Controller – Sie müssen über eine gültige Lizenz für die NGINX Plus-basierte Version des NGINX Ingress Controllers verfügen. Sie können noch heute mit einer Lizenz beginnen, indem Sie eine kostenlose 30-Tage-Testversion anfordern. Weitere Informationen finden Sie in unserer Dokumentation .
• Ein Okta-Entwicklerkonto – Um Okta als Ihren IdP zu konfigurieren, melden Sie sich zunächst für ein Entwicklerkonto an. Laden Sie alternativ die Okta-Befehlszeilenschnittstelle (CLI) herunter und führen Sie den Befehl „okta register“ aus, um sich für ein neues Konto anzumelden. Zum Zeitpunkt des Schreibens befindet sich die Okta CLI in der Betaphase und wird nicht für den Produktionseinsatz empfohlen.

Vorkonfigurieren des IdP

Cloud-Dienste müssen wissen, wo Benutzeridentitäten abgerufen und überprüft werden können. Hierfür wird ein IdP erforderlich. Ein IdP verwaltet und speichert digitale Identitäten sicher und stellt sicher, dass Angreifer keine Identitäten stehlen können, um sich als Benutzer auszugeben.

In diesem Abschnitt verwenden wir die Okta-CLI, um Okta als IdP vorzukonfigurieren und das zu erstellen, was Okta eine App-Integration nennt.

1. Führen Sie den Befehl „Okta Login “ aus, um die Okta-CLI mit Ihrem Okta-Entwicklerkonto zu authentifizieren. Geben Sie bei den Eingabeaufforderungen Ihre Okta-Domäne und Ihr API-Token ein.

   $ Okta-Login Okta-Org-URL: https:// Ihre Okta-Domäne Okta-API-Token: Ihr API-Token
   

2. Erstellen Sie die App-Integration:

   $ okta apps erstellen --app-name=mywebapp --redirect-uri=http[s]:// ingress-controller-hostname /_codexch
   

   Wo

   • --app-name definiert den Anwendungsnamen (hier mywebapp )
   • --redirect-uri definiert die URI, zu der Anmeldungen umgeleitet werden (hier: ingress-controller-hostname /_codexch )

3. Geben Sie den Anwendungstyp als Antwort auf die Eingabeaufforderungen an, zunächst mit1 (darstellt eine Webanwendung) und dann5 (stellt ein anderes Framework als die aufgelisteten dar).

   Anwendungstyp
   (Die Okta CLI unterstützt nur eine Teilmenge von Anwendungstypen und -eigenschaften):
   > 1: Web
   > 2: Einzelseiten-App
   > 3: Native App (mobil)
   > 4: Service (Machine-to-Machine)
   Geben Sie Ihre Auswahl ein [Web]: 1
   Art der Anwendung
   > 1: Okta Spring Boot Starter
   > 2: Spring Boot
   > 3: JHipster
   > 4: Quarkus
   > 5: Sonstiges
   Geben Sie Ihre Auswahl ein [Sonstiges]: 5
   Eine neue OIDC-Anwendung konfigurieren, fast fertig:
   OIDC-Anwendung erstellt, Client-ID: 0oa1mi...OrfQAg5d7
   

Konfigurieren des NGINX Ingress Controllers

Konfigurieren Sie die auf NGINX Plus basierende Version des NGINX Ingress Controller als Weiterleitungspartei, die Benutzer authentifiziert.

Definieren eines geheimen Clientanmeldeinformationen-Schlüssels

Aus Sicherheitsgründen wird die Festcodierung des Client-Geheimnisses im OIDC-Richtlinienobjekt nicht unterstützt. Stattdessen erstellen wir ein Kubernetes-Geheimnis mit Daten, die den Base64-codierten Wert des Client-Geheimnisses enthalten.

API-Version: v1 Art: Geheime Metadaten: Name: oidc-secret Typ: nginx.org/oidc Daten: Client-Geheimnis: Base64-codierter Wert des Client-Geheimnisses 

Wenden Sie dann die YAML-Datei an, die das Geheimnis enthält (hier client-secret.yaml ):

$ kubectl apply –f client-secret.yaml

Abrufen der Authentifizierungsendpunkte

Verwenden Sie die OAuth 2.0- und OpenID Connect-API, um Informationen zu den Endpunkten zu erhalten, die Okta auf seinen Autorisierungsservern bereitstellt.

Führen Sie den folgenden Befehl auf Ihrem lokalen Computer aus, um Informationen zu Ihren Okta-Endpunkten auszugeben. Beachten Sie die Werte von authorization_endpoint , token_endpoint und jwks_uri wie in der Beispielausgabe gezeigt. Sie verwenden sie im nächsten Abschnitt .

$ curl -i https:// Ihre Okta-Domäne /.well-known/openid-configuration { "authorization_endpoint": "https:// Ihre Okta-Domäne /oauth2/v1/authorize", ... "jwks_uri": "https:// Ihre Okta-Domäne /oauth2/v1/keys", ... "token_endpoint": "https:// Ihre Okta-Domäne /oauth2/v1/token", ... }

Definieren der NGINX Ingress OIDC-Richtlinie

Unterstützung für OIDC-basierte Authentifizierung wurde in NGINX Ingress Controller 1.10.0 hinzugefügt. Ausführliche Informationen finden Sie in unserem Blog im Artikel „Einfaches und robustes Single Sign-On mit OpenID Connect und NGINX Ingress Controller“ .

Die NGINX Ingress Controller-Implementierung der OIDC-Authentifizierung verwendet ein Policy- Objekt, eine benutzerdefinierte Kubernetes-Ressource , die eine OIDC-Richtlinie im NGINX Ingress Controller definiert.

1. Fügen Sie die im vorherigen Abschnitt erhaltenen Informationen in die Felder authEndpoint , tokenEndpoint und jwksURI des Policy- Objekts ein.

   API-Version: k8s.nginx.org/v1 Art: Metadaten der Richtlinie: Name: oidc-policy spec: oidc: clientID: Client-ID ClientSecret: oidc-secret authEndpoint: https:// Ihre Okta-Domäne /oauth2/v1/authorize tokenEndpoint: https:// Ihre Okta-Domäne /oauth2/v1/token jwksURI: https:// Ihre Okta-Domäne /oauth2/v1/keys
   

2. Wenden Sie die Richtlinie an (hier in oidc.yaml definiert):

   $ kubectl apply -f oidc.yaml
   

3. (Optional) Überprüfen Sie die Gültigkeit der Richtlinie:

   $ kubectl get policy NAME STATE AGE oidc-policy Gültig 2m
   

Definieren des VirtualServer-Objekts

VirtualServer und VirtualServerRoute sind NGINX-Ingress-Ressourcen , die die Regeln für die Weiterleitung des eingehenden Datenverkehrs an die Back-End-Anwendungen im Kubernetes-Cluster bereitstellen. Damit eine OIDC-Richtlinie wirksam wird, muss in einer VirtualServer- oder VirtualServerRoute-Ressource darauf verwiesen werden.

1. Verweisen Sie unter dem Pfadpräfix / auf eine OIDC-Richtlinie, damit Benutzer, die Pfade anfordern, die mit dem Präfix übereinstimmen, authentifiziert werden, bevor die Anforderung an den App-Server-Payload- Dienst weitergeleitet wird.

   API-Version: k8s.nginx.org/v1
   Art: VirtualServer
   Metadaten:
   Name: app-ingress
   Spezifikation:
   Host: unit-demo.linkpc.net
   Upstreams:
   -Name: app-server-payload
   Dienst: app-server-svc
   Port: 80
   Routen:
   - Pfad: /
   Richtlinien:
   - Name: oidc-policy
   Aktion:
   Proxy: 
   Upstream: App-Server-Payload
   

2. Wenden Sie die VirtualServer-Ressource an (hier definiert in app-virtual-server.yaml ):

   $ kubectl apply -f app-virtual-server.yaml
   

3. (Optional.) Überprüfen Sie die Gültigkeit der Ressource:

   $ kubectl get vs NAME STAAT HOST IP PORTS ALTER app-ingress Gültige unit-demo.linkpc.net 2m
   

Testen der Umgebung

Um zu testen, ob die OIDC Okta-Integration ordnungsgemäß funktioniert, geben Sie den Hostnamen des NGINX Ingress Controllers in die Adressleiste Ihres Browsers ein. Sie werden zum Okta-Anmeldeportal weitergeleitet, wo Sie die Anmeldeinformationen für Ihr Okta-Entwicklerkonto eingeben können, um Zugriff auf die Backend-Anwendung zu erhalten.

Nach erfolgreicher Authentifizierung erhalten Sie Zugriff auf den Upstream-Dienst „App-Server-Payload“ .

Hinzufügen von Benutzern zur Anwendung

In den meisten Fällen müssen mehrere Benutzer in Ihrer Organisation auf Ihre Apps zugreifen. Fügen Sie jeden Benutzer auf der Seite „Personen“ unter der Kategorie „Verzeichnis“ in der Okta-Administratorkonsole hinzu.

Erstellen von SSO-Integrationen für mehrere Apps

Wir haben den Authentifizierungsprozess aus einer Anwendung ausgelagert, indem wir SSO mit Okta als IdP und NGINX Ingress Controller als Weiterleitungspartei konfiguriert haben. In der Praxis möchten Sie Benutzern wahrscheinlich den Zugriff auf viele Anwendungen mit einem einzigen Satz Anmeldeinformationen ermöglichen. Möglicherweise möchten Sie auch die Flexibilität haben, zu variieren, auf welche Anwendungen ein Benutzer zugreifen kann. Sie können dies tun, indem Sie die Anweisungen in den obigen Abschnitten wiederholen:

• Vorkonfigurieren des IdP zur Integration anderer Anwendungen in Okta
• Definieren der NGINX Ingress OIDC-Richtlinie zum Definieren anderer OIDC-Richtlinien
• Definieren des VirtualServer-Objekts zum Verweisen auf zusätzliche Richtlinien

In dem im folgenden Diagramm dargestellten Beispiel gibt es zwei Subdomänen, unit-demo.marketing.net und unit-demo.engineering.net , die in die externe IP-Adresse des NGINX Ingress Controller aufgelöst werden. Der NGINX Ingress Controller leitet Anfragen basierend auf der Subdomäne entweder an die Marketing- App oder an die Engineering- App weiter. Um einem Benutzer Zugriff zu gewähren, ordnen Sie den Benutzer auf der Registerkarte „Zuweisungen “ der Okta-GUI jeder entsprechenden Anwendung zu. Okta gewährt dem authentifizierten Benutzer dann ein kurzlebiges Sitzungscookie für den Zugriff auf diese Anwendungen.

Abschluss

Durch die Implementierung von OIDC-basiertem SSO in Kubernetes unter Verwendung von NGINX Ingress Controller als Weiterleitungspartei und Okta als IdP entlasten Sie Ihre Entwickler von Authentifizierung und Autorisierung, sodass diese sich auf die Optimierung der Geschäftslogik in ihren Apps konzentrieren können. Um mit dem auf NGINX Plus basierenden NGINX Ingress Controller zu beginnen, fordern Sie noch heute eine kostenlose 30-Tage-Testversion an oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .