Utilisateurs et autorisations RBAC dans Kubernetes

Le déploiement d’un cluster Kubernetes n’est que le début de votre parcours et vous devez maintenant l’exploiter. Pour sécuriser son accès, les identités des utilisateurs doivent être déclarées avec des authentifications et des autorisations correctement paramétrés.

Cet article traite de la création d’utilisateurs avec des certificats de client X.509 et de la gestion des autorisations à l’aide des objets de l’API RBAC (Kubernetes Role-Based Access Control) natifs à Kubernetes. Nous présenterons également plusieurs projets Open Source qui simplifient l’administration de clusters : rakkess, kubectl-who-can, rbac-lookup, et RBAC Manager.

Prérequis et hypothèses

Nous partirons des hypothèses suivantes :

• Vous avez une compréhension de base du fonctionnement de Kubernetes.
• Vous avez un cluster Kubernetes ou un Minikube en cours d’exécution
• Vous avez la ligne de commande Kubectl installée et fonctionnelle
• OpenSSL est installé sur votre système Linux

Si vous ne disposez pas d’un cluster Kubernetes, vous pouvez suivre l’article d’Arthur intitulé Installation de Kubernetes sur CentOS 7, qui utilise Vagrant.

Nous avons un cluster Kubernetes de 4 nœuds, un master et trois slaves. Le master sera également utilisé comme notre edge node pour interagir avec le cluster.

Objects de l’API RBAC

Le contrôle d’accès basé sur les rôles (RBAC) est une méthode de régulation de l’accès aux ordinateurs et aux ressources réseau basée sur les rôles des utilisateurs individuels au sein d’une entreprise. Nous pouvons utiliser le contrôle d’accès basé sur les rôles sur toutes les ressources Kubernetes supportant les accès CRUD (Create, Read, Update, Delete). Exemples de ressources :

• Namespaces
• Pods
• Deployments
• PersistentVolumes
• ConfigMaps

Voici des exemples d’opérations possibles sur ces ressources :

• create
• get
• delete
• list
• update

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

• Role et ClusterRole
  Ce sont un ensemble de règles représentant un ensemble d’autorisations. Un Role ne peut être utilisé que pour accorder l’accès à des ressources dans des namespaces. Un ClusterRole peut être utilisé pour octroyer les mêmes autorisations qu’un rôle, mais également pour octroyer un accès à des ressources à l’échelle du cluster, des endpoints autres que des ressources.
• Subjects
  Un sujet est l’entité qui effectuera les opérations dans le cluster. Ils peuvent être des comptes d’utilisateurs, des comptes de services ou même un groupe.
• RoleBinding et ClusterRoleBinding
  Comme son nom l’indique, il ne s’agit que de la liaison entre un sujet et un Role ou un ClusterRole.

Les rôles par défaut définis dans Kubernetes sont :

• view : accès en lecture seule, exclut les secrets
• edit : ci-dessus + possibilité de modifier la plupart des ressources, exclut les rôles et les role bindings
• admin : ci-dessus + possibilité de gérer des rôles et des role bindings au niveau d’un espace de noms
• cluster-admin : tout

Nous pouvons, bien sûr, créer des rôles spécifiques et des rôles de cluster, mais nous vous recommandons d’utiliser la valeur par défaut aussi longtemps que vous le pouvez. Cela peut rapidement devenir difficile à gérer.

Cas d’utilisation

Nous allons créer deux namespaces “my-project-dev” et “my-project-prod” et deux utilisateurs “jean” et “sarah” avec différents rôles dans chacun des namespaces :

• my-project-dev :
  • jean : Edit
• my-project-prod :
  • jean : View
  • sarah : Edit

Création d’utilisateurs et authentification avec les certificats clients X.509

Il existe deux types d’utilisateurs : les comptes de service gérés par Kubernetes et les utilisateurs normaux. Nous allons nous concentrer sur les utilisateurs normaux. Voici comment la documentation officielle décrit un utilisateur normal :

Les utilisateurs normaux sont supposés être gérés par un service externe indépendant. Un administrateur distribuant des clés privées, un magasin d’utilisateurs comme Keystone ou des comptes Google, voire un fichier contenant une liste de noms d’utilisateur et de mots de passe. À cet égard, Kubernetes n’a pas d’objets qui représentent des comptes d’utilisateur normaux. Les utilisateurs normaux ne peuvent pas être ajoutés à un cluster via un appel d’API.

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

• Basic Authentication
  • Transmettez une configuration avec le contenu suivant au serveur API
    • password,username,uid,group
• Certificats clients X.509
  • Créer la clé privée d’un utilisateur et une demande de signature de certificat (CSR)
  • Certifier la demande de signature de certificat par un CA (Kubernetes CA) pour avoir le certificat de l’utilisateur
• Bearer Tokens (JSON Web Tokens)
  • OpenID Connect
    • Par dessus OAuth 2.0
  • Webhooks

Pour les besoins de cet article, nous utiliserons les certificats clients X.509 avec OpenSSL pour leur simplicité. Il existe différentes étapes pour la création d’utilisateurs. Nous irons étape par étape. Vous devez effectuer les actions en tant qu’utilisateur identifié avec les permissions de “cluster-admin”. Voici les étapes à suivre pour créer un utilisateur (ici pour “jean”) :

• Création d’un utilisateur sur la machine principale puis se rendre dans sa home pour effectuer les étapes restantes.

  useradd jean && cd /home/jean

• Création de sa private key :

  openssl genrsa -out jean.key 2048

• Création d’une demande de signature de certificat (CSR). CN est le nom de l’utilisateur et O est le groupe. Il est possible de définir des autorisations à l’échelle d’un groupe, ce qui peut simplifier la gestion si plusieurs utilisateurs partagent les mêmes autorisations.

  # Without Group
  openssl req -new \
    -key jean.key \
    -out jean.csr \
    -subj "/CN=jean"
  
  # With a Group where $group is the group name
  openssl req -new \
    -key jean.key \
    -out jean.csr \
    -subj "/CN=jean/O=$group"
  
  #If the user has multiple groups
  openssl req -new \
    -key jean.key \
    -out jean.csr \
    -subj "/CN=jean/O=$group1/O=$group2/O=$group3"

• Signer le CSR avec le CA de Kubernetes. Le certificat et la clé de Kubernetes sont locallisés dans /etc/kubernetes/pki. Les certificats générés ci-dessous seront valides pour 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éation d’un répertoire “.certs” où sera stocké les clé public et privées de l’utilisateur.

  mkdir .certs && mv jean.crt jean.key .certs

• Création de l’utilisateur dans Kubernetes.

  kubectl config set-credentials jean \
    --client-certificate=/home/jean/.certs/jean.crt \
    --client-key=/home/jean/.certs/jean.key

• Création d’un contexte associé à l’utilisateur.

  kubectl config set-context jean-context \
    --cluster=kubernetes --user=jean

• Edition du fichier de configuration utilisateur. Ce fichier de configuration contient toutes les informations nécessaire pour authentifier l’utilisateur auprès du cluster. Vous pouvez utiliser la configuration de l’administrateur du cluster comme template. Il se trouve normalement dans /etc/kubernetes/. Les variables “certificate-authority-data” et “server” doivent être identiques à celle de l’administrateur.

  apiVersion: v1
  clusters:
  - cluster:
     certificate-authority-data: {Parse content here}
     server: {Parse content here}
    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

  Ensuite, nous devons copier la configuration ci-dessus dans le répertoire .kube.

  mkdir .kube && vi .kube/config

• Appliquer les permission sur tous les fichiers et répertoires associés à l’utilisateur :

  chown -R jean: /home/jean/

Nous avons maintenant un utilisateur “jean” créé. Nous ferons la même chose pour l’utilisateur “sarah”. Il existe de nombreuses étapes à effectuer et cela peut prendre beaucoup de temps si nous avons plusieurs utilisateurs à créer. C’est pourquoi j’édite des scripts bash qui automatisent le processus. Vous pouvez les trouver sur mon dépôt Github.

Les utilisateurs sont désormais actifs et nous allons créer les deux namespaces mentionnés précédemment :

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

Comme nous n’avons défini aucune autorisation pour les utilisateurs, ceux-ci n’auront pas la permission pour accéder à toutes les ressources du cluster.

• Utilisateur 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"

• Utilisateur 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 des types Role et ClusterRole

Nous allons utilisé les ClusterRole disponible par défaut. Cependant, nous allons vous montrer comment créer des types spécifiques de Role et ClusterRole. Les types Role et ClusterRole ne sont qu’une liste de verbes (actions) autorisés sur des ressources et des namespaces spécifiques. 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 ]

Créable ainsi :

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

Association des types Role et ClusterRole aux utilisateurs

Nous allons maintenant lier le ClusterRole par défaut (Edit and View) à nos utilisateurs comme ci-dessous :

• jean :
  • Éditez sur le namespace “my-project-dev”
  • Voir sur le namespace “my-project-prod”
• Sarah :
  • Editer sur le namespace “my-project-prod”

Nous devons créer le RoleBinding par namespaces et non par utilisateurs. Cela signifie que pour notre utilisateur “jean”, nous devons créer deux RoleBinding pour ses autorisations. Exemple de fichier yaml RoleBinding 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 assignons à “jean” le rôle “view” dans “my-project-prod” et le rôle “edit” sur “my-project-dev”. Nous ferons de même pour les autorisations “sarah” :

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

Nous avons ici utilisé la commande kubectl apply au lieu de kubectl create. La différence entre “apply” et “create” est que “create” créera l’objet s’il n’existe pas et ne fait rien d’autre. Mais utiliser “apply” signifie qu’il créera l’objet s’il n’existe pas et le mettra à jour si nécessaire.Vérifions si nos utilisateurs ont les bonnes autorisations.

Vérifions si nos utilisateurs ont les bonnes autorisations.

• Utilisateur sarah (rôle “edit” sur “my-project-prod”)
  • my-project-prod :
    • Peut lister les pods(1)
    • Peut créer des deployments(2)
  • my-project-dev :
    • Ne peut pas lister des pods(4)
    • Ne peut pas créer des deployments(5)

kubectl get pods -n my-project-prod 
No resources found. 

kubectl run nginx --image=nginx --replicas=1 -n my-project-prod 
deployment.apps/nginx created 

[sarah@master1 ~]$kubectl get pods -n my-project-prod 
NAME                    READY  STATUS   RESTARTS  AGE 
nginx-7db9fccd9b-t14qw  1/1    Running  0         4s 

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"

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 (rôle “view” sur “my-project-prod” et “edit” sur “my-project-dev”)
  • my-project-prod :
    • Peut lister des pods(1)
    • Peut lister des deployments(2)
    • Ne peut pas supprimer des deployments(3)
  • my-project-dev :
    • Peut lister des pods(4)
    • Peut créer des deployments(5)
    • Peut lister des deployments(6)
    • Peut supprimer des deployments(7)

kubectl get pods -n my-project-prod 
NAME                    READY  STATUS   RESTARTS  AGE 
nginx-7db9fccd9b-t14qw  1/1    Running  0         101s 

[jean@master1 —]$ kubectl get deploy -n my-project-prod 
NAME   READY  UP-TO-DATE  AVAILABLE  AGE 
nginx  1/1    1           1          110s 

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" 

kubectl get pods -n my-project-dev
No resources found. 

kubectl run nginx --image=nginx --replicas=1 -n my-project-dev 
deployment.apps/nginx created 

kubectl get deploy -n my-project-dev 
NAME   READY  UP-TO-DATE  AVAILABLE  AGE 
nginx  0/1    1           0          13s 

kubectl delete deploy/nginx -n my-project-dev 
deployment.extensions "nginx" deleted 

kubectl get deploy -n my-project-dev 
No resources found.

Gestion des utilisateurs et de leurs authorisations

Maintenant que nous avons défini différents rôles et autorisations pour nos utilisateurs, comment pouvons-nous gérer tout cela ? Comment pouvons-nous savoir si un utilisateur possède le bon accès ? Comment savoir qui peut réellement effectuer une action spécifique ? Comment avoir une vue d’ensemble de tous les accès utilisateurs ? Telles sont les questions auxquelles nous devons répondre pour assurer la sécurité du cluster. Dans Kubernetes, nous avons la commande kubectl auth can-i qui nous permet de savoir si un utilisateur peut effectuer une action spécifique.

# kubectl auth can-i $action $resource --as $subject

kubectl auth can-i list pods 
kubectl auth can-i list pods --as jean

La première commande permet à un utilisateur de savoir s’il peut effectuer une action. La deuxième commande permet à un administrateur d’emprunter l’identité d’un utilisateur pour savoir si l’utilisateur ciblé peut effectuer une action. L’emprunt d’identité ne peut être utilisé que par un utilisateur disposant de permissions “cluster-admin”. En dehors de cela, nous ne pouvons pas faire beaucoup plus. C’est pourquoi nous allons vous présenter quelques projets Open Source qui nous permettent d’étendre les fonctionnalités couvertes par la commande kubectl auth can-i. Avant de les présenter, nous allons installer certaines de leurs dépendances telles que Krew et GO.

Installation de GO

Go est un langage de programmation open source qui facilite la création de logiciels simples, fiables et efficaces. Inspiré par C et Pascal, ce langage a été développé par Google à partir d’un concept initial 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 facilite l’utilisation des plugins kubectl. Krew vous aide à découvrir, installer et gérer des plugins sur votre machine. Cela ressemble à des outils comme apt, dnf ou brew. Krew est uniquement compatible avec kubectl v1.12 et supérieur.

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 nous aide à connaître toutes les autorisations accordées à un utilisateur. Cela aide à répondre à la question : que peut faire “jean” ? Tout d’abord, installons Rakkess :

kubectl krew install access_matrix

Vous pouvez trouver la documentation sur le repôt Github du projet. Voici un exemple :

kubectl access-matrix -n my-project-dev --as jean
NAME                                            LIST  CREATE  UPDATE  DELETE
bindings                                               ✖               
configmaps                                      ✔     ✔       ✔       ✔
controllerrevisions.apps                        ✔     ✖       ✖       ✖
cronjobs.batch                                  ✔     ✔       ✔       ✔
daemonsets.apps                                 ✔     ✔       ✔       ✔
daemonsets.extensions                           ✔     ✔       ✔       ✔
deployments.apps                                ✔     ✔       ✔       ✔
deployments.extensions                          ✔     ✔       ✔       ✔
endpoints                                       ✔     ✔       ✔       ✔
events                                          ✔     ✖       ✖       ✖
events.events.k8s.io                            ✖     ✖       ✖       ✖
horizontalpodautoscalers.autoscaling            ✔     ✔       ✔       ✔
ingresses.extensions                            ✔     ✔       ✔       ✔
ingresses.networking.k8s.io                     ✔     ✔       ✔       ✔
jobs.batch                                      ✔     ✔       ✔       ✔
leases.coordination.k8s.io                      ✖     ✖       ✖       ✖
limitranges                                     ✔     ✖       ✖       ✖
localsubjectaccessreviews.authorization.k8s.io         ✖               
networkpolicies.extensions                      ✔     ✔       ✔       ✔
networkpolicies.networking.k8s.io               ✔     ✔       ✔       ✔
persistentvolumeclaims                          ✔     ✔       ✔       ✔
poddisruptionbudgets.policy                     ✔     ✔       ✔       ✔
pods                                            ✔     ✔       ✔       ✔
podtemplates                                    ✖     ✖       ✖       ✖
replicasets.apps                                ✔     ✔       ✔       ✔
replicasets.extensions                          ✔     ✔       ✔       ✔
replicationcontrollers                          ✔     ✔       ✔       ✔
resourcequotas                                  ✔     ✖       ✖       ✖
rolebindings.rbac.authorization.k8s.io          ✖     ✖       ✖       ✖
roles.rbac.authorization.k8s.io                 ✖     ✖       ✖       ✖
secrets                                         ✔     ✔       ✔       ✔
serviceaccounts                                 ✔     ✔       ✔       ✔
services                                        ✔     ✔       ✔       ✔
statefulsets.apps                               ✔     ✔       ✔       ✔

kubect-who-can

Ce projet nous permet de savoir qui sont les utilisateurs pouvant effectuer une action spécifique. Cela aide à répondre à la question : qui peut faire cette action ?

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

Vous pouvez trouver la documentation sur le repôt Github du projet. Voici un exemple :

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 nous permet d’avoir une vue d’ensemble de RBAC. Cela aide à répondre aux questions suivantes : Quel rôles a “jean” ? “sarah” ? Tous les utilisateurs ? tout le groupe ?

kubectl krew install rbac-lookup

La documentation officielle est disponible sur le repôt Github du projet. Voici un exemple :

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

Ce projet nous permet d’avoir un gestionnaire pour RBAC, comme son nom l’indique. Cela simplifie beaucoup d’opération. Le plus important est la création de RoleBindings. En effet, nous avons constaté que si nous devions créer différents rôles pour un utilisateur, nous devions créer différents RoleBindings. RBAC Manager nous aide en nous permettant de créer un seul RoleBinding avec toutes les autorisations qu’il contient. Pour l’installer, vous pouvez télécharger le fichier YAML à partir du repôt Github :

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

La documentation officielle est disponible sur le repôt Github du projet. voici un exemple :

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 de certificats clients X.509 générés avec OpenSSL et en leur accordant des autorisations. Vous pouvez utiliser le script disponible sur mon repôt Github afin de créer facilement des utilisateurs. En ce qui concerne l’administration du cluster, vous pouvez utiliser les projets open source présentés dans cet article. Pour résumer ces projets :

• kubectl auth can-i : savoir si un utilisateur peut effectuer une action spécifique
• rakkess : connaître toutes les actions qu’un utilisateur peut effectuer
• kubectl-who-can : savoir qui sont les utilisateurs pouvant effectuer une action spécifique
• rbac-lookup : visualiser l’ensemble des RBAC
• RBAC Manager : obtenez une configuration plus simple qui regroupe les liaisons, une automatisation facile des modifications RBAC et des label selectors.

Il peut être très fastidieux de gérer toutes les étapes de la création d’utilisateur. Surtout si nous avons plusieurs utilisateurs à créer en même temps et d’autres à créer fréquemment. Cela est plus facile avec un annaire LDAP connectée au cluster Kubernetes. Il existe des projets Open Source qui fournissent un Webhook d’authentification LDAP directe à Kubernetes : Kismatic et ObjectifLibre. Une autre solution consiste à configurer un serveur OpenId avec votre entreprise LDAP comme backend.