Implémentation de l'authentification OpenID Connect pour Kubernetes avec Okta et NGINX Ingress Controller

Nous avons écrit à plusieurs reprises sur l’importance de sécuriser vos applications et API dans le climat actuel d’attaques par ransomware et par robots. Outre des mécanismes tels que le pare-feu d’application Web (WAF), l’authentification des identités des utilisateurs et l’application de contrôles d’autorisation sont des moyens importants pour protéger vos applications professionnelles.

Le moyen le plus direct d’implémenter l’authentification et l’autorisation est dans les applications elles-mêmes. Bien que cela puisse fonctionner lorsque votre base d’utilisateurs est petite et que votre application ne nécessite pas de mises à jour fréquentes, cela devient rapidement intenable à grande échelle. D’une part, lorsque vos utilisateurs doivent mémoriser un nom de compte et un mot de passe différents pour chacune des nombreuses applications, ils sont souvent accueillis par des messages frustrants « nom d’utilisateur ou mot de passe incorrect » lorsqu’ils essaient de se connecter, ce qui les conduit à recourir à des solutions non sécurisées comme des mots de passe « abc123 » faciles à deviner. Et nous avons tous vu des écrans ornés d’un halo de notes Post‑it® portant des rappels de mots de passe !

Les technologies d’authentification unique (SSO) peuvent résoudre partiellement ces problèmes en éliminant tous ces noms d’utilisateur et mots de passe distincts au profit d’un seul ensemble d’informations d’identification. Les utilisateurs se connectent une seule fois auprès d'un fournisseur d'identité (IdP) pour accéder à de nombreuses applications. Mais les développeurs doivent toujours inclure du code dans leurs applications pour interagir avec le système SSO, ce qui peut s’avérer très difficile, en particulier lorsque les applications deviennent de plus en plus complexes.

À mesure que les organisations évoluent et doivent répondre aux exigences d'une base d'utilisateurs en pleine croissance, il devient essentiel de décharger les exigences qui ne sont pas spécifiques aux fonctionnalités d'une application, telles que l'authentification et l'autorisation, de la couche applicative. L’emplacement idéal pour l’authentification et l’autorisation centralisées dans Kubernetes est le contrôleur d’entrée , qui peut examiner tout le trafic entrant dans le cluster et l’acheminer vers les services appropriés. Cela libère les développeurs de la charge de créer, de maintenir et de répliquer la logique d’authentification et ils peuvent facilement exploiter les technologies SSO au niveau de la couche d’entrée à l’aide de l’API Kubernetes native.

Dans ce blog, nous montrons comment mettre en œuvre une solution SSO à part entière avec le contrôleur d'entrée NGINX basé sur NGINX Plus fonctionnant comme partie relais, prenant en charge le flux de code d'autorisation OIDC avec Okta comme fournisseur d'identité préconfiguré (IdP).

Note: Cette fonctionnalité n'est pas disponible avec le contrôleur d'entrée NGINX Open Source basé sur NGINX.

Prérequis

Ce blog suppose que vous avez de l'expérience dans les environnements Kubernetes. De plus, vous aurez besoin des éléments suivants :

• Un environnement Kubernetes – NGINX Ingress Controller est pris en charge sur Kubernetes vanilla ainsi que sur de nombreuses plateformes Kubernetes, notamment Amazon Elastic Kubernetes (EKS), bare metal, Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher Kubernetes Engine et Red Hat OpenShift.
• Contrôleur d’entrée NGINX basé sur NGINX Plus – Vous devez disposer d’une licence valide pour la version de NGINX Ingress Controller basée sur NGINX Plus . Vous pouvez commencer à utiliser une licence dès aujourd'hui en demandant un essai gratuit de 30 jours . Pour plus d'informations, consultez notre documentation .
• Un compte développeur Okta – Pour configurer Okta comme IdP, commencez par créer un compte développeur. Comme alternative, téléchargez l’ interface de ligne de commande Okta (CLI) et exécutez la commande okta register pour créer un nouveau compte. Au moment de la rédaction de cet article, l'interface de ligne de commande Okta est en version bêta et n'est pas recommandée pour une utilisation en production.

Préconfiguration de l'IdP

Les services cloud doivent savoir où récupérer et vérifier les identités des utilisateurs, c'est là qu'un IdP devient nécessaire. Un IdP gère et stocke les identités numériques en toute sécurité et garantit que les attaquants ne peuvent pas voler d’identités pour se faire passer pour des utilisateurs.

Dans cette section, nous utilisons l'interface de ligne de commande Okta pour préconfigurer Okta en tant qu'IdP, créant ainsi ce qu'Okta appelle une intégration d'application .

1. Exécutez la commande okta login pour authentifier l’interface de ligne de commande Okta avec votre compte de développeur Okta. Saisissez votre domaine Okta et votre jeton API lorsque vous y êtes invité.

   $ okta login URL de l'organisation Okta : https:// votre-domaine-okta Jeton API Okta : votre-jeton-api
   

2. Créer l’intégration de l’application :

   $ okta apps create --app-name=mywebapp --redirect-uri=http[s]:// nom-hôte-du-contrôleur-d'entrée /_codexch
   

   où

   • --app-name définit le nom de l'application (ici, mywebapp )
   • --redirect-uri définit l'URI vers lequel les connexions sont redirigées (ici, ingress-controller-hostname /_codexch )

3. Spécifiez le type d’application en réponse aux invites, d’abord avec1 (représentant une application Web) puis5 (représentant un cadre autre que ceux listés).

   Type d'application
   (L'interface de ligne de commande Okta ne prend en charge qu'un sous-ensemble de types et de propriétés d'applications) :
   > 1 : Web
   > 2 : Application à page unique
   > 3 : Application native (mobile)
   > 4 : Service (Machine-to-Machine)
   Entrez votre choix [Web] : 1
   Type de demande
   > 1 : Démarreur de démarrage Okta Spring
   > 2 : Botte à ressort
   > 3 : JHipster
   > 4 : Quarkus
   > 5 : Autre
   Entrez votre choix [Autre] : 5
   Configuration d'une nouvelle application OIDC, presque terminée :
   Application OIDC créée, ID client : 0oa1mi...OrfQAg5d7
   

Configuration du contrôleur d'entrée NGINX

Configurez la version basée sur NGINX Plus de NGINX Ingress Controller comme partie relais qui authentifie les utilisateurs.

Définition d'un secret d'identification client

Pour des raisons de sécurité, le codage en dur du secret client dans l'objet de stratégie OIDC n'est pas pris en charge. Au lieu de cela, nous créons un secret Kubernetes avec des données contenant la valeur codée en base64 du secret client.

apiVersion: v1 type: Métadonnées secrètes : nom : oidc-secret type : nginx.org/oidc données : client-secret : valeur-codée-en-base64-du-client-secret 

Appliquez ensuite le fichier YAML contenant le Secret (ici, client-secret.yaml ) :

$ kubectl apply –f client-secret.yaml

Obtenir les points de terminaison d'authentification

Utilisez l' API OAuth 2.0 et OpenID Connect pour obtenir des informations sur les points de terminaison qu'Okta expose sur ses serveurs d'autorisation.

Exécutez la commande suivante sur votre machine locale pour générer des informations sur vos points de terminaison Okta. Notez les valeurs de authority_endpoint , token_endpoint et jwks_uri comme indiqué dans l’exemple de sortie. Vous les utiliserez dans la section suivante .

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

Définition de la politique OIDC d'entrée NGINX

La prise en charge de l’authentification basée sur OIDC a été ajoutée dans NGINX Ingress Controller 1.10.0. Pour plus de détails, lisez Authentification unique simple et robuste avec OpenID Connect et NGINX Ingress Controller sur notre blog.

L’implémentation de l’authentification OIDC par NGINX Ingress Controller utilise un objet Policy , une ressource personnalisée Kubernetes qui définit une politique OIDC dans NGINX Ingress Controller.

1. Insérez les informations obtenues dans la section précédente dans les champs authEndpoint , tokenEndpoint et jwksURI de l'objet Policy .

   apiVersion: k8s.nginx.org/v1 type: Métadonnées de la politique : nom : oidc-policy spec : oidc : clientID : client-id clientSecret : oidc-secret authEndpoint : https:// votre-domaine-okta /oauth2/v1/authorize tokenEndpoint : https:// votre-domaine-okta /oauth2/v1/token jwksURI : https:// votre-domaine-okta /oauth2/v1/keys
   

2. Appliquer la politique (ici définie dans oidc.yaml ) :

   $ kubectl apply -f oidc.yaml
   

3. (Facultatif) Vérifiez la validité de la politique :

   $ kubectl get policy NOM ÉTAT ÂGE oidc-policy Valide 2m
   

Définition de l'objet VirtualServer

VirtualServer et VirtualServerRoute sont des ressources NGINX Ingress qui fournissent les règles de routage du trafic entrant vers les applications back-end du cluster Kubernetes. Pour qu'une stratégie OIDC prenne effet, elle doit être référencée dans une ressource VirtualServer ou VirtualServerRoute.

1. Faites référence à une politique OIDC sous le préfixe / path afin que les utilisateurs qui demandent des chemins correspondant au préfixe soient authentifiés avant que la demande ne soit transmise par proxy au service app-server-payload .

   apiVersion : k8s.nginx.org/v1
   type : VirtualServer
   métadonnées :
   nom : app-ingress
   spécification :
   hôte : unit-demo.linkpc.net
   flux en amont :
   - nom : app-server-payload
   service : app-server-svc
   port : 80
   routes :
   - chemin : /
   politiques :
   - nom : oidc-policy
   action :
   proxy : 
   en amont : app-server-payload
   

2. Appliquer la ressource VirtualServer (ici définie dans app-virtual-server.yaml ) :

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

3. (Facultatif.) Vérifier la validité de la ressource :

   $ kubectl get vs NOM ÉTAT HÔTE IP PORTS ÂGE app-ingress Valide unit-demo.linkpc.net 2m
   

Tester l'environnement

Pour tester que l'intégration OIDC Okta fonctionne correctement, saisissez le nom d'hôte du contrôleur d'entrée NGINX dans la barre d'adresse de votre navigateur. Vous êtes redirigé vers le portail de connexion Okta, où vous pouvez saisir les informations d'identification de votre compte de développeur Okta pour accéder à l'application backend.

Une fois authentifié avec succès, vous avez accès au service en amont app-server-payload .

Ajout d'utilisateurs à l'application

Dans la plupart des cas, plusieurs utilisateurs de votre organisation doivent accéder à vos applications. Ajoutez chaque utilisateur sur la page Personnes sous la catégorie Répertoire dans la console d’administration Okta.

Création d'intégrations SSO pour plusieurs applications

Nous avons déchargé le processus d’authentification d’une application en configurant SSO avec Okta comme IdP et NGINX Ingress Controller comme partie relais. En pratique, vous souhaitez probablement permettre aux utilisateurs d’accéder à de nombreuses applications à l’aide d’un seul ensemble d’informations d’identification. Vous souhaiterez peut-être également avoir la possibilité de varier les applications auxquelles un utilisateur peut accéder. Vous pouvez le faire en répétant les instructions dans les sections ci-dessus :

• Préconfiguration de l'IdP pour intégrer d'autres applications avec Okta
• Définition de la politique OIDC d'entrée NGINX pour définir d'autres politiques OIDC
• Définition de l'objet VirtualServer pour référencer des politiques supplémentaires

Dans l'exemple illustré dans le diagramme suivant, il existe deux sous-domaines, unit-demo.marketing.net et unit-demo.engineering.net , qui correspondent à l'adresse IP externe de NGINX Ingress Controller. NGINX Ingress Controller achemine les requêtes vers l'application marketing ou vers l'application d'ingénierie en fonction du sous-domaine. Pour accorder l'accès à un utilisateur, dans l'onglet Affectations de l'interface graphique Okta, vous associez l'utilisateur à chaque application appropriée. Okta accorde ensuite à l’utilisateur authentifié un cookie de session de courte durée pour accéder à ces applications.

Conclusion

En implémentant l'authentification unique basée sur OIDC dans Kubernetes à l'aide de NGINX Ingress Controller comme partie relais et d'Okta comme IdP, vous déchargez l'authentification et l'autorisation de vos développeurs, leur permettant ainsi de se concentrer sur l'optimisation de la logique métier dans leurs applications. Pour commencer à utiliser le contrôleur d'entrée NGINX basé sur NGINX Plus , demandez dès aujourd'hui un essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d'utilisation .