Ajouter OAuth2 aux blocs-notes Jupyter sur Kubernetes

True Foundry les utilisateurs peuvent déployer des ordinateurs portables Jupyter sur leurs comptes cloud personnels, tels qu'AWS, Azure ou GCP. Cette fonctionnalité leur permet de réaliser facilement des expériences d'apprentissage automatique et des tâches de formation sur leurs propres machines. Au départ, les ordinateurs portables déployés via TrueFoundry étaient sécurisés à l'aide d'une combinaison nom d'utilisateur et mot de passe. Cependant, en réponse aux nombreuses demandes des clients, nous avons intégré l'authentification unique. Cela signifie que les utilisateurs peuvent désormais accéder facilement à leurs blocs-notes avec le même identifiant que celui utilisé pour TrueFoundry. Ce billet de blog explique en détail comment nous avons implémenté cette fonctionnalité.

Carnets sur TrueFoundry

TrueFoundry utilise en interne un fork de Kubeflow Notebook Controller pour orchestrer le déploiement des blocs-notes. Le contrôleur fournit diverses fonctionnalités que nous exploitons, telles que :

1. Spécifications de bloc-notes simplifiées : les API Kubeflow Notebook sont simples et le contrôleur orchestre la création des déploiements de Jupyter Notebook.
2. Élimination automatique : la manette arrête automatiquement l'ordinateur portable après un certain temps d'inactivité. Cela est extrêmement utile pour nos clients qui mènent des expériences sur des ordinateurs portables équipés de machines GPU.
3. Répertoire personnel permanent : le contrôleur se charge de créer un volume persistant qui enregistre la progression de l'utilisateur sur le bloc-notes d'une session à l'autre.
4. Images de base extensibles : le contrôleur prend en charge une suite d'images de bloc-notes de base de Jupyter Notebook et VS Code gérées par TrueFoundry. L'utilisateur peut étendre les fonctionnalités de ces images Docker en ajoutant un script de démarrage ou en installant des bibliothèques spécifiques.

À titre de contexte, voici à quoi ressemble un simple objet Kubeflow Notebook :

Version de l'API : kubeflow.org/v1
type : Notebook
métadonnées :
nom : my-notebook
spécification :
modèle :
spécification :
conteneurs :
- nom : my-notebook
image : kubeflownotebookswg/jupyter:master
args :
[
« start.sh «,
« laboratoire »,
« --LabApp.Token= »,
« --labapp.allow_remote_access='true' »,
« --labapp.allow_root='true' »,
« --LabApp.ip='*' »,
« --labapp.base_url=/test/mon-bloc-notebook/ »,
« --port=8888",
« --sans navigateur »,
]

Authentification de base pour ordinateurs portables

Avant d'implémenter OAuth2, TrueFoundry offrait aux utilisateurs la possibilité de renforcer la sécurité de leurs ordinateurs portables publics en intégrant une authentification de base. Ce niveau de sécurité supplémentaire était crucial pour garantir que seules les personnes autorisées puissent accéder au contenu sensible de ces blocs-notes. Pour implémenter cette fonctionnalité, TrueFoundry a utilisé les fonctionnalités de Plug-ins WebAssembly (Wasm) dans le proxy Istio, en particulier le Proxy Envoyé.

Istio, un maillage de services open source, offre un cadre pour gérer les communications réseau entre les différentes charges de travail de service. Avec Istio, TrueFoundry a été habilité à injecter une logique personnalisée directement dans la couche réseau, qui est gérée par le proxy Envoy. Cette approche a permis de contrôler et de sécuriser efficacement le trafic entrant et sortant de leurs ordinateurs portables Jupyter. La clé de la mise en œuvre de l'authentification de base était le WASMPlugin, une fonctionnalité d'Istio qui facilite le déploiement des modules WebAssembly dans le proxy Envoy.

Cette authentification de base WASMPlugin est intégrée à une séquence de filtres réseau au sein du proxy Envoy. Ces filtres permettent l'exécution de fonctions de niveau supérieur liées au contrôle d'accès, à la transformation, à l'enrichissement des données, à l'audit, etc., améliorant ainsi la sécurité globale et les fonctionnalités du maillage de services. Voici une version simplifiée de la spécification relative à l'ajout d'un filtre d'authentification de base à la chaîne de filtres Envoy :

Version de l'API : extensions.istio.io/v1alpha1
type : WASMPlugin
métadonnées :
nom : basic-auth
espace de noms : istio-ingress
spécification :
phase : AUTHN
Configuration du plugin :
règles_d'authentification de base :
- informations d'identification :
- utilisateur:pass
hébergeurs : www.example.com
préfixe : /secret/
sélecteur :
Étiquettes de match :
Adresse : Ingressgateway
URL : oci : //ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0

OAuth2 pour ordinateur portable

Pour implémenter OAuth2 dans nos blocs-notes, nous avons utilisé un filtre Envoy, mais l'approche était différente de celle de l'authentification de base. Contrairement à l'authentification de base où nous pouvions facilement insérer un WASMPlugin prédéfini dans la chaîne de filtres, OAuth2 nécessitait une solution plus personnalisée. Pour ce faire, nous avons utilisé un filtre HTTP spécialement conçu pour OAuth. Chez TrueFoundry, notre système d'authentification unique s'intègre à FusionAuth, en tant que fournisseur OAuth.

Voici à quoi ressemble la spécification du filtre Envoy. Reportez-vous aux commentaires du fichier pour plus de détails :

Version de l'API : networking.istio.io/v1alpha3
type : EnvoyFilter
métadonnées :
nom : truefoundry-notebook-tfy-oauth2 # Nom du filtre EnvoyFilter
namespace : auth-test # Espace de noms où l'EnvoyFilter est déployé
spécification :
Sélecteur de charge de travail :
étiquettes :
truefoundry.com/application : truefoundry-notebook # Sélecteur ciblant les charges de travail avec des libellés spécifiques
Correctifs de configuration :
- Postulez auprès de : CLUSTER
match :
contexte : SIDECAR_OUTBOUND
patch :
opération : ADD
valeur :
nom : tfy-oauth2 # Nom du cluster pour le service d'authentification OAuth2
type : LOGICAL_DNS # Type de découverte de service (DNS)
connect_timeout : 5s # Délai d'établissement d'une connexion
lb_policy : ROUND_ROBIN # Politique d'équilibrage de charge
# autre configuration d'équilibrage de charge
- Appliquer à : HTTP_FILTER
match :
contexte : SIDECAR_INBOUND
auditeur :
Chaîne de filtres :
filtre :
nom : « envoy.filters.network.http_connection_manager »
Sous-filtre :
nom : envoy.filters.http.jwt_authn
patch :
opération : INSERT_BEFORE # Insérer ce filtre avant le filtre d'authentification JWT
valeur :
nom : envoy.filters.http.tfy-oauth # Nom du filtre OAuth
configuration_saisie :
« @type » : tapez .googleapis.com/envoy.extensions.filters.http.OAuth2.v3.OAuth2
configuration :
use_refresh_token : false # S'il faut utiliser un jeton d'actualisation
pass_through_matcher :
- nom : Autorisation
present_match : true # Passer si l'en-tête Authorization est présent
forward_bearer_token : true # Jeton porteur vers l'amont
auth_type : BASIC_AUTH # Type d'authentification utilisé
point de terminaison du jeton :
cluster : tfy-oauth2 # Cluster pour le point de terminaison du jeton
uri : <token-endpoint-uri-of-oauth-provider>
timeout : 5s # Délai d'expiration pour le point de terminaison du jeton
point de terminaison d'autorisation : <authorization-endpoint-uri-of-oauth-provider>
redirect_uri : https://%REQ(:authority)%/truefoundry-notebook/_auth/callback # URL de redirection pour le rappel
redirect_path_matcher :
chemin :
exact : /truefoundry-notebook/_auth/callback # Chemin pour l'URI de redirection
chemin_déconnexion :
chemin :
exact : /truefoundry-notebook/_auth/signout # Chemin de déconnexion
informations d'identification :
identifiant_client : <client-id-for-oauth>
token_secret :
# configuration pour récupérer le code secret du jeton
# pour en savoir plus sur la façon dont nous récupérons les secrets, cliquez ici :
# https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret
hmac_secret :
# configuration pour récupérer hmac

Lorsqu'un utilisateur tente d'accéder à un service protégé par le filtre OAuth2 pour la première fois, il est redirigé vers le point de terminaison d'autorisation. Ce point de terminaison est l'URL de notre fournisseur OAuth externe, qui, dans notre implémentation, est le modal de connexion TrueFoundry basé sur FusionAuth. Cette redirection est une étape cruciale du processus OAuth, car elle permet de guider les utilisateurs vers un emplacement sécurisé où ils peuvent s'authentifier et, par conséquent, accorder les autorisations nécessaires pour accéder au service.

Une fois la connexion terminée, FusionAuth vous redirigera vers le redirect_uri (configuré dans la spécification du filtre), en y ajoutant un code d'autorisation secret et temporaire. Cette demande est interceptée par le filtre et celui-ci adresse une requête à point de terminaison du jeton, en échangeant le code contre un jeton JWT. Enfin, le filtre définit les cookies à l'aide du jeton JWT.

Les accès ultérieurs au service sont transmis via le filtre HTTP puisque le cookie définit Autorisation en-tête avec JWT comme valeur. Le filtre est configuré pour traiter de telles demandes (voir pass_through_matcher dans la spécification). Pour vérifier que le JWT est un jeton valide, nous créons une politique RequestAuthentication qui vérifiera auprès du fournisseur OAuth :

Version de l'API : security.istio.io/v1beta1
type : RequestAuthentication
métadonnées :
#...
spécification :
sélecteur :
#...
Règles JW :
- émetteur : « truefoundry.com »
À partir des en-têtes :
- nom : Autorisation
préfixe : « Bearer »
publics :
- <client-id>
JWK sur : <oauth-provider-jwks-uri>
ForwardOriginalToken : vrai

Enfin, nous ajoutons la politique d'autorisation qui spécifie les demandes à appliquer Demande d'authentification à. Nous voulons appliquer une autorisation à toutes les demandes sur le port 8888 :

Version de l'API : security.istio.io/v1beta1
type : AuthorizationPolicy
métadonnées :
nom : best-notebook-tfy-oauth2
espace de noms : auth-test
spécification :
sélecteur :
Étiquettes de match :
truefoundry.com/application : meilleur ordinateur portable
action : REFUSER
règles :
- à partir de :
- source :
Not RequestDirectors : ["*"]
à :
- fonctionnement :
ports :
- « 8888 »