Hinzufügen von OAuth2 zu Jupyter Notebooks auf Kubernetes

Wahre Gießerei Benutzer können Stellen Sie Jupyter Notebooks bereit auf ihren persönlichen Cloud-Konten wie AWS, Azure oder GCP. Mit dieser Funktion können sie mühelos Experimente zum maschinellen Lernen und Trainingsjobs auf ihren eigenen Computern durchführen. Anfänglich wurden Notebooks, die über TrueFoundry bereitgestellt wurden, mit einer Kombination aus Benutzername und Passwort gesichert. Als Reaktion auf weit verbreitete Kundenanfragen haben wir jedoch Single Sign-On integriert. Das bedeutet, dass Benutzer jetzt bequem mit demselben Login, das sie für TrueFoundry verwenden, auf ihre Notebooks zugreifen können. Dieser Blogbeitrag befasst sich mit den Einzelheiten, wie wir diese Funktion implementiert haben.

Notizbücher auf TrueFoundry

TrueFoundry verwendet intern einen Fork von Kubeflow Notebook Controller, um die Bereitstellung von Notebooks zu orchestrieren. Der Controller bietet verschiedene Funktionen, die wir nutzen, wie zum Beispiel:

1. Vereinfachte Notebook-Spezifikation: Die Kubeflow Notebook-APIs sind einfach und der Controller orchestriert die Erstellung der Jupyter Notebook-Bereitstellungen.
2. Automatisches Ausblenden: Der Controller fährt das Notebook nach einer bestimmten Zeit der Inaktivität automatisch herunter. Dies ist unglaublich nützlich für unsere Kunden, die Experimente auf Notebooks durchführen, die von GPU-Computern unterstützt werden.
3. Persistentes Home-Verzeichnis: Der Controller sorgt für die Erstellung eines persistenten Volumes, das den Benutzerfortschritt sitzungsübergreifend auf dem Notebook speichert.
4. Erweiterbare Basis-Images: Der Controller unterstützt eine Reihe von Basis-Notebook-Images von Jupyter Notebook und VS Code, die von TrueFoundry verwaltet werden. Der Benutzer kann die Funktionen dieser Docker-Images erweitern, indem er ein Startskript hinzufügt oder bestimmte Bibliotheken installiert.

Zum Kontext sieht ein einfaches Kubeflow Notebook-Objekt so aus:

apiVersion: kubeflow.org/v1
kind: Notebook
metadata:
 name: my-notebook
spec:
 template:
   spec:
     containers:
       - name: my-notebook
         image: kubeflownotebookswg/jupyter:master
         args:
           [
             "start.sh",
             "lab",
             "--LabApp.token=''",
             "--LabApp.allow_remote_access='True'",
             "--LabApp.allow_root='True'",
             "--LabApp.ip='*'",
             "--LabApp.base_url=/test/my-notebook/",
             "--port=8888",
             "--no-browser",
           ]

Basic Auth für Notebooks

Vor der Implementierung von OAuth2 bot TrueFoundry Benutzern die Möglichkeit, die Sicherheit ihrer öffentlichen Notebooks durch die Integration der Standardauthentifizierung zu erhöhen. Diese zusätzliche Sicherheitsebene war entscheidend, um sicherzustellen, dass nur autorisierte Personen auf den vertraulichen Inhalt dieser Notizbücher zugreifen konnten. Um diese Funktion zu implementieren, nutzte TrueFoundry die Funktionen von WebAssembly (Wasm) -Plugins innerhalb des Istio-Proxys, insbesondere der Proxy für Gesandte.

Istio, ein Open-Source-Service-Mesh, bietet ein Framework für die Verwaltung der Netzwerkkommunikation zwischen verschiedenen Service-Workloads. Mit Istio wurde TrueFoundry in die Lage versetzt, benutzerdefinierte Logik direkt in die Netzwerkebene einzufügen, die vom Envoy-Proxy verwaltet wird. Dieser Ansatz ermöglichte eine effektive Kontrolle und Sicherheit des Datenverkehrs, der zu und von ihren Jupyter-Notebooks fließt. Der Schlüssel zur Implementierung der Basisauthentifizierung war das WASMplugin, eine Funktion von Istio, die die Bereitstellung von WebAssembly-Modulen innerhalb des Envoy-Proxys erleichtert.

Dieses grundlegende WASM-Plugin für die Authentifizierung ist in eine Abfolge von Netzwerkfiltern innerhalb des Envoy-Proxys integriert. Diese Filter ermöglichen die Ausführung übergeordneter Funktionen in Bezug auf Zugriffskontrolle, Transformation, Datenanreicherung, Prüfung und mehr und verbessern so die allgemeine Sicherheit und Funktionalität des Service Mesh. Hier ist eine vereinfachte Version der Spezifikation für das Hinzufügen eines einfachen Authentifizierungsfilters zur Envoy-Filterkette:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
 name: basic-auth
 namespace: istio-ingress
spec:
 phase: AUTHN
 pluginConfig:
   basic_auth_rules:
     - credentials:
         - user:pass
       hosts: www.example.com
       prefix: /secret/
 selector:
   matchLabels:
     istio: ingressgateway
 url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0

OAuth2 für Notebook

Für die Implementierung von OAuth2 in unseren Notebooks verwendeten wir einen Envoy-Filter, aber der Ansatz unterschied sich von dem der Standardauthentifizierung. Im Gegensatz zur Basisauthentifizierung, bei der wir bequem ein vorgefertigtes WASM-Plugin in die Filterkette einfügen konnten, benötigte OAuth2 eine maßgeschneidertere Lösung. Um dies zu erreichen, verwendeten wir einen HTTP-Filter, der speziell für OAuth entwickelt wurde. Bei TrueFoundry lässt sich unser Single Sign-On-System integrieren mit FusionAuth, der als unser OAuth-Anbieter fungiert.

So sieht die Envoy-Filter-Spezifikation aus — weitere Informationen finden Sie in den Kommentaren in der Datei:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
 name: truefoundry-notebook-tfy-oauth2  # Name of the EnvoyFilter
 namespace: auth-test  # Namespace where the EnvoyFilter is deployed
spec:
 workloadSelector:
   labels:
     truefoundry.com/application: truefoundry-notebook  # Selector targeting workloads with specific labels
 configPatches:
 - applyTo: CLUSTER
   match:
     context: SIDECAR_OUTBOUND
   patch:
     operation: ADD
     value:
       name: tfy-oauth2  # Name of the cluster for OAuth2 authentication service
       type: LOGICAL_DNS  # Type of service discovery (DNS)
       connect_timeout: 5s  # Timeout for establishing a connection
       lb_policy: ROUND_ROBIN  # Load balancing policy
       # other load balancing config
 - applyTo: HTTP_FILTER
   match:
     context: SIDECAR_INBOUND
     listener:
       filterChain:
         filter:
           name: "envoy.filters.network.http_connection_manager"
           subFilter:
             name: envoy.filters.http.jwt_authn
   patch:
     operation: INSERT_BEFORE  # Inserting this filter before the JWT auth filter
     value:
      name: envoy.filters.http.tfy-oauth  # Name of the OAuth filter
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.http.oauth2.v3.OAuth2
        config:
          use_refresh_token: false  # Whether to use a refresh token
          pass_through_matcher:
            - name: Authorization
              present_match: true  # Pass through if Authorization header is present
          forward_bearer_token: true  # Forward bearer token to upstream
          auth_type: BASIC_AUTH  # Type of authentication used
          token_endpoint:
            cluster: tfy-oauth2  # Cluster for token endpoint
            uri: <token-endpoint-uri-of-oauth-provider>
            timeout: 5s  # Timeout for token endpoint
          authorization_endpoint: <authorization-endpoint-uri-of-oauth-provider>
          redirect_uri: https://%REQ(:authority)%/truefoundry-notebook/_auth/callback  # Redirect URI for callback
          redirect_path_matcher:
            path:
              exact: /truefoundry-notebook/_auth/callback  # Path for redirect URI
          signout_path:
            path:
              exact: /truefoundry-notebook/_auth/signout  # Path for signout
          credentials:
            client_id: <client-id-for-oauth>
            token_secret:
               # configuration to fetch token secret
               # read more about how we fetch secrets here:
               # https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret
            hmac_secret:
               # configuration to fetch hmac

Wenn ein Benutzer zum ersten Mal versucht, auf einen Dienst zuzugreifen, der durch den OAuth2-Filter geschützt ist, wird er zum authorization_endpoint. Dieser Endpunkt ist die URL unseres externen OAuth-Anbieters, bei dem es sich in unserer Implementierung um das FusionAuth-basierte TrueFoundry-Login-Modal handelt. Diese Umleitung ist ein wichtiger Schritt im OAuth-Prozess. Sie führt Benutzer zu einem sicheren Ort, an dem sie sich authentifizieren und somit die erforderlichen Berechtigungen für den Zugriff auf den Dienst gewähren können.

Sobald die Anmeldung abgeschlossen ist, leitet FusionAuth Sie weiter zum redirect_uri (in der Filterspezifikation konfiguriert), indem dort ein geheimer, temporärer Autorisierungscode hinzugefügt wird. Diese Anfrage wird vom Filter abgefangen und er sendet eine Anfrage an token_endpoint, tauscht den Code gegen ein JWT-Token aus. Schließlich setzt der Filter Cookies mit dem JWT-Token.

Nachfolgende Zugriffe auf den Dienst werden durch den HTTP-Filter geleitet, da das Cookie den Authorization Header mit JWT als Wert. Der Filter ist so konfiguriert, dass er solche Anfragen durchlässt (siehe pass_through_matcher in der Spezifikation). Um zu überprüfen, ob das JWT ein gültiges Token ist, erstellen wir eine RequestAuthentication-Richtlinie, die beim OAuth-Anbieter nachfragt:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 # ...
spec:
 selector:
   # ...
 jwtRules:
 - issuer: "truefoundry.com"
   fromHeaders:
   - name: Authorization
     prefix: "Bearer "
   audiences:
     - <client-id>
   jwksUri: <oauth-provider-jwks-uri>
   forwardOriginalToken: true

Schließlich fügen wir die Autorisierungsrichtlinie hinzu, die festlegt, welche Anfragen gelten sollen RequestAuthentication zu. Wir möchten die Autorisierung auf alle Anfragen auf Port 8888 anwenden:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: best-notebook-tfy-oauth2
 namespace: auth-test
spec:
 selector:
   matchLabels:
     truefoundry.com/application: best-notebook
 action: DENY
 rules:
 - from:
   - source:
       notRequestPrincipals: ["*"]
   to:
     - operation:
         ports:
           - "8888"