🥇Ajout de l'autorisation LDAP à Kubernetes

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 tableau de barre officiel 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 documents officiels.

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/freeipa.example.org@EXAMPLE.ORG

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 Enregistrer

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éer

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:

ANNONCEURS -> Créer

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éer

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éer

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 :

ANNONCEURS -> 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 :

ANNONCEURS -> kubernetes

Option
Valeur

Autorisation activée
ON

Pressons enregistrer et avec cela la configuration du client est terminée, maintenant sur l'onglet

ANNONCEURS -> kubernetes -> Titres de compétences

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 Kuberos, 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/template

Pour des informations plus détaillées, voir Utilisation sur Github.

Il est également possible d'utiliser connexion kubel 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 jwt.io. 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-admins

D’autres exemples de RBAC peuvent être trouvés dans documentation officielle de Kubernetes

Configuration du proxy d'authentification

Il y a un merveilleux projet keycloak-gatekeeper, 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: ClusterIP

Source: habr.com

Nous attachons l'autorisation LDAP à Kubernetes

Installation de Keycloak

Configuration de la fédération

Configuration client

Configuration de Kubernetes

Autorisation initiale

Configuration du RBAC

Configuration du proxy d'authentification