🥇Nous attachons l'autorisation ActiveDirectory à Kubernetes en utilisant Keycloak

Cet article a été écrit pour développer le déjà existant, mais parle des fonctionnalités du bundle avec Microsoft ActiveDirectory, et le complète également.

Dans cet article je vais vous expliquer comment installer et configurer :

Cape de clé est un projet open source. Ce qui fournit un point d'entrée unique pour les applications. Fonctionne avec de nombreux protocoles, dont LDAP et OpenID qui nous intéressent.
gardien de clé - application de proxy inverse qui vous permet d'intégrer l'autorisation via Keycloak.
Allée - une application qui génère une configuration pour kubectl avec laquelle vous pouvez vous connecter et vous connecter à l'API Kubernetes via OpenID.

Fonctionnement des autorisations dans Kubernetes.

On peut gérer les droits des utilisateurs/groupes grâce au RBAC, un tas d'articles ont déjà été créés à ce sujet, je ne vais pas m'étendre là-dessus en détail. Le problème est que vous pouvez utiliser RBAC pour restreindre les droits des utilisateurs, mais Kubernetes ne sait rien des utilisateurs. Il s'avère que nous avons besoin d'un mécanisme de livraison utilisateur dans Kubernetes. Pour ce faire, nous ajouterons un fournisseur à Kuberntes OpenID, qui dira qu'un tel utilisateur existe réellement, et Kubernetes lui-même lui en donnera les droits.

Formation

Vous aurez besoin d'un cluster Kubernetes ou d'un minikube
active Directory
Domaines:
keycloak.example.org
kubernetes-dashboard.example.org
passerelle.exemple.org
Certificat pour les domaines ou certificat auto-signé

Je ne m'attarderai pas sur la façon de créer un certificat auto-signé, vous devez créer 2 certificats, il s'agit de la racine (autorité de certification) et du client générique pour le domaine *.example.org

Après avoir reçu/émis des certificats, le client doit être ajouté à Kubernetes, pour cela nous créons un secret pour lui :

kubectl create secret tls tls-keycloak --cert=example.org.crt --key=example.org.pem

Ensuite, nous l'utiliserons pour notre contrôleur Ingress.

Installation de Keycloak

J'ai décidé que le moyen le plus simple était d'utiliser des solutions toutes faites pour cela, à savoir des cartes de barre.

Installez le référentiel et mettez-le à jour :

helm repo add codecentric https://codecentric.github.io/helm-charts
helm repo update

Créez un fichier keycloak.yml avec le contenu suivant :

keycloak.yml

keycloak:
  # Имя администратора
  username: "test_admin"
  # Пароль администратор  
  password: "admin"
  # Эти флаги нужны что бы позволить загружать в Keycloak скрипты прямо через web морду. Это нам 
  понадобиться что бы починить один баг, о котором ниже.
  extraArgs: "-Dkeycloak.profile.feature.script=enabled -Dkeycloak.profile.feature.upload_scripts=enabled" 
  # Включаем ingress, указываем имя хоста и сертификат который мы предварительно сохранили в secrets
  ingress:
    enabled: true 
    path: /
    annotations:
      kubernetes.io/ingress.class: nginx
      ingress.kubernetes.io/affinity: cookie
    hosts:
      - keycloak.example.org
    tls:
    - hosts:
        - keycloak.example.org
      secretName: tls-keycloak
  # Keycloak для своей работы требует базу данных, в тестовых целях я разворачиваю Postgresql прямо в Kuberntes, в продакшене так лучше не делать!
  persistence:
    deployPostgres: true
    dbVendor: postgres

postgresql:
  postgresUser: keycloak
  postgresPassword: ""
  postgresDatabase: keycloak
  persistence:
    enabled: true

Configuration de la fédération

Ensuite, accédez à l'interface Web keycloak.example.org

Cliquez dans le coin gauche Ajouter un domaine

clés / KEY :
Valeur

Nom
kubernetes

Nom du profil
Kubernetes

Désactiver la vérification des e-mails des utilisateurs :
Étendues client —> E-mail —> Mappeurs —> E-mail vérifié (Supprimer)

Nous avons mis en place une fédération pour importer des utilisateurs depuis ActiveDirectory, je vais laisser des captures d'écran ci-dessous, je pense que ce sera plus clair.

Fédération d'utilisateurs —> Ajouter un fournisseur… —> ldap

Configuration de la fédération

Si tout va bien, après avoir appuyé sur le bouton Synchroniser tous les utilisateurs vous verrez un message sur l'importation réussie des utilisateurs.

Ensuite, nous devons cartographier nos groupes

Fédération d'utilisateurs --> ldap_localhost --> Mappeurs --> Créer

Création d'un mappeur

Configuration client

Il est nécessaire de créer un client, en termes de Keycloak, c'est une application qui sera autorisée de sa part. Je soulignerai les points importants dans la capture d'écran en rouge.

Client —> Créer

Configuration client

Créons scoupe pour les groupes :

Étendues client —> Créer

Créer une portée

Et configurez un mappeur pour eux :

Client Scopes -> groupes -> Mappers -> Créer

Mappeur

Ajoutez le mappage de nos groupes aux étendues client par défaut :

Clients -> kubernetes -> Étendues client -> Étendues client par défaut
sélectionner groupes в Étendues client disponiblespousser Ajouter sélectionnée

Nous obtenons le secret (et l'écrivons dans le fil) que nous utiliserons pour l'autorisation dans Keycloak :

Clients -> kubernetes -> Identifiants -> Secret
Ceci termine la configuration, mais j'ai eu une erreur lorsque, après une autorisation réussie, j'ai reçu une erreur 403. Rapport d'erreur.

Réparer:

Client Scopes -> rôles -> Mappers -> Créer

Cartographe

Code de script

// add current client-id to token audience
token.addAudience(token.getIssuedFor());

// return token issuer as dummy result assigned to iss again
token.getIssuer();

Configuration de Kubernetes

Nous devons spécifier où se trouve notre certificat racine du site et où se trouve le fournisseur OIDC.
Pour cela, éditez le fichier /etc/kubernetes/manifests/kube-apiserver.yaml

kube-apiserver.yaml


...
spec:
  containers:
  - command:
    - kube-apiserver
...
    - --oidc-ca-file=/var/lib/minikube/certs/My_Root.crt
    - --oidc-client-id=kubernetes
    - --oidc-groups-claim=groups
    - --oidc-issuer-url=https://keycloak.example.org/auth/realms/kubernetes
    - --oidc-username-claim=email
...

Mettez à jour la configuration de kubeadm dans le cluster :

kubeadmconfig

kubectl edit -n kube-system configmaps kubeadm-config


...
data:
  ClusterConfiguration: |
    apiServer:
      extraArgs:
        oidc-ca-file: /var/lib/minikube/certs/My_Root.crt
        oidc-client-id: kubernetes
        oidc-groups-claim: groups
        oidc-issuer-url: https://keycloak.example.org/auth/realms/kubernetes
        oidc-username-claim: email
...

Configuration du proxy d'authentification

Vous pouvez utiliser le gatekeeper keycloak pour protéger votre application Web. Outre le fait que ce proxy inverse autorisera l'utilisateur avant d'afficher la page, il transmettra également des informations vous concernant à l'application finale dans les en-têtes. Ainsi, si votre application supporte OpenID, alors l'utilisateur est immédiatement autorisé. Prenons l'exemple du tableau de bord Kubernetes

Installation du tableau de bord Kubernetes


helm install stable/kubernetes-dashboard --name dashboard -f values_dashboard.yaml

valeurs_dashboard.yaml

enableInsecureLogin: true
service:
  externalPort: 80
rbac:
  clusterAdminRole: true
  create: true
serviceAccount:
  create: true
  name: 'dashboard-test'

Paramétrage des droits d'accès :

Créons un ClusterRoleBinding qui donnera des droits d'administrateur de cluster (cluster-admin ClusterRole standard) aux utilisateurs du groupe DataOPS.


kubectl apply -f rbac.yaml

rbac.yaml


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dataops_group
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: DataOPS

Installez le gardien keycloak :


helm repo add gabibbo97 https://gabibbo97.github.io/charts/
helm repo update
helm install gabibbo97/keycloak-gatekeeper --version 2.1.0 --name keycloak-gatekeeper -f values_proxy.yaml

valeurs_proxy.yaml



# Включаем ingress
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
  path: /
  hosts:
    - kubernetes-dashboard.example.org
  tls:
   - secretName: tls-keycloak
     hosts:
       - kubernetes-dashboard.example.org

# Говорим где мы будем авторизовываться у OIDC провайдера
discoveryURL: "https://keycloak.example.org/auth/realms/kubernetes"
# Имя клиента которого мы создали в Keycloak
ClientID: "kubernetes"
# Secret который я просил записать
ClientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
# Куда перенаправить в случае успешной авторизации. Формат <SCHEMA>://<SERVICE_NAME>.><NAMESAPCE>.<CLUSTER_NAME>
upstreamURL: "http://dashboard-kubernetes-dashboard.default.svc.cluster.local"
# Пропускаем проверку сертификата, если у нас самоподписанный
skipOpenidProviderTlsVerify: true
# Настройка прав доступа, пускаем на все path если мы в группе DataOPS
rules:
  - "uri=/*|groups=DataOPS"

Après cela, lorsque vous essayez d'aller à kubernetes-dashboard.example.org, nous serons redirigés vers Keycloak et en cas d'autorisation réussie, nous accéderons au tableau de bord déjà connecté.

pose de passerelle

Pour plus de commodité, vous pouvez ajouter une passerelle qui générera un fichier de configuration pour kubectl, à l'aide duquel nous entrerons dans Kubernetes sous notre utilisateur.


helm install --name gangway stable/gangway -f values_gangway.yaml

valeurs_gangway.yaml


gangway:
  # Произвольное имя кластера
  clusterName: "my-k8s"
  # Где у нас OIDC провайдер
  authorizeURL: "https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/auth"
  tokenURL: "https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/token"
  audience: "https://keycloak.example.org/auth/realms/kubernetes/protocol/openid-connect/userinfo"
  # Теоритически сюда можно добавить groups которые мы замапили
  scopes: ["openid", "profile", "email", "offline_access"]
  redirectURL: "https://gangway.example.org/callback"
  # Имя клиента
  clientID: "kubernetes"
  # Секрет
  clientSecret: "c6ec03b8-d0b8-4cb6-97a0-03becba1d727"
  # Если оставить дефолтное значние, то за имя пользователя будет братья <b>Frist name</b> <b>Second name</b>, а при "sub" его логин
  usernameClaim: "sub"
  # Доменное имя или IP адресс API сервера
  apiServerURL: "https://192.168.99.111:8443"

# Включаем Ingress
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy-buffer-size: "64k"
  path: /
  hosts:
  - gangway.example.org
  tls:
  - secretName: tls-keycloak
    hosts:
      - gangway.example.org

# Если используем самоподписанный сертификат, то его(открытый корневой сертификат) надо указать.
trustedCACert: |-
 -----BEGIN CERTIFICATE-----
 MIIDVzCCAj+gAwIBAgIBATANBgkqhkiG9w0BAQsFADA1MQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRGF0YU9QUzEUMBIGA1UEAxMLbXkgcm9vdCBrZXkwHhcNMjAwMjE0MDkxODAwWhcNMzAwMjE0MDkxODAwWjA1MQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRGF0YU9QUzEUMBIGA1UEAxMLbXkgcm9vdCBrZXkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDyP749PqqIRwNSqaK6qr0Zsi03G4PTCUlgaYTPZuMrwUVPK8xX2dWWs9MPRMOdXpgr8aSTZnVfmelIlVz4D7o2vK5rfmAe9GPcK0WbwKwXyhFU0flS9sU/g46ogHFrk03SZxQAeJhMLfEmAJm8LF5HghtGDs3t4uwGsB95o+lqPLiBvxRB8ZS3jSpYpvPgXAuZWKdZUQ3UUZf0X3hGLp7uIcIwJ7i4MduOGaQEO4cePeEJy9aDAO6qV78YmHbyh9kaW+1DL/Sgq8NmTgHGV6UOnAPKHTnMKXl6KkyUz8uLBGIdVhPxrlzG1EzXresJbJenSZ+FZqm3oLqZbw54Yp5hAgMBAAGjcjBwMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFHISTOU/6BQqqnOZj+1xJfxpjiG0MAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAAcwHgYJYIZIAYb4QgENBBEWD3hjYSBjZXJ0aWZpY2F0ZTANBgkqhkiG9w0BAQsFAAOCAQEAj7HC8ObibwOLT4ZYmISJZwub9lcE0AZ5cWkPW39j/syhdbbqjK/6jy2D3WUEbR+s1Vson5Ov7JhN5In2yfZ/ByDvBnoj7CP8Q/ZMjTJgwN7j0rgmEb3CTZvnDPAz8Ijw3FP0cjxfoZ1Z0V2F44Ry7gtLJWr06+MztXVyto3aIz1/XbMQnXYlzc3c3B5yUQIy44Ce5aLRVsAjmXNqVRmDJ2QPNLicvrhnUJsO0zFWI+zZ2hc4Ge1RotCrjfOc9hQY63jZJ17myCZ6QCD7yzMzAob4vrgmkD4q7tpGrhPY/gDcE+lUNhC7DO3l0oPy2wsnT2TEn87eyWmDiTFG9zWDew==
 -----END CERTIFICATE-----

Ressemble à ça. Vous permet de télécharger immédiatement le fichier de configuration et de le générer à l'aide d'un ensemble de commandes :

Source: habr.com

Nous attachons l'autorisation ActiveDirectory à Kubernetes en utilisant Keycloak