Un court tutoriel sur la façon d'utiliser Kubernetes pour connecter Kubernetes à votre serveur LDAP et configurer l'importation d'utilisateurs et de groupes à l'aide de Keycloak. Cela vous permettra de configurer RBAC pour vos utilisateurs et d'utiliser auth-proxy pour protéger Kubernetes Dashboard et d'autres applications qui ne peuvent pas s'autoriser.
Installer Keycloak
Supposons que vous disposiez déjà d'un serveur LDAP. Il peut s'agir d'Active Directory, FreeIPA, OpenLDAP ou toute autre chose. Si vous n'avez pas de serveur LDAP, vous pouvez en principe créer des utilisateurs directement dans l'interface Keycloak ou utiliser des fournisseurs publics Oidc (Google, Github, Gitlab), le résultat sera presque le même.
Tout d'abord, nous installerons Keycloak lui-même, l'installation peut être effectuée séparément, et immédiatement dans le cluster Kubernetes, en règle générale, si vous avez plusieurs clusters Kubernetes, il serait plus facile de l'installer séparément. D'autre part, vous pouvez toujours utiliser le tableau de barre officiel et l'installer directement dans votre cluster.
Pour stocker les données Keycloak, vous avez besoin d'une base de données. Par défaut, h2 utilisé (toutes les données sont stockées localement), mais il est également possible d'utiliser postgres , mysql ou mariadb .
Si vous décidez toujours d'installer Keycloak séparément, vous trouverez des instructions plus détaillées dans la documentation officielle .
Configuration de la fédération
Créez d'abord un nouveau domaine. Le domaine est l'espace de notre application. Chaque application peut avoir son propre domaine avec différents utilisateurs et paramètres d'autorisation. Le domaine maître est utilisé par Keycloak lui-même et il n'est pas juste de l'utiliser pour autre chose.
Cliquez sur Ajouter un domaine
| Option | Valeur |
|---|
| Nom | kubernetes |
| Nom d'affichage | Kubernetes |
| Nom d'affichage HTML | <img src="https://kubernetes.io/images/nav_logo.svg" width="400" \> |
Kubernetes vérifie par défaut si l'utilisateur a un e-mail ou non. Puisque nous utilisons notre propre serveur LDAP, cette vérification retournera presque toujours false . Désactivons la représentation de ce paramètre dans Kubernetes:
Étendues client -> E - mail -> Mappeurs -> E-mail vérifié (Supprimer)
Configurez maintenant la fédération, pour cela nous allons aller à:
Fédération d'utilisateurs -> Ajouter un fournisseur ... -> ldap
Voici un exemple de configuration pour FreeIPA:
| Option | Valeur |
|---|
| Nom d'affichage de la console | freeipa.example.org |
| Vendeur | Red Hat Directory Server |
| Attribut LDAP UUID | ipauniqueid |
| URL de connexion | ldaps://freeipa.example.org |
| DN d'utilisateurs | cn=users,cn=accounts,dc=example,dc=org |
| Lier dn | uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org |
| Lier les informations d'identification | <password> |
| Autoriser l'authentification Kerberos: | on |
| Domaine Kerberos: | EXAMPLE.ORG |
| Principal du serveur: | HTTP/freeipa.example.org@EXAMPLE.ORG |
| KeyTab: | /etc/krb5.keytab |
L'utilisateur keycloak-svc doit être créé à l'avance sur notre serveur LDAP.
Dans le cas d'Active Directory, sélectionnez simplement Fournisseur: Active Directory et les paramètres nécessaires sont automatiquement renseignés dans le formulaire.
Cliquez sur Enregistrer
Passons maintenant:
Fédération d'utilisateurs -> freeipa.example.org -> Mappeurs -> Prénom
| Option | Valeur |
|---|
| Attribution LDAP | givenName |
Activez maintenant le mappage de groupe:
Fédération d'utilisateurs -> freeipa.example.org -> Mappeurs -> Créer
| Option | Valeur |
|---|
| Nom | groups |
| Type de mappeur | group-ldap-mapper |
| DN des groupes LDAP | cn=groups,cn=accounts,dc=example,dc=org |
| Groupes d'utilisateurs récupérer la stratégie | GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE |
Ceci termine la configuration de la fédération, passons à la configuration du client.
Configuration du client
Créez un nouveau client (une application qui recevra les utilisateurs de Keycloak). Nous passons:
Clients -> Créer
| Option | Valeur |
|---|
| ID client | kubernetes |
| Type d'accès | confidenrial |
| URL racine | http://kubernetes.example.org/ |
| URI de redirection valides | http://kubernetes.example.org/* |
| URL administrateur | http://kubernetes.example.org/ |
Créez également une portée pour les groupes:
Étendues client -> Créer
| Option | Valeur |
|---|
| Gabarit | No template |
| Nom | groups |
| Chemin de groupe complet | false |
Et configurez le mappeur pour eux:
Étendues client -> groupes -> Mappeurs -> Créer
| Option | Valeur |
|---|
| Nom | groups |
| Type de mappeur | Group membership |
| Nom de revendication de jeton | groups |
Maintenant, nous devons activer le groupe de mappage dans notre portée client:
Clients -> kubernetes -> Étendues client -> Étendues client par défaut
Sélectionnez les groupes dans les étendues client disponibles , cliquez sur Ajouter la sélection
Configurez maintenant l'authentification de notre application, allez sur:
Clients -> kubernetes
| Option | Valeur |
|---|
| Autorisation activée | ON |
Cliquez sur enregistrer et cela termine la configuration du client, maintenant sur l'onglet
Clients -> kubernetes -> Identifiants
Vous pouvez obtenir Secret que nous utiliserons à l'avenir.
Configurer Kubernetes
La configuration de Kubernetes pour l'authentification OIDC est assez triviale et n'est 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 d'ajouter les options nécessaires pour kube-apiserver.
Pour ce faire, mettez à jour /etc/kubernetes/manifests/kube-apiserver.yaml sur tous vos assistants:
... 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 ...
Et mettez également à jour la configuration 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 dans tous vos clusters Kubernetes.
Autorisation initiale
Après ces étapes, vous disposerez déjà d'un cluster Kubernetes avec l'authentification OIDC configurée. Le seul point est que vos utilisateurs n'ont pas encore configuré de client ainsi que leur propre kubeconfig. Pour résoudre ce problème, vous devez configurer l'émission 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 terminé. L'un des plus pratiques est Kuberos , qui 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 de kubeconfig et exécutez-le avec les paramètres suivants:
kuberos https://keycloak.example.org/auth/realms/kubernetes kubernetes /cfg/secret /cfg/template
Voir Utilisation sur Github pour plus de détails.
Il est également possible d'utiliser kubelogin si vous souhaitez autoriser directement sur l'ordinateur de l'utilisateur. Dans ce cas, l'utilisateur ouvre un navigateur avec un formulaire d'autorisation sur localhost.
Le kubeconfig résultant peut être vérifié sur jwt.io. Copiez simplement la valeur des users[].user.auth-provider.config.id-token de votre kubeconfig vers le formulaire sur le site et obtenez immédiatement le décryptage.
Configuration RBAC
Lors de la configuration de RBAC, vous pouvez faire référence à la fois au nom d'utilisateur (le champ de name dans le jeton jwt) et au groupe d'utilisateurs (le champ de groups dans le jeton jwt). Voici un exemple de définition des autorisations pour le 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-admins
Vous trouverez d'autres exemples de RBAC dans la documentation officielle de Kubernetes.
Configurer l'auth-proxy
Il existe un merveilleux projet keycloak-gatekeeper qui vous permet de protéger n'importe quelle application, donnant à l'utilisateur la possibilité de s'authentifier auprès du serveur OIDC. Je vais montrer comment vous pouvez le configurer en utilisant Kubernetes Dashboard comme exemple:
dashboard-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: ClusterIP