Mise en œuvre de l’authentification OpenID Connect pour Kubernetes avec Okta et le contrôleur Ingress NGINX

Amir RawdatIngénieur solutions

Nous avons écrit à maintes reprises sur l’importance de sécuriser vos applications et vos API dans le contexte actuel marqué par les rançongiciels et les attaques menées par des bots. Outre des mécanismes tels que le pare-feu d’applications web (WAF), l’authentification de l’identité des utilisateurs et l’application de contrôles d’autorisation constituent des moyens importants de protéger vos applications métier.

La manière la plus directe de mettre en œuvre l’authentification et l’autorisation consiste à les intégrer aux applications elles-mêmes. Cette approche peut fonctionner lorsque votre base d’utilisateurs est restreinte et que votre application ne nécessite pas de mises à jour fréquentes, mais elle devient rapidement intenable à grande échelle. En effet, lorsque vos utilisateurs doivent mémoriser un nom de compte et un mot de passe différents pour chacune de leurs nombreuses applications, ils se retrouvent souvent confrontés à de frustrants messages « nom d’utilisateur ou mot de passe incorrect » lorsqu’ils tentent de se connecter, ce qui les pousse à adopter des solutions peu sûres, comme des mots de passe faciles à deviner tels que « abc123 ». Et nous avons tous déjà vu des écrans entourés d’une ribambelle de notes Post-it® sur lesquelles étaient inscrits des rappels de mots de passe !

Les technologies d’authentification unique (SSO) peuvent résoudre en partie ces problèmes en remplaçant tous ces noms d’utilisateur et mots de passe distincts par un seul jeu d’identifiants. Les utilisateurs s’authentifient une seule fois auprès d’un fournisseur d’identité (IdP) pour accéder à de nombreuses applications. Toutefois, les développeurs doivent toujours intégrer à leurs applications du code permettant d’interagir avec le système SSO, ce qui peut s’avérer très complexe, en particulier à mesure que les applications gagnent en complexité.

À mesure que les organisations se développent et doivent répondre aux besoins d’une base d’utilisateurs en forte croissance, il devient essentiel de décharger la couche applicative des fonctions qui ne sont pas propres à l’application, telles que l’authentification et l’autorisation. Dans Kubernetes, l’emplacement idéal pour centraliser l’authentification et l’autorisation est le contrôleur Ingress, qui peut examiner l’ensemble du trafic entrant dans le cluster et l’acheminer vers les services appropriés. Les développeurs n’ont ainsi plus à créer, maintenir et dupliquer la logique d’authentification, et peuvent facilement tirer parti des technologies d’authentification unique (SSO) au niveau de la couche d’entrée à l’aide de l’API Kubernetes native.

Dans cet article de blog, nous expliquons comment mettre en œuvre une solution SSO complète avec NGINX Ingress Controller basé sur NGINX Plus, qui fait office de partie relais et prend en charge le flux de code d’autorisation OIDC avec Okta comme fournisseur d’identité (IdP) préconfiguré.

Remarque : Cette fonctionnalité n’est pas disponible avec NGINX Ingress Controller basé sur NGINX Open Source.

Prérequis

Cet article suppose que vous avez de l’expérience dans l’exploitation d’environnements Kubernetes. Vous aurez également besoin des éléments suivants :

• Un environnement Kubernetes – NGINX Ingress Controller est pris en charge sur Kubernetes standard ainsi que sur de nombreuses plateformes Kubernetes, notamment Amazon Elastic Kubernetes (EKS), les serveurs bare metal, Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher Kubernetes Engine et Red Hat OpenShift.
• NGINX Ingress Controller 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 obtenir une licence dès aujourd’hui en demandant un essai gratuit de 30 jours. Pour plus d’informations, consultez notre documentation.
• Un compte de développeur Okta – Pour configurer Okta comme fournisseur d’identité, commencez par créer un compte de développeur. Vous pouvez également télécharger l’interface de ligne de commande Okta (CLI) et exécuter la commande okta register pour créer un compte. À l’heure où nous écrivons ces lignes, l’interface de ligne de commande Okta est en version bêta et son utilisation en production n’est pas recommandée.

Préconfiguration du fournisseur d’identité

Les services cloud doivent savoir où récupérer et vérifier l’identité des utilisateurs, d’où la nécessité d’un fournisseur d’identité (IdP). Un IdP gère et stocke les identités numériques de manière sécurisée et empêche les attaquants de les dérober pour usurper l’identité des utilisateurs.

Dans cette section, nous utilisons l’interface de ligne de commande Okta pour préconfigurer Okta en tant que fournisseur d’identité (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. Lorsque vous y êtes invité, saisissez votre domaine Okta et votre jeton d’API.

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

1. Créez l’intégration de l’application :

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

1. où
   • --app-name définit le nom de l’application (ici, « mywebapp »)
   • --redirect-uri définit l’URI vers laquelle les utilisateurs sont redirigés après leur connexion (ici, ingress-controller-hostname/_codexch)
2. Indiquez le type d’application en réponse aux invites, d’abord avec 1 (qui correspond à une application web), puis avec 5 (qui correspond à un framework autre que ceux répertoriés).

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

Configuration du contrôleur Ingress NGINX

Configurez la version de NGINX Ingress Controller basée sur NGINX Plus en tant que partie relais chargée d’authentifier les utilisateurs.

Définition d’un secret d’identifiants 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. Nous créons à la place un Secret Kubernetes contenant la valeur du secret client encodée en base64.

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: base64-encoded-value-of-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 les 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 afficher des informations sur vos points de terminaison Okta. Notez les valeurs de « authorization_endpoint », « token_endpoint » et « jwks_uri », comme indiqué dans l’exemple de sortie. Vous les utiliserez dans la section suivante.

$ 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",
 ...
 }

Définition de la stratégie OIDC d’Ingress NGINX

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

L’implémentation de l’authentification OIDC dans NGINX Ingress Controller utilise un objet « Policy », une ressource personnalisée Kubernetes qui définit une stratégie 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
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. Appliquez la politique (définie ici dans « oidc.yaml ») :

$ kubectl apply -f oidc.yaml

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

$ kubectl get policy 

NAME          STATE   AGE
oidc-policy   Valid   2m

Définition de l’objet VirtualServer

VirtualServer et VirtualServerRoute sont des ressources NGINX Ingress qui définissent les règles d’acheminement du trafic entrant vers les applications backend 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. Référencez une stratégie OIDC sous le préfixe de chemin « / » afin que les utilisateurs qui demandent des chemins correspondant à ce préfixe soient authentifiés avant que la requête ne soit transmise au service app-server-payload.

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. Appliquez la ressource VirtualServer (définie ici dans « app-virtual-server.yaml ») :

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

1. (Facultatif.) Vérifiez la validité de la ressource :

$ kubectl get vs

NAME          STATE   HOST                   IP    PORTS   AGE
app-ingress   Valid   unit-demo.linkpc.net                 2m

Test de l’environnement

Pour vérifier que l’intégration OIDC avec Okta fonctionne correctement, saisissez le nom d’hôte du contrôleur Ingress NGINX dans la barre d’adresse de votre navigateur. Vous êtes redirigé vers le portail de connexion Okta, où vous pouvez saisir les identifiants de votre compte de développeur Okta afin d’accéder à l’application backend.

Une fois l’authentification réussie, vous accédez au service en amont « app-server-payload ».

Ajouter des 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 » de la catégorie « Annuaire » dans la console d’administration Okta.

Créer des intégrations SSO pour plusieurs applications

Nous avons délégué le processus d’authentification d’une application en configurant l’authentification unique (SSO), avec Okta comme fournisseur d’identité (IdP) et NGINX Ingress Controller comme partie relais. En pratique, vous souhaiterez probablement permettre aux utilisateurs d’accéder à plusieurs applications à l’aide d’un seul jeu d’identifiants. Vous souhaiterez peut-être également pouvoir définir les applications auxquelles chaque utilisateur peut accéder. Pour ce faire, répétez les instructions des sections précédentes :

• Préconfigurer l’IdP pour intégrer d’autres applications à Okta
• Définition de la stratégie OIDC de NGINX Ingress pour définir d’autres stratégies OIDC
• Définition de l’objet VirtualServer pour référencer des stratégies supplémentaires

Dans l’exemple illustré dans le schéma suivant, deux sous-domaines, unit-demo.marketing.net et unit-demo.engineering.net, sont associés à l’adresse IP externe de NGINX Ingress Controller. NGINX Ingress Controller achemine les requêtes vers l’application Marketing ou l’application Engineering en fonction du sous-domaine. Pour accorder l’accès à un utilisateur, associez-le à chaque application appropriée dans l’onglet Affectations de l’interface graphique d’Okta. Okta accorde ensuite à l’utilisateur authentifié un cookie de session de courte durée lui permettant d’accéder à ces applications.

Conclusion

En mettant en œuvre l’authentification unique (SSO) basée sur OIDC dans Kubernetes, avec NGINX Ingress Controller comme partie relais et Okta comme fournisseur d’identité (IdP), vous déchargez vos développeurs des tâches d’authentification et d’autorisation, ce qui leur permet de se concentrer sur l’optimisation de la logique métier de leurs applications. Pour commencer à utiliser NGINX Ingress Controller 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.

À propos de l’auteur

Amir RawdatIngénieur solutions

Autres articles de Amir Rawdat