Cette page explique comment utiliser un fournisseur OpenID pour configurer l'authentification pour les clusters d'utilisateurs GKE On-Prem. Pour savoir comment utiliser OIDC avec ADFS, consultez la page Assurer l'authentification avec OIDC et ADFS.
Pour une présentation du processus d'authentification de GKE On-Prem, consultez la page Authentification.
Présentation
GKE On-Prem est compatible avec OpenID Connect (OIDC) en tant que mécanisme d'authentification pour interagir avec le serveur d'API Kubernetes d'un cluster d'utilisateur. Pour que ce flux d'authentification soit automatique pour les utilisateurs de cluster, GKE On-Prem fournit le plug-in Kubectl pour OIDC, un plug-in kubectl.
Dans cet exercice, vous allez configurer une relation entre votre fournisseur OpenID et kubectl
.
Avant de commencer
Dans cette rubrique, nous partons du principe que vous connaissez bien OAuth 2.0 et OpenID Connect. Dans cette rubrique, nous partons du principe que vous connaissez bien les champs d'application et les revendications OpenID.
Choisir un fournisseur d'identité
- Utilisez Active Directory Federated Services (ADFS) en tant que fournisseur OpenID et utilisez une instance sur site d'AD comme base de données des employés Consultez la section Procéder à l'authentification à l'aide d'OIDC et d'ADFS.
- Utilisez un autre fournisseur OpenID.
Quelle que soit l'option choisie, vous pouvez utiliser le plug-in Kubectl pour OIDC, décrit dans ces instructions, pour accélérer la configuration de l'authentification et le processus d'authentification lui-même. Cet article explique comment utiliser un fournisseur OpenID autre qu'ADFS.
Télécharger le plug-in Kubectl pour OIDC
Téléchargez le plug-in et définissez les autorisations d'accès :
Linux
gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/linux_amd64/kubectl-oidc . chmod +x kubectl-oidc
Windows
gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/windows_amd64/kubectl-oidc .
macOS
gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/darwin_amd64/kubectl-oidc . chmod +x kubectl-oidc
Installer le plug-in
Installez le plug-in en déplaçant le fichier exécutable à n'importe quel emplacement de votre PATH
. Le fichier exécutable doit être nommé kubectl-oidc
. Pour en savoir plus, consultez la section Installer des plug-ins Kubectl.
Créer un URI de redirection
Dans le cadre de l'établissement d'une relation avec votre fournisseur OpenID, vous devez spécifier un URI de redirection que le fournisseur peut utiliser pour renvoyer des jetons d'ID. Les jetons sont envoyés au plug-in Kubectl pour OIDC, qui s'exécute sur la machine locale de chaque employé et écoute sur le port de votre choix. Choisissez un numéro de port supérieur à 1 024 et adapté à cet usage. Ainsi, l'URI de redirection est :
http://localhost:[PORT]/callback
où [PORT] est votre numéro de port.
Enregistrer le plug-in Kubectl pour OIDC auprès de votre fournisseur OpenID
Avant de pouvoir utiliser le plug-in Kubectl pour OIDC avec votre fournisseur OpenID, vous devez enregistrer le plug-in auprès du fournisseur. L'enregistrement comprend les étapes suivantes :
Découvrir l'URI d'émetteur du fournisseur. C'est là que le plug-in envoie les requêtes d'authentification.
Indiquer au fournisseur votre URI de redirection.
Définir un ID client. Il s'agit de l'ID utilisé par le fournisseur pour identifier le plug-in.
Définir un code secret de client. Le plug-in utilise ce code secret pour s'authentifier auprès du fournisseur OpenID.
Établir un champ d'application personnalisé que le plug-in peut utiliser pour demander les groupes de sécurité de l'utilisateur.
Établir un nom de revendication personnalisé que le fournisseur utilisera pour renvoyer les groupes de sécurité de l'utilisateur.
La procédure à suivre dépend de votre fournisseur OpenID. Pour savoir comment effectuer les étapes d'enregistrement avec ADFS, consultez la section Assurer l'authentification avec OIDC et ADFS.
Remplir la spécification oidc
dans le fichier de configuration GKE On-Prem
Pendant l'installation, vous générez un fichier de configuration GKE On-Prem à l'aide de gkectl create-config
. La configuration inclut la spécification oidc
suivante. Renseignez "oidc" avec des valeurs spécifiques à votre fournisseur :
oidc: issuerurl: kubectlredirecturl: clientid: clientsecret: username: usernameprefix: group: groupprefix: scopes: extraparams: usehttpproxy: capath:
issuerurl
: URL de votre fournisseur OpenID, telle quehttps://example.com/adfs
. Les applications clientes, telles que le plug-in Kubectl pour OIDC, envoient des requêtes d'autorisation à cette URL. Le serveur de l'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. Vous devez utiliser HTTPS. Ce champ est obligatoire.kubectlredirecturl
: URL de redirection de l'hôte local, pour le plug-in Kubectl pour OIDC. Vous devez enregistrer l'URL de redirection auprès de votre fournisseur OpenID pour l'utiliser par l'ID client attribué à ce cluster. Ce champ est obligatoire.clientid
: ID de l'application cliente, tel que le plug-in Kubectl pour OIDC, qui envoie des requêtes d'authentification au fournisseur OpenID. Ce champ est obligatoire.clientsecret
: clé secrète de l'application cliente. Ce champ est obligatoire.usehttpproxy
: choisissez de déployer un proxy inverse dans le cluster pour permettre à l'agent Connect d'accéder au fournisseur OIDC sur site pour authentifier les utilisateurs. La valeur doit être une chaîne :"true"
ou"false"
. Ce champ est obligatoire.username
: revendication JWT à utiliser comme nom d'utilisateur. La valeur par défaut estsub
, qui est censé être un identifiant unique de l'utilisateur final. Vous pouvez choisir d'autres revendications, telles queemail
ouname
, en fonction du fournisseur OIDC. Toutefois, les revendications autres queemail
sont précédées de l'URL de l'émetteur afin d'éviter les conflits avec les noms d'autres plug-ins.usernameprefix
: préfixe précédé des revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Si vous n'ajoutez pas cet indicateur et queusername
est une valeur autre que l'adresse e-mail, le préfixe est défini par défaut surissueruri#
. La valeur-
peut être utilisée pour désactiver tout préfixe.group
: revendication JWT à utiliser comme groupe de l'utilisateur. Si la revendication est présente, il doit s'agir d'un tableau de chaînes.groupprefix
: préfixe ajouté aux revendications de groupe pour éviter les conflits avec les noms existants. Par exemple, pour un groupefoobar
et un préfixegid-
donnés,gid-foobar
.scopes
: champs d'application supplémentaires à envoyer au fournisseur OpenID sous forme de liste séparée par des virgules.extraparams
: paramètres de clé-valeur supplémentaires à envoyer au fournisseur OpenID.capath
: chemin d'accès au certificat de l'autorité de certification qui a signé le certificat Web de votre fournisseur d'identité.Les clusters GKE On-Prem utilisent le protocole TLS pour sécuriser la communication entre leurs composants. Pour que Kubernetes génère automatiquement des certificats clients lors de l'installation et de l'amorçage des nœuds, GKE On-Prem doit être installé avec une autorité de certification.
Par défaut, GKE On-Prem crée une autorité de certification lors de l'installation qui génère des certificats TLS. L'autorité de certification et les certificats générés sont stockés localement dans le cluster d'administration.
Exemple : Authentifier et autoriser un groupe
De nombreux fournisseurs codent les propriétés d'identification des utilisateurs, telles que les e-mails et les ID utilisateur, dans un jeton. Cependant, ces propriétés présentent des risques implicites pour les stratégies d'authentification :
- Les ID utilisateur peuvent compliquer la lecture et l'audit des stratégies.
- Les e-mails peuvent créer un risque de disponibilité (si un utilisateur modifie son adresse e-mail principale) et éventuellement un risque de sécurité (si un e-mail peut être réattribué).
Par conséquent, il est recommandé d'utiliser des stratégies de groupe, car le GID peut être à la fois persistant et plus facile à contrôler.
Supposons que votre fournisseur crée des jetons OpenID qui incluent les champs suivants :
{ 'iss': 'https://server.example.com' 'sub': 'u98523-4509823' 'groupList: ['developers@example.corp', 'us-east1-cluster-admins@example.corp'] ... }Avec ce format de jeton, vous devez remplir la spécification
oidc
de votre fichier de configuration comme suit :
issueruri: 'https://server.example.com' username: 'sub' usernameprefix: 'uid-' group: 'groupList' groupprefix: 'gid-' ...
Une fois le cluster utilisateur créé, vous pouvez utiliser le contrôle des accès basé sur les rôles Kubernetes (RBAC) pour accorder un accès privilégié aux utilisateurs authentifiés. Par exemple, vous pouvez créer un objet ClusterRole qui accorde à ses utilisateurs un accès en lecture seule aux codes secrets du cluster, et créer une ressource ClusterRoleBinding pour lier le rôle au groupe authentifié :
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secrets-admins subjects: # Allows anyone in the "us-east1-cluster-admins" group to # read Secrets in any namespace within this cluster. - kind: Group name: gid-us-east1-cluster-admins # Name is case sensitive apiGroup: rbac.authorization.k8s.io # Allows this specific user to read Secrets in any # namespace within this cluster - kind: User name: uid-u98523-4509823 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Créer le certificat CA (autorité de certification) du serveur
Le fichier kubeconfig de votre cluster utilisateur stocke les données de l'autorité de certification de son hôte dans son champ certificate-authority-data
. Vous devez décoder cette valeur et la stocker dans un fichier local, tel que server-ca-cert
:
cat [USER_CLUSTER_KUBECONFIG] | grep certificate-authority-data | awk '{ print $2}' | base64 --decode > server-ca-cert
Générer le fichier de configuration d'authentification du client
Une fois que vous avez configuré votre cluster utilisateur pour OpenID et créé celui-ci, un utilisateur peut se connecter au cluster en transmettant un fichier de configuration d'authentification client à kubectl oidc login
. Pour générer un fichier de configuration d'authentification client, saisissez la commande suivante :
Linux
kubectl oidc client-config --issuer-uri [ISSUER_URI] \ --redirect-uri [REDIRECT_URI] \ --client-id [CLIENT_ID] \ --client-secret [CLIENT_SECRET] \ --scopes "[CUSTOM_SCOPES]" \ --cluster-name [USER_CLUSTER_NAME] \ --server [CLUSTER_URL] \ --server-ca-file server-ca-cert \ --issuer-ca-file [CA_CERT] \ --extra-params [KEY]=[VALUE] > client-config.yaml
- [ISSUER_URI] est votre URI d'émetteur.
- [REDIRECT_URI] est votre URI de redirection.
- [CLIENT_ID] est l'ID client pour l'application "kubectl".
- [CLIENT_SECRET] est le code secret du client qui a été généré automatiquement.
- [USER_CLUSTER_NAME] est le nom de votre cluster d'utilisateur.
- [CLUSTER_URL] est l'URL du serveur d'API Kubernetes du cluster d'utilisateur.
--server-ca-file
accepte le chemin d'accès au fichier CA que vous avez créé dans la section précédente.- [CA_CERT] est le chemin d'accès au fichier d'autorité de certification public de l'émetteur.
- [CUSTOM_SCOPES] est la liste de vos champs d'application personnalisés séparés par des virgules pour les groupes de sécurité.
--extra-param
envoie une paire clé-valeur avec la requête d'authentification au fournisseur OIDC.
PowerShell
kubectl oidc client-config --issuer-uri [ISSUER_URI] ` --redirect-uri [REDIRECT_URI] ` --client-id [CLIENT_ID] ` --client-secret [CLIENT_SECRET] ` --scopes "[CUSTOM_SCOPES]" ` --cluster-name [USER_CLUSTER_NAME] ` --server [CLUSTER_URL] ` --server-ca-file server-ca-cert ` --issuer-ca-file [CA_CERT] ` --extra-params [KEY]=[VALUE] > client-config.yaml
- [ISSUER_URI] est votre URI d'émetteur.
- [REDIRECT_URI] est votre URI de redirection.
- [CLIENT_ID] est l'ID client pour l'application "kubectl".
- [CLIENT_SECRET] est le code secret du client qui a été généré automatiquement.
- [USER_CLUSTER_NAME] est le nom de votre cluster d'utilisateur.
- [CLUSTER_URL] est l'URL du serveur d'API Kubernetes du cluster d'utilisateur.
--server-ca-file
accepte le chemin d'accès au fichier CA que vous avez créé dans la section précédente.- [CA_CERT] est le chemin d'accès au fichier d'autorité de certification public de l'émetteur.
- [CUSTOM_SCOPES] est la liste de vos champs d'application personnalisés séparés par des virgules pour les groupes de sécurité.
--extra-param
envoie une paire clé-valeur avec la requête d'authentification au fournisseur OIDC.
Cette commande génère un fichier d'authentification client appelé client-config.yaml
.
Ne modifiez pas manuellement ce fichier. Chaque employé qui doit s'authentifier auprès du cluster d'utilisateurs doit recevoir client-config.yaml
.
À propos des certificats TLS
Les clusters d'utilisateurs GKE On-Prem utilisent TLS pour sécuriser toutes les communications entre les composants du cluster. Pour que Kubernetes génère automatiquement des certificats clients lors de l'installation et de l'amorçage des nœuds, GKE On-Prem doit être installé avec une autorité de certification.
Par défaut, GKE On-Prem crée une autorité de certification lors de l'installation qui génère des certificats TLS. L'autorité de certification et les certificats générés sont stockés localement dans le cluster d'administration.
Authentifier contre un cluster utilisateur à l'aide du plug-in Kubectl pour OIDC
Pour vous authentifier auprès d'un cluster d'utilisateurs à l'aide du fichier d'authentification client, procédez comme suit à partir de votre machine locale ou VM :
Initialisez le plug-in à l'aide du fichier
client-config.yaml
:kubectl oidc login --clientconfig-file=client-config.yaml --user [NAME] \ --kubeconfig [KUBECONFIG_OUTPUT_PATH]
où :
- [NAME] est le nom d'utilisateur choisi.
- [KUBECONFIG_OUTPUT_PATH] est l'emplacement de sortie du fichier kubeconfig où les identifiants sont stockés.
kubectl oidc login
lance un navigateur dans lequel l'utilisateur ou l'employé peut saisir ses identifiants.Le fichier kubeconfig fourni contient désormais un jeton d'ID que kubectl peut utiliser pour s'authentifier auprès du serveur d'API Kubernetes sur le cluster d'utilisateur.
.Vous devriez maintenant être authentifié. Pour savoir si vous êtes authentifié, saisissez n'importe quelle commande
kubectl
. Exemple :kubectl get nodes --kubeconfig [KUBECONFIG_OUTPUT_PATH]