Un court tutoriel sur la façon dont vous pouvez utiliser Keycloak pour connecter Kubernetes à votre serveur LDAP et configurer l'importation d'utilisateurs et de groupes. Cela vous permettra de configurer RBAC pour vos utilisateurs et d'utiliser un proxy d'authentification pour protéger le tableau de bord Kubernetes et d'autres applications qui ne peuvent pas s'authentifier.
Installation de Keycloak
Supposons que vous disposez déjà d'un serveur LDAP. Cela peut être Active Directory, FreeIPA, OpenLDAP ou autre. Si vous ne disposez pas de serveur LDAP, alors en principe vous pouvez créer des utilisateurs directement dans l'interface Keycloak, ou utiliser des fournisseurs oidc publics (Google, Github, Gitlab), le résultat sera quasiment le même.
Tout d'abord, installons Keycloak lui-même. L'installation peut être effectuée séparément ou directement dans un cluster Kubernetes. En règle générale, si vous disposez de plusieurs clusters Kubernetes, il serait plus facile de l'installer séparément. Par contre, vous pouvez toujours utiliser et installez-le directement dans votre cluster.
Pour stocker les données Keycloak, vous aurez besoin d'une base de données. La valeur par défaut est h2 (toutes les données sont stockées localement), mais il est également possible d'utiliser postgres, mysql ou mariadb.
Si vous décidez quand même d'installer Keycloak séparément, vous trouverez des instructions plus détaillées dans .
Configuration de la fédération
Tout d’abord, créons un nouveau royaume. Le royaume est l'espace de notre application. Chaque application peut avoir son propre domaine avec différents utilisateurs et paramètres d'autorisation. Le royaume Maître est utilisé par Keycloak lui-même et il est erroné de l'utiliser pour autre chose.
Cliquez ici Ajouter un domaine
Option
Valeur
Nom
kubernetes
Nom du profil
Kubernetes
Nom d'affichage HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >
Kubernetes vérifie par défaut si l'e-mail de l'utilisateur est confirmé ou non. Puisque nous utilisons notre propre serveur LDAP, cette vérification renverra presque toujours false. Désactivons la représentation de cette option dans Kubernetes :
Périmètres clients -> Email -> Cartographes -> Email verifié (Effacer)
Maintenant, mettons en place la fédération ; pour cela, rendez-vous sur :
Fédération des utilisateurs -> Ajouter un fournisseur… -> ldap
Voici un exemple de paramètres pour FreeIPA :
Option
Valeur
Nom d'affichage de la console
freeipa.example.org
Vendeur
Red Hat Directory Server
Attribut UUID LDAP
ipauniqueid
URL de connexion
ldaps://freeipa.example.org
DN des utilisateurs
cn=users,cn=accounts,dc=example,dc=org
Bind DN
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org
Lier les informations d'identification
<password>
Autoriser l'authentification Kerberos :
on
Royaume de Kerberos :
EXAMPLE.ORG
Principal du serveur :
HTTP/[email protected]
Onglet Clé :
/etc/krb5.keytab
Utilisateur keycloak-svc doivent être créés au préalable sur notre serveur LDAP.
Dans le cas d'Active Directory, il vous suffit de sélectionner Fournisseur : Active Directory et les paramètres nécessaires seront automatiquement saisis dans le formulaire.
Cliquez ici Épargnez
Passons maintenant à autre chose :
Fédération des utilisateurs -> freeipa.example.org -> Cartographes -> Prénom
Option
Valeur
Attribut Ldap
givenName
Activons maintenant le mappage de groupe :
Fédération des utilisateurs -> freeipa.example.org -> Cartographes -> Création
Option
Valeur
Nom
groups
Type de mappeur
group-ldap-mapper
DN des groupes LDAP
cn=groups,cn=accounts,dc=example,dc=org
Stratégie de récupération des groupes d'utilisateurs
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE
Maintenant que la configuration de la fédération est terminée, passons à la configuration du client.
Configuration client
Créons un nouveau client (une application qui recevra les utilisateurs de Keycloak). Allons-nous en:
Entreprises -> Création
Option
Valeur
identité du client
kubernetes
Type d'accès
confidenrial
URL racine
http://kubernetes.example.org/
URI de redirection valides
http://kubernetes.example.org/*
URL de l'administrateur
http://kubernetes.example.org/
Créons également une portée pour les groupes :
Portées client -> Création
Option
Valeur
Modèle
No template
Nom
groups
Chemin de groupe complet
false
Et configurez un mappeur pour eux :
Portées client -> groupes -> Cartographes -> Création
Option
Valeur
Nom
groups
Type de mappeur
Group membership
Nom de la revendication du jeton
groups
Nous devons maintenant activer le groupe de mappage dans notre périmètre client :
Entreprises -> kubernetes -> Portées client -> Étendues client par défaut
sélectionner groupes в Étendues client disponiblespousser Ajouter sélectionnée
Configurons maintenant l'authentification de notre application, rendez-vous sur :
Entreprises -> kubernetes
Option
Valeur
Autorisation activée
ON
Pressons enregistrer et avec cela la configuration du client est terminée, maintenant sur l'onglet
Entreprises -> kubernetes -> Lettres de créance
Tu peux recevoir secret que nous utiliserons plus loin.
Configuration de Kubernetes
La configuration de Kubernetes pour l'autorisation OIDC est assez triviale et pas très compliquée. Il vous suffit de mettre le certificat CA de votre serveur OIDC dans /etc/kubernetes/pki/oidc-ca.pem et ajoutez les options nécessaires pour kube-apiserver.
Pour ce faire, mettez à jour /etc/kubernetes/manifests/kube-apiserver.yaml sur tous vos masters :
...
spec:
containers:
- command:
- kube-apiserver
...
- --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.pem
- --oidc-client-id=kubernetes
- --oidc-groups-claim=groups
- --oidc-issuer-url=https://keycloak.example.org/auth/realms/kubernetes
- --oidc-username-claim=email
...Mettez également à jour la configuration de kubeadm dans le cluster afin de ne pas perdre ces paramètres lors de la mise à jour :
kubectl edit -n kube-system configmaps kubeadm-config...
data:
ClusterConfiguration: |
apiServer:
extraArgs:
oidc-ca-file: /etc/kubernetes/pki/oidc-ca.pem
oidc-client-id: kubernetes
oidc-groups-claim: groups
oidc-issuer-url: https://keycloak.example.org/auth/realms/kubernetes
oidc-username-claim: email
...Ceci termine la configuration de Kubernetes. Vous pouvez répéter ces étapes sur tous vos clusters Kubernetes.
Autorisation initiale
Après ces étapes, vous disposerez déjà d'un cluster Kubernetes avec une autorisation OIDC configurée. La seule chose est que vos utilisateurs n'ont pas encore de client configuré ni leur propre kubeconfig. Pour résoudre ce problème, vous devez configurer la distribution automatique de kubeconfig aux utilisateurs après une autorisation réussie.
Pour ce faire, vous pouvez utiliser des applications Web spéciales qui vous permettent d'authentifier l'utilisateur, puis de télécharger le kubeconfig prêt à l'emploi. L'un des plus pratiques est , il vous permet de décrire tous les clusters Kubernetes dans une seule configuration et de basculer facilement entre eux.
Pour configurer Kuberos, décrivez simplement le modèle pour kubeconfig et exécutez-le avec les paramètres suivants :
kuberos https://keycloak.example.org/auth/realms/kubernetes kubernetes /cfg/secret /cfg/templatePour des informations plus détaillées, voir sur Github.
Il est également possible d'utiliser si vous souhaitez autoriser directement sur l'ordinateur de l'utilisateur. Dans ce cas, l'utilisateur ouvrira un navigateur avec un formulaire d'autorisation sur localhost.
Le kubeconfig résultant peut être vérifié sur le site Web . Copiez simplement la valeur users[].user.auth-provider.config.id-token depuis votre kubeconfig vers le formulaire sur le site Web et recevez immédiatement une transcription.
Configuration du RBAC
Lors de la configuration de RBAC, vous pouvez faire référence à la fois au nom d'utilisateur (champ name dans le jeton jwt), et par groupe d'utilisateurs (champ groups en jeton jwt). Voici un exemple de paramétrage des droits pour un groupe kubernetes-default-namespace-admins:
kubernetes-default-namespace-admins.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: default-admins
namespace: default
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kubernetes-default-namespace-admins
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: default-admins
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: kubernetes-default-namespace-adminsD’autres exemples de RBAC peuvent être trouvés dans
Configuration du proxy d'authentification
Il y a un merveilleux projet , qui vous permet de protéger n'importe quelle application en offrant à l'utilisateur la possibilité de s'authentifier auprès du serveur OIDC. Je vais vous montrer comment le configurer en utilisant le tableau de bord Kubernetes comme exemple :
tableau de bord-proxy.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: kubernetes-dashboard-proxy
spec:
replicas: 1
template:
metadata:
labels:
app: kubernetes-dashboard-proxy
spec:
containers:
- args:
- --listen=0.0.0.0:80
- --discovery-url=https://keycloak.example.org/auth/realms/kubernetes
- --client-id=kubernetes
- --client-secret=<your-client-secret-here>
- --redirection-url=https://kubernetes-dashboard.example.org
- --enable-refresh-tokens=true
- --encryption-key=ooTh6Chei1eefooyovai5ohwienuquoh
- --upstream-url=https://kubernetes-dashboard.kube-system
- --resources=uri=/*
image: keycloak/keycloak-gatekeeper
name: kubernetes-dashboard-proxy
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /oauth/health
port: 80
initialDelaySeconds: 3
timeoutSeconds: 2
readinessProbe:
httpGet:
path: /oauth/health
port: 80
initialDelaySeconds: 3
timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
name: kubernetes-dashboard-proxy
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: kubernetes-dashboard-proxy
type: ClusterIPSource: habr.com