OpenID-Connect-Authentifizierung für Kubernetes mit Okta und dem NGINX Ingress Controller implementieren

Amir RawdatLösungsingenieur

Wir haben bereits häufig darüber geschrieben, wie wichtig es angesichts der heutigen Bedrohungslage durch Ransomware und botgesteuerte Angriffe ist, Ihre Apps und APIs abzusichern. Neben Mechanismen wie einer Web Application Firewall (WAF) sind die Authentifizierung von Benutzeridentitäten und die Durchsetzung von Autorisierungskontrollen wichtige Maßnahmen zum Schutz Ihrer Geschäftsanwendungen.

Am direktesten lassen sich Authentifizierung und Autorisierung in den Anwendungen selbst implementieren. Bei einer kleinen Benutzerbasis und wenn Ihre App nicht häufig aktualisiert werden muss, kann dies zwar funktionieren, doch bei zunehmender Skalierung wird dieser Ansatz schnell unpraktikabel. Wenn sich Ihre Benutzer beispielsweise für jede der vielen Apps einen anderen Kontonamen und ein anderes Passwort merken müssen, werden sie beim Anmeldeversuch häufig mit frustrierenden Meldungen wie „Benutzername oder Passwort falsch“ konfrontiert. Das verleitet sie dazu, auf unsichere Lösungen wie leicht zu erratende Passwörter à la „abc123“ zurückzugreifen. Und wir alle kennen Monitore, die von einem Kranz aus Post-it®-Notizen mit Passworthinweisen umgeben sind!

Single-Sign-on-Technologien (SSO) können diese Probleme teilweise lösen, indem sie all die separaten Benutzernamen und Passwörter durch einen einzigen Satz von Anmeldedaten ersetzen. Benutzer melden sich nur einmal bei einem Identitätsanbieter (Identity Provider, IdP) an und erhalten so Zugriff auf zahlreiche Anwendungen. Entwickler müssen jedoch weiterhin Code in ihre Anwendungen integrieren, um eine Verbindung zum SSO-System herzustellen. Dies kann insbesondere mit zunehmender Komplexität der Anwendungen sehr anspruchsvoll sein.

Wenn Unternehmen wachsen und die Anforderungen einer stark zunehmenden Nutzerbasis erfüllen müssen, ist es entscheidend, Anforderungen, die nicht spezifisch für die Funktionalität einer App sind – etwa Authentifizierung und Autorisierung – aus der Anwendungsschicht 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, pflegen und replizieren und können SSO-Technologien mithilfe der nativen Kubernetes-API problemlos auf der Ingress-Schicht einsetzen.

In diesem Blog zeigen wir, wie Sie eine vollwertige SSO-Lösung implementieren, bei der der auf NGINX Plus basierende NGINX Ingress Controller als vertrauende Partei fungiert und den OIDC-Autorisierungscode-Flow mit Okta als vorkonfiguriertem Identitätsanbieter (IdP) unterstützt.

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

Voraussetzungen

Dieser Blogbeitrag setzt voraus, dass Sie Erfahrung mit dem Betrieb von Kubernetes-Umgebungen haben. Darüber hinaus benötigen Sie Folgendes:

• Eine Kubernetes-Umgebung – NGINX Ingress Controller wird sowohl auf Standard-Kubernetes als auch auf 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 Ingress Controller auf Basis von NGINX Plus – Sie benötigen eine gültige Lizenz für die auf NGINX Plus basierende Version von NGINX Ingress Controller. Fordern Sie noch heute eine kostenlose 30-Tage-Testversion an. Weitere Informationen finden Sie in unserer Dokumentation.
• Ein Okta-Entwicklerkonto – Um Okta als Ihren IdP zu konfigurieren, registrieren Sie zunächst ein Entwicklerkonto. Alternativ können Sie die Okta-Befehlszeilenschnittstelle (CLI) herunterladen und den Befehl okta register ausführen, um ein neues Konto zu registrieren. Zum Zeitpunkt der Erstellung dieses Artikels 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 sie Benutzeridentitäten abrufen und überprüfen können. Hierfür ist ein IdP erforderlich. Ein IdP verwaltet und speichert digitale Identitäten sicher und sorgt dafür, 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 eine von Okta so bezeichnete App-Integration zu erstellen.

1. Führen Sie den Befehl „okta login“ aus, um die Okta CLI bei Ihrem Okta-Entwicklerkonto zu authentifizieren. Geben Sie bei den Eingabeaufforderungen Ihre Okta-Domain und Ihr API-Token ein.

$ okta login Okta Org URL: https://your-okta-domain
Okta API token: your-api-token

1. Erstellen Sie die App-Integration:

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

1. wobei
   • --app-name definiert den Namen der Anwendung (hier: mywebapp)
   • --redirect-uri definiert den URI, an den Anmeldungen weitergeleitet werden (hier: ingress-controller-hostname/_codexch)
2. Geben Sie bei den Eingabeaufforderungen den Anwendungstyp an, zunächst mit 1 (für eine Webanwendung) und anschließend mit 5 (für ein anderes als die aufgeführten Frameworks).

Type of Application
(The Okta CLI only supports a subset of application types and properties):
> 1: Web
> 2: Single Page App
> 3: Native App (mobile)
> 4: Service (Machine-to-Machine)
Enter your choice [Web]: 1
Type of Application
> 1: Okta Spring Boot Starter
> 2: Spring Boot
> 3: JHipster
> 4: Quarkus
> 5: Other
Enter your choice [Other]: 5
Configuring a new OIDC Application, almost done:
Created OIDC application, client-id: 0oa1mi...OrfQAg5d7

Konfigurieren des NGINX Ingress Controllers

Konfigurieren Sie die auf NGINX Plus basierende Version des NGINX Ingress Controllers als vertrauende Partei, die Benutzer authentifiziert.

Definieren eines Secrets für Client-Anmeldedaten

Aus Sicherheitsgründen wird die feste Einbettung des Client-Geheimnisses in das OIDC-Richtlinienobjekt nicht unterstützt. Stattdessen erstellen wir ein Kubernetes-Secret mit Daten, die den Base64-codierten Wert des Client-Geheimnisses enthalten.

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: base64-encoded-value-of-client-secret 

Wenden Sie anschließend die YAML-Datei an, die das Secret enthält (hier: client-secret.yaml):

$ kubectl apply –f client-secret.yaml

Abrufen der Authentifizierungsendpunkte

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

Führen Sie den folgenden Befehl auf Ihrem lokalen Rechner aus, um Informationen zu Ihren Okta-Endpunkten auszugeben. Notieren Sie sich die Werte für „authorization_endpoint“, „token_endpoint“ und „jwks_uri“, wie in der Beispielausgabe dargestellt. Sie benötigen diese im nächsten Abschnitt.

$ curl -i https://your-okta-domain/.well-known/openid-configuration
{
    "authorization_endpoint": "https://your-okta-domain/oauth2/v1/authorize",
    ...
    "jwks_uri": "https://your-okta-domain/oauth2/v1/keys",
    ...
    "token_endpoint": "https://your-okta-domain/oauth2/v1/token",
 ...
 }

Definieren der NGINX-Ingress-OIDC-Richtlinie

Die Unterstützung für OIDC-basierte Authentifizierung wurde mit NGINX Ingress Controller 1.10.0 eingeführt. Weitere Informationen finden Sie im Beitrag „Einfaches und zuverlässiges Single Sign-on mit OpenID Connect und NGINX Ingress Controller“ in unserem Blog.

Die Implementierung der OIDC-Authentifizierung im NGINX Ingress Controller 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.

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: oidc-policy
spec:
  oidc:
    clientID: client-id
    clientSecret: oidc-secret
    authEndpoint: https://your-okta-domain/oauth2/v1/authorize
    tokenEndpoint: https://your-okta-domain/oauth2/v1/token
    jwksURI: https://your-okta-domain/oauth2/v1/keys

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

$ kubectl apply -f oidc.yaml

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

$ kubectl get policy 

NAME          STATE   AGE
oidc-policy   Valid   2m

Definieren des VirtualServer-Objekts

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

1. Referenzieren Sie eine OIDC-Richtlinie unter dem Pfadpräfix „/“, damit Benutzer, die mit dem Präfix übereinstimmende Pfade anfordern, authentifiziert werden, bevor die Anfrage an den Dienst „app-server-payload“ weitergeleitet wird.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app-ingress
spec:
  host: unit-demo.linkpc.net
  upstreams:
  - name: app-server-payload
    service: app-server-svc
    port: 80
  routes:
  - path: /
    policies:
    - name: oidc-policy
    action:
      proxy: 
        upstream: app-server-payload

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

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

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

$ kubectl get vs

NAME          STATE   HOST                   IP    PORTS   AGE
app-ingress   Valid   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. Dort können Sie die Anmeldedaten Ihres Okta-Entwicklerkontos eingeben, um Zugriff auf die Backend-Anwendung zu erhalten.

Nach erfolgreicher Authentifizierung erhalten Sie Zugriff auf den Upstream-Dienst app-server-payload.

Benutzer zur Anwendung hinzufügen

In den meisten Fällen benötigen mehrere Benutzer in Ihrer Organisation Zugriff auf Ihre Apps. Fügen Sie jeden Benutzer auf der Seite „Personen“ in der Kategorie „Verzeichnis“ der Okta-Admin-Konsole hinzu.

SSO-Integrationen für mehrere Apps erstellen

Wir haben den Authentifizierungsprozess aus einer Anwendung ausgelagert, indem wir SSO mit Okta als IdP und dem NGINX Ingress Controller als vertrauender Partei konfiguriert haben. In der Praxis möchten Sie Benutzern wahrscheinlich ermöglichen, mit einem einzigen Satz von Anmeldedaten auf mehrere Anwendungen zuzugreifen. Möglicherweise möchten Sie auch flexibel festlegen können, auf welche Anwendungen ein Benutzer zugreifen darf. Wiederholen Sie dazu die Anweisungen in den vorherigen Abschnitten:

• Vorkonfigurieren des IdP zur Integration weiterer Anwendungen mit Okta
• Definieren der NGINX Ingress OIDC-Richtlinie zum Definieren weiterer OIDC-Richtlinien
• Definieren des VirtualServer-Objekts zum Referenzieren zusätzlicher Richtlinien

In dem im folgenden Diagramm dargestellten Beispiel gibt es zwei Subdomains, unit-demo.marketing.net und unit-demo.engineering.net, die auf die externe IP-Adresse des NGINX Ingress Controllers verweisen. Der NGINX Ingress Controller leitet Anfragen je nach Subdomain entweder an die Marketing-App oder die Engineering-App weiter. Um einem Benutzer Zugriff zu gewähren, ordnen Sie ihn auf der Registerkarte Zuweisungen in der Okta-Benutzeroberfläche den jeweils entsprechenden Anwendungen zu. Okta stellt dem authentifizierten Benutzer anschließend ein kurzlebiges Sitzungscookie für den Zugriff auf diese Anwendungen aus.

Fazit

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

Über den Autor

Amir RawdatLösungsingenieur

Weitere Blogbeiträge von Amir Rawdat