🥇Intégration de l'autorisation LDAP à Kubernetes

Un petit guide sur la façon d'utiliser Keycloak pour relier Kubernetes à votre serveur LDAP et configurer l'importation d'utilisateurs et de groupes. Cela permettra de configurer le RBAC pour vos utilisateurs et d'utiliser un auth-proxy pour sécuriser le tableau de bord Kubernetes et d'autres applications qui ne peuvent pas s'authentifier elles-mêmes.

Installation de Keycloak

Supposons que vous avez déjà un serveur LDAP. Cela peut être Active Directory, FreeIPA, OpenLDAP ou autre chose. Si vous n'avez pas de serveur LDAP, vous pouvez en principe créer des utilisateurs directement dans l'interface de Keycloak, ou utiliser des fournisseurs oidc publics (Google, Github, Gitlab), le résultat sera presque le même.

D'abord, installez Keycloak lui-même, l'installation peut se faire séparément ou directement dans le cluster Kubernetes, en général, si vous avez plusieurs clusters Kubernetes, il serait plus facile de l'installer séparément. D'autre part, vous pouvez toujours utiliser le chart helm officiel et l'installer directement dans votre cluster.

Pour stocker les données de Keycloak, vous aurez besoin d'une base de données. Par défaut, on utilise h2 (toutes les données sont stockées localement), mais vous pouvez également utiliser postgres, mysql ou mariadb.
Si vous avez décidé d'installer Keycloak séparément, des instructions plus détaillées se trouvent dans la documentation officielle.

Configuration de la fédération

Tout d'abord, créons un nouveau royaume. Un royaume est l'espace de notre application. Chaque application peut avoir son propre royaume avec différents utilisateurs et paramètres d'autorisation. Le royaume maître est utilisé par Keycloak lui-même et il est incorrect de l'utiliser pour autre chose.

Cliquez Ajouter un royaume

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'email de l'utilisateur est confirmé ou non. Comme nous utilisons notre propre serveur LDAP, cette vérification renverra presque toujours faux. Désactivons l'affichage de ce paramètre dans Kubernetes :

Client scopes —> Email —> Mappers —> Email vérifié (Supprimer)

Nous allons maintenant configurer la fédération, pour cela allons dans :

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

Fournisseur
Red Hat Directory Server

Attribut LDAP UUID
ipauniqueid

URL de connexion
ldaps://freeipa.example.org

DN des utilisateurs
cn=users,cn=accounts,dc=example,dc=org

DN de liaison
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org

Informations d'identification de liaison
<password>

Autoriser l'authentification Kerberos :
on

Royaume 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, il suffit de choisir Fournisseur : Active Directory Et les paramètres nécessaires seront automatiquement remplis dans le formulaire.

Cliquez Sauvegarder

Passons maintenant à :

Fédération d'utilisateurs —> freeipa.example.org —> Mappers —> Prénom

Option
Valeur

Attribut LDAP
givenName

Nous allons maintenant activer le mappage des groupes :

Fédération d'utilisateurs —> freeipa.example.org —> Mappers —> 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

La configuration de la fédération est maintenant terminée, passons à la configuration du client.

Configuration du client

Créons un nouveau client (une application qui récupérera les utilisateurs de Keycloak). Passons à :

Clients —> Créer

Option
Valeur

ID Client
kubernetes

Type d'accès
confidenrial

URL racine
http://kubernetes.example.org/

URIs de redirection valides
http://kubernetes.example.org/*

URL d'administration
http://kubernetes.example.org/

Nous allons également créer un scope pour les groupes :

Scopes de client —> Créer

Option
Valeur

Modèle
Aucun modèle

Nom
groups

Chemin complet du groupe
faux

Et nous configurerons un mappeur pour eux :

Scopes de client —> groups —> Mappers —> Créer

Option
Valeur

Nom
groups

Type de mappeur
Adhésion au groupe

Nom de la réclamation de jeton
groups

Nous devons maintenant activer le mappage des groupes dans notre scope de client :

Clients —> kubernetes —> Scopes de client —> Scopes de client par défaut

Sélectionnez groups dans Scopes de client disponibles, cliquez sur Ajouter les sélectionnés

Nous allons maintenant configurer l'authentification de notre application, passons à :

Clients —> kubernetes

Option
Valeur

Autorisation activée
ACTIVER

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

Clients —> kubernetes —> Identifiants

vous pourrez obtenir Secret que nous utiliserons plus tard.

Configuration de Kubernetes

La configuration de Kubernetes pour l'autorisation OIDC est assez triviale et n'est pas très complexe. Tout ce que vous devez faire est de placer 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 cela, mettez à jour /etc/kubernetes/manifests/kube-apiserver.yaml sur tous vos maîtres :

...
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 pour 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
...

La configuration de Kubernetes est maintenant terminée. Vous pouvez répéter ces actions dans tous vos clusters Kubernetes.

Autorisation initiale

Après ces actions, vous aurez déjà un cluster Kubernetes avec une autorisation OIDC configurée. Le seul point est que vos utilisateurs n'ont pas encore de client configuré ni de kubeconfig propre. Pour résoudre ce problème, vous devez configurer l'émission automatique de kubeconfig aux utilisateurs après une autorisation réussie.

Pour cela, vous pouvez utiliser des applications web spéciales qui permettent d'authentifier l'utilisateur puis de télécharger le kubeconfig prêt. L'une des plus pratiques est Kuberos, il permet de décrire tous les clusters Kubernetes dans une seule configuration et de basculer facilement entre eux.

Pour configurer Kuberos, il suffit de décrire le template pour kubeconfig et de l'exécuter avec les paramètres suivants :

kuberos https://keycloak.example.org/auth/realms/kubernetes kubernetes /cfg/secret /cfg/template

Pour plus d'informations détaillées, consultez Utilisation sur Github.

Il est également possible d'utiliser kubelogin si vous souhaitez effectuer l'authentification directement sur l'ordinateur de l'utilisateur. Dans ce cas, un navigateur s'ouvrira avec un formulaire d'authentification sur localhost.

Le kubeconfig obtenu peut être vérifié sur le site jwt.io. Il suffit de copier la valeur users[].user.auth-provider.config.id-token de votre kubeconfig dans le formulaire sur le site pour obtenir instantanément le décryptage.

Configuration RBAC

Lors de la configuration de RBAC, vous pouvez vous référer soit au nom d'utilisateur (champ nom dans le jeton jwt), soit au groupe d'utilisateurs (champ groups dans le jeton jwt). Voici un exemple de configuration des droits 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

D'autres exemples pour RBAC peuvent être trouvés dans la documentation officielle de Kubernetes

Configuration de auth-proxy

Il existe un projet formidable keycloak-gatekeeper, qui permet de sécuriser n'importe quelle application en permettant à l'utilisateur de s'authentifier sur un serveur OIDC. Je vais montrer comment le configurer à l'aide de l'exemple Kubernetes Dashboard :

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=
        - --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 intégrons l'authentification LDAP à Kubernetes.

Installation de Keycloak

Configuration de la fédération

Configuration du client

Configuration de Kubernetes

Autorisation initiale

Configuration RBAC

Configuration de auth-proxy