Geekly articles weekly

Utilisateurs et autorisation de Kubernetes RBAC

Remarque perev. : Poursuivant le sujet récemment soulevé de la sécurité de Kubernetes en général et de RBAC en particulier, nous publions une traduction de ce matériel par un consultant français de la société internationale Adaltas Big Data. L'auteur montre en détail comment créer des utilisateurs, leur donner des droits et continuer à servir.

La configuration et le démarrage d'un cluster Kubernetes n'est qu'un début: il doit également être exploité. Pour sécuriser l'accès au cluster, vous devez définir les informations d'identification de l'utilisateur et gérer correctement les paramètres d'authentification et d'autorisation.

(Illustration tirée du blog de la CNCF - Trad . Env.)

Cet article explique comment créer des utilisateurs à l'aide de certificats clients X.509 et comment gérer l'autorisation à l'aide des API RBAC de base dans Kubernetes. Nous parlerons également de quelques projets open source qui simplifient l'administration des clusters: rakkess, kubectl-who-can, rbac-lookup et RBAC Manager.

Conditions préalables et hypothèses


Tout d'abord, il faut faire plusieurs hypothèses:


Si vous n'avez pas de cluster Kubernetes prêt à l'emploi, je vous recommande de vous référer à l'article d'un collègue (Arthur BUSSER) dans lequel il parle de l' installation de Kubernetes sur CentOS 7 à l' aide de Vagrant.

Notre cluster comprend 4 nœuds: un maître et 3 travailleurs. L'assistant sera également utilisé comme nœud périphérique pour interagir avec le cluster.

API RBAC


Le contrôle d'accès basé sur les rôles (RBAC) est une méthode de contrôle de l'accès aux ordinateurs et aux ressources réseau, basée sur les rôles des utilisateurs individuels dans une entreprise. RBAC peut être utilisé avec toutes les ressources Kubernetes qui prennent en charge CRUD (créer, lire, mettre à jour, supprimer). Exemples de telles ressources:

  • espaces de noms
  • Pods
  • Déploiements
  • volumes persistants (PersistentVolumes);
  • ConfigMaps

Et voici des exemples d'opérations possibles avec eux:

  • create ;
  • get
  • delete (supprimer) ;
  • list (vue list ) ;
  • update .

Pour gérer RBAC dans Kubernetes, nous devons déclarer:

  • Role et ClusterRole . Ce sont simplement des ensembles de règles représentant un ensemble d'autorisations. Role ne peut être utilisé que pour fournir un accès aux ressources dans les espaces de noms. ClusterRole peut fournir les mêmes autorisations que Role , et également donner accès aux ressources disponibles dans l'ensemble du cluster, et aux points de terminaison non-ressources (comme /healthz - environ Transl.) .
  • Subjects Le sujet est une entité qui effectuera des opérations dans un cluster. Il peut s'agir d'utilisateurs, de services ou même de groupes.
  • RoleBinding et ClusterRoleBinding . Comme son nom l'indique, il s'agit simplement d'une liaison du sujet à un rôle ou à un ClusterRole.

Kubernetes a les rôles par défaut suivants:

  • view : accès en lecture seule, exclut les secrets;
  • edit : ce qui précède + la possibilité de modifier la plupart des ressources, exclut les rôles et les liaisons de rôles;
  • admin : ce qui précède + la possibilité de gérer les rôles et les mappages de rôles au niveau de l'espace de noms;
  • cluster-admin : tous les privilèges possibles.

Bien sûr, vous pouvez créer vos propres Roles et Roles ClusterRoles , mais nous vous recommandons d'utiliser autant que possible les rôles par défaut, dans la mesure où la situation le permet. Sinon, vous pouvez rapidement vous perdre dans tout cela.

Exemple d'utilisation


Nous allons créer deux espaces de noms: my-project-dev et my-project-prod , - ainsi que deux utilisateurs: jean et sarah - avec des rôles différents dans ces espaces de noms:

  • mon-projet-dev:
    • jean: modifier
  • my-project-prod:
    • jean: voir
    • sarah: modifier

Créer et authentifier des utilisateurs à l'aide de certificats clients X.509


En règle générale, il existe deux types d'utilisateurs: les comptes de service gérés par Kubernetes et les utilisateurs réguliers. Nous nous concentrerons sur ce dernier. Voici comment ils sont décrits dans la documentation officielle:

On suppose que les utilisateurs réguliers sont gérés par un service externe indépendant. Le rôle peut être joué par un administrateur distribuant des clés privées, un référentiel d'utilisateurs comme Keystone ou des comptes Google, ou même un fichier avec une liste de noms d'utilisateurs et de mots de passe. À cet égard, Kubernetes n'a aucun objet représentant des utilisateurs ordinaires. Les utilisateurs ordinaires ne peuvent pas être ajoutés au cluster via un appel d'API.

Il existe plusieurs façons de gérer les utilisateurs réguliers:

  • Authentification de base:
    • transfert de la configuration au serveur API avec le contenu suivant (ou similaire): mot de passe, nom d'utilisateur, uid, groupe;
  • Certificat client X.509:
    • création d'une clé secrète d'utilisateur et d'une demande de signature de certificat;
    • certification dans une autorité de certification (Kubernetes CA) pour obtenir un certificat d'utilisateur;
  • Jetons au porteur (jetons Web JSON, JWT):
    • OpenID Connect
    • couche d'authentification au-dessus d'OAuth 2.0;
    • webhooks

Dans cet article, nous utiliserons les certificats X.509 et OpenSSL en raison de leur simplicité. La création d'utilisateurs se déroule en plusieurs étapes - nous allons les parcourir toutes. Les opérations doivent être effectuées sous le compte d'utilisateur avec les privilèges d'administrateur du cluster (cluster-admin). Voici toutes les étapes pour créer un utilisateur (en utilisant jean comme exemple):

  • Créez un utilisateur dans l'assistant, puis accédez à son répertoire personnel pour effectuer les étapes restantes:

     useradd jean && cd /home/jean
  • Créez une clé privée:

     openssl genrsa -out jean.key 2048
  • Créez une demande de signature de certificat (CSR). CN est le nom d'utilisateur, O est le groupe. Vous pouvez définir des autorisations par groupe. Cela simplifiera le travail si, par exemple, vous avez de nombreux utilisateurs avec les mêmes autorisations:

     #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3"
  • Signez la RSE dans Kubernetes CA. Nous devons utiliser le certificat et la clé CA, qui se trouvent généralement dans /etc/kubernetes/pki . Le certificat sera valable 500 jours:

     openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500
  • Créez le répertoire .certs . Nous y stockons les clés publiques et privées de l'utilisateur:

     mkdir .certs && mv jean.crt jean.key .certs
  • Créez un utilisateur dans Kubernetes:

     kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key
  • Définissez le contexte pour l'utilisateur:

     kubectl config set-context jean-context \ --cluster=kubernetes --user=jean
  • Modifiez le fichier de configuration utilisateur. Il contient les informations nécessaires à l'authentification dans un cluster. Vous pouvez utiliser le fichier de configuration du cluster, qui se trouve généralement dans /etc/kubernetes : les certificate-authority-data et server variables du server doivent être les mêmes que dans le fichier mentionné:

     apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key

    Vous devez maintenant copier la configuration ci-dessus dans le répertoire .kube :

     mkdir .kube && vi .kube/config
  • Il reste à faire de l'utilisateur le propriétaire de tous les fichiers et répertoires créés:

     chown -R jean: /home/jean/

L'utilisateur jean créé avec succès. Nous ferons de même pour sarah . Il y a pas mal d'étapes et la création d'un grand nombre d'utilisateurs peut prendre beaucoup de temps. Par conséquent, j'ai écrit des scripts Bash qui automatisent le processus: ils peuvent être trouvés dans le référentiel sur GitHub .

Remarque perev. : Comme nous l'avons écrit dans notre récent article , cette procédure peut être simplifiée de manière plus «native» pour Kubernetes - grâce à de nouvelles fonctionnalités de l'utilitaire de console kubeadm . Cependant, n'oubliez pas qu'au moment de la publication de cette traduction, ils sont disponibles sous forme alpha. Un exemple de commande pour créer un utilisateur est kubeadm alpha kubeconfig user .

Nous avons maintenant des utilisateurs et nous pouvons passer à la création de deux espaces de noms:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod

Comme nous n'avons pas encore déterminé l'autorisation des utilisateurs, ils ne devraient pas avoir accès aux ressources du cluster:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev"

Création de rôles et de clusters


Nous utiliserons ClusterRole , disponible par défaut. Cependant, nous montrons également comment créer votre propre Role et ClusterRole . En substance, Role et ClusterRole sont qu'un ensemble d'actions (appelées verbs , c'est-à-dire verbatim - verbes) autorisées pour certaines ressources et certains espaces de noms. Voici un exemple de fichier YAML:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ]

Pour les créer, exécutez la commande:

 kubectl create -f /path/to/your/yaml/file

Rôle de rôle ou rôle de cluster aux utilisateurs


Maintenant, liez le ClusterRole par défaut ( edit et view ) à nos utilisateurs comme suit:

  • jean :
    • edit - dans l'espace de noms my-project-dev ;
    • view - dans l'espace de noms my-project-prod ;
  • sarah :
    • edit - dans l'espace de noms my-project-prod .

Les liaisons de rôles doivent être spécifiées par des espaces de noms et non par des utilisateurs. En d'autres termes, pour autoriser jean nous allons créer deux RoleBindings. Un exemple de fichier YAML qui définit les RoleBindings pour jean :

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io

Nous permettons à jean de view my-project-prod et de modifier my-project-dev . La même chose doit être faite avec les autorisations pour sarah . Pour les activer, exécutez la commande:

 kubectl apply -f /path/to/your/yaml/file

Dans ce cas, kubectl apply été utilisé à la place de kubectl create . La différence entre les deux est que create crée l'objet et ne fait rien d'autre, et apply - non seulement crée l'objet (s'il n'existe pas), mais met également à jour si nécessaire.

Vérifions si nos utilisateurs ont reçu les autorisations nécessaires.

  • Utilisateur: sarah ( edit dans my-project-prod )
    • my-project-prod
      • peut lister les pods (1);
      • peut créer des déploiements (2).
    • my-project-dev
      • impossible de répertorier les pods (4);
      • impossible de créer des déploiements (5).

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev"

  • Utilisateur: jean ( view dans my-project-prod et edit dans my-project-dev )
    • my-project-prod
      • peut lister les pods (1);
      • peut lister deployment'ov (2);
      • ne peut pas supprimer les déploiements (3).
    • mon-projet-dev:
      • peut lister les dosettes (4);
      • peut créer des déploiements (5);
      • peut lister deployment'ov (6);
      • peut supprimer des déploiements (7).

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found.

Gestion et autorisation des utilisateurs


Nous avons donc défini avec succès divers rôles et autorisations utilisateur. La question se pose: comment gérer maintenant tout cela? Comment savoir si les autorisations pour un utilisateur spécifique sont définies correctement? Comment savoir qui a le pouvoir d'effectuer une action spécifique? Comment obtenir une image générale des autorisations utilisateur?

Nous avons besoin de réponses à toutes ces questions pour garantir la sécurité du cluster. La commande kubectl auth can-i vous permet de savoir si un utilisateur peut effectuer une action spécifique:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean

La première commande (1) permet à l'utilisateur de savoir s'il peut effectuer une action. Le second (2) - permet à l'administrateur d'usurper l'identité de l'utilisateur pour savoir s'il peut effectuer une certaine action. Cette "réincarnation" n'est autorisée que pour les utilisateurs disposant de privilèges d'administrateur de cluster.

C'est pratiquement tout ce qui peut être fait avec la boîte à outils intégrée. C'est pourquoi je présenterai quelques projets Open Source qui étendent les capacités offertes par l'équipe kubectl auth can-i. Avant de les introduire, établissons les dépendances: Go and Krew .

Aller à l'installation


Go est un langage de programmation open source qui vous permet de créer des logiciels simples, fiables et efficaces. Il a été développé par Google sous l'inspiration de C et Pascal, basé sur les concepts originaux de Robert Griesemer , Rob Pike et Ken Thompson .

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin

Installation de Krew


Krew est un outil qui simplifie l'utilisation des plugins kubectl . Krew vous aide à trouver, installer et gérer des plugins. En termes de fonctions, il ressemble à des outils tels que apt, dnf ou brew. Krew est uniquement compatible avec kubectl version 1.12 et supérieure.

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

rakkess


Ce projet vous permet de visualiser toutes les autorisations accordées à l'utilisateur. Par exemple, cela aide à répondre à la question de savoir ce que jean peut faire. Tout d'abord, installons-le:

 kubectl krew install access-matrix

La documentation du projet peut être trouvée dans le référentiel sur GitHub . Voici un exemple de son travail:

 kubectl access-matrix -n my-project-dev --as jean



kubect-who-can


Ce projet nous permet de savoir quels utilisateurs peuvent effectuer une action spécifique. Cela aide à répondre à la question: "Qui peut faire ça?" Installation:

 go get -v github.com/aquasecurity/kubectl-who-can

La documentation se trouve dans le référentiel GitHub . Exemple de travail:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User

rbac-lookup


Ce projet donne un aperçu des règles RBAC. Il aide à répondre aux questions: «À quel rôle appartiennent jean et sarah ?», «À quel rôle appartiennent tous les utilisateurs?», «À quel rôle appartient tout le groupe?». Pour installer, exécutez la commande:

 kubectl krew install rbac-lookup

La documentation se trouve dans le référentiel GitHub . Voici un exemple de travail:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer

RBAC Manager


Comme le nom de ce projet suit évidemment, il est le directeur de RBAC. Il simplifie les nombreuses manipulations nécessaires. Le plus important est peut-être la création de RoleBindings. Nous avons vu plus tôt que lors de la création de rôles différents pour un utilisateur, il est nécessaire de créer différents rôles RoleBindings. RBAC Manager vous aide en vous permettant de créer un seul RoleBinding avec toutes les autorisations à la fois. Pour l'installer, vous devez télécharger le fichier YAML depuis le référentiel sur GitHub:

 kubectl apply -f /path/to/rbac/manager/yaml/file

La documentation officielle se trouve dans le référentiel GitHub . Exemple de travail:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit

Conclusion


Nous avons créé des utilisateurs dans le cluster Kubernetes à l'aide du certificat client X.509 avec OpenSSL et les avons autorisés. Pour une création d'utilisateur plus facile, vous pouvez utiliser le script disponible dans mon référentiel sur GitHub (ou les commandes expérimentales kubeadm - environ Transl.) . Quant à l'administration du cluster, vous pouvez utiliser les projets Open Source présentés dans l'article:

  • kubectl auth can-i : savoir si l'utilisateur peut effectuer une action;
  • rakkess : découvrez toutes les actions que l'utilisateur peut effectuer;
  • kubectl-who-can : détermine quels utilisateurs peuvent effectuer une action;
  • rbac-lookup : obtenir un aperçu général de RBAC;
  • Gestionnaire RBAC : simplifiez la configuration en combinant les liaisons de droits, en automatisant les modifications apportées à RBAC, en utilisant des étiquettes comme sélecteurs pour attribuer les droits.

La création d'utilisateurs peut devenir une tâche très chronophage, surtout si vous devez définir un grand nombre d'utilisateurs à la fois (ou les créer souvent). Pour atténuer la situation, vous pouvez connecter LDAP d'entreprise au cluster Kubernetes. Certains projets Open Source ( Kismatic [ Object ressemble à abandonné - environ Transl.] Et ObjectifLibre ) offrent des webhooks Kubernetes qui permettent une authentification directe via LDAP. Une autre solution possible consiste à configurer un serveur OpenID avec LDAP d'entreprise comme backend.

PS du traducteur


Lisez aussi dans notre blog:

Source: https://habr.com/ru/post/fr470503/

More articles:


All Articles