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.
Ce blog suppose que vous avez de l'expérience dans les environnements Kubernetes. De plus, vous aurez besoin des éléments suivants :
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.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 .
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
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 )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
Configurez la version basée sur NGINX Plus de NGINX Ingress Controller comme partie relais qui authentifie les utilisateurs.
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
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", ... }
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.
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
Appliquer la politique (ici définie dans oidc.yaml ) :
$ kubectl apply -f oidc.yaml
(Facultatif) Vérifiez la validité de la politique :
$ kubectl get policy NOM ÉTAT ÂGE oidc-policy Valide 2m
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.
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
Appliquer la ressource VirtualServer (ici définie dans app-virtual-server.yaml ) :
$ kubectl apply -f app-virtual-server.yaml
(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
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
.
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.
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 :
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.
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 .
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."