Mécanismes d’authentification externes

1. Présentation du mécanisme

Dans Kubernetes, il n’existe pas de type pour représenter un utilisateur : ils sont directement référencés sous la forme d’un identifiant (clement, admin@my-company.com) ou d’un groupe (administrator, intranet, etc.).

Dans la suite du chapitre, l’accès à l’aide d’identifiants OAuth2 sera abordé.

L’accès par identifiants OAuth2 est assez similaire à ce qui a été fait dans le chapitre Sécurisation : accès aux applications. L’exercice se fera avec les API de Google, mais les instructions sont tout à fait transposables avec celle de GitHub ou de n’importe quel fournisseur d’identifiants OAuth2.

2. Communication entre le fournisseur OAuth2 et le cluster

L’authentification entre le cluster et le fournisseur d’identifiants s’appuie sur le protocole OpenID Connect (une extension répandue du protocole OAuth2 supportée par Google ou Azure). OpenID Connect OAuth2

Le principal ajout est la présence d’un champ contenant un jeton d’identification de type JWT (JSON Web Token). Ce jeton sert à l’authentification de l’utilisateur et peut également contenir des champs supplémentaires comme par exemple l’e-mail de l’utilisateur. Il est également signé par le fournisseur d’identité. JWT JSON Web Token

images/24EP02.png

Diagramme...

Pour consulter la suite, découvrez le livre suivant :
couv_EPKUB.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Authentification et autorisation
Suivant
Objectifs du chapitre et prérequis