Comprendre Kubernetes RBAC : principaux concepts et exemples

Kubernetes n’est pas une plateforme de sécurité. Il ne dispose pas d’outils natifs pour gérer la plupart des tâches liées à la sécurité, telles que la détection des vulnérabilités dans les applications et la surveillance des violations.

Cependant, il existe bien une tâche de sécurité que Kubernetes gère très bien de manière native : le contrôle d’accès basé sur les rôles (RBAC). Kubernetes offre un framework RBAC étendu et intégré. Tirer parti de Kubernetes RBAC est une première étape fondamentale pour sécuriser les clusters et les applications fonctionnant dans Kubernetes.

Cet article présente les concepts qui sont au cœur de Kubernetes RBAC, montre comment utiliser les politiques RBAC de Kubernetes et met en évidence les meilleures pratiques à suivre et les erreurs à éviter lorsqu’on travaille avec RBAC dans Kubernetes.

Kubernetes RBAC : concepts fondamentaux

Si vous lisez ces lignes, vous connaissez probablement le principe général de RBAC. Suivant le contexte (systèmes d’exploitation ou clouds publics), les systèmes RBAC peuvent être utilisés pour définir qui peut accéder à quoi en fonction des identités des utilisateurs.

Kubernetes RBAC repose sur ces concepts. Toutefois, le système RBAC de Kubernetes diffère de la plupart des autres types de frameworks RBAC sur quelques points essentiels :

Comptes utilisateurs contre comptes de services

Dans Kubernetes, les politiques RBAC peuvent être utilisées pour définir les droits d’accès des utilisateurs humains (ou des groupes d’utilisateurs humains). Kubernetes identifie les utilisateurs humains comme des comptes d’utilisateurs.

Cependant, les politiques RBAC peuvent également régir le comportement des ressources logicielles, que Kubernetes identifie comme des comptes de services.

Bien que Kubernetes établisse une distinction entre les comptes d’utilisateurs et les comptes de services à un niveau conceptuel, la différence n’a pas vraiment d’importance en ce qui concerne les politiques RBAC. C’est ce qui différencie le système RBAC de Kubernetes de nombreux autres systèmes RBAC, qui se concentrent généralement sur la gestion des autorisations des utilisateurs humains (en fonction de facteurs tels que leur rôle professionnel ou leur type de compte) plutôt que sur la gestion de l’accès aux services logiciels.

Définitions flexibles des ressources

Kubernetes RBAC est également assez large dans la manière dont Kubernetes définit les entités que les politiques RBAC peuvent régir.

Kubernetes désigne ces entités sous le nom de « ressources », et elles peuvent être presque tout ce que vous désirez : pods, journaux, contrôleurs d’entrée, ou tout autre type de ressource personnalisée que vous choisissez de définir.

La plupart des autres systèmes RBAC ont tendance à être plus restrictifs quant aux types de ressources que vous pouvez gérer. Par exemple, les frameworks IAM du cloud sont conçus pour gérer uniquement des types de ressources prédéfinis, comme des instances de machines virtuelles ou des compartiments de stockage. Vous pourriez également utiliser le balisage pour contrôler quelles politiques s’appliquent à quelles ressources, mais cette approche est moins évolutive que celle de Kubernetes, car vous devriez créer chaque balise manuellement.

Comparaison entre les rôles et les ClusterRoles

Une particularité relativement simple mais importante du RBAC de Kubernetes est qu’il établit une distinction entre les autorisations qui s’appliquent aux ressources d’un namespace, qui sont gérées par les rôles, et celles qui s’appliquent à l’ensemble du cluster, qui sont gérées par les ClusterRoles.

Dans la plupart des cas, vous travaillerez avec des rôles, qui peuvent être utilisés pour gérer les autorisations sur une base plus granulaire (c’est-à-dire dans des namespaces individuels). Mais parfois, vous voudrez utiliser des ClusterRoles pour gérer les règles pour les ressources qui n’existent qu’au niveau du cluster, comme les nœuds.

Gestion des permissions par le biais de « verbes »

Contrairement aux systèmes de contrôle d’accès qui ne peuvent qu’autoriser ou refuser l’accès, ou aux systèmes qui divisent les droits d’accès en grandes catégories telles que « lire », « écrire » et « exécuter », le RBAC de Kubernetes fournit une série de « verbes » qui définissent les actions spécifiques que les comptes peuvent effectuer sur les ressources.

Par exemple, vous pouvez autoriser un utilisateur à « créer » et « lister » une ressource donnée en spécifiant les verbes appropriés dans une politique RBAC.

Vous pouvez obtenir une liste de tous les verbes disponibles dans votre cluster en exécutant :

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get 
--show-kind --ignore-not-found -l <label>=<value> -n <namespace>

Travailler avec Kubernetes RBAC : étapes et exemples

Maintenant que nous connaissons les principes fondamentaux de RBAC dans Kubernetes, voyons comment l’utiliser.

Vérifier la prise en charge de RBAC

Tout d’abord, assurez-vous que votre cluster prend RBAC en charge. RBAC a été introduit avec Kubernetes 1.6 et la plupart des clusters l’activent par défaut, mais il n’est jamais inutile de vérifier sa comptabilité.

Recherchez un fichier de configuration RBAC dans /etc/kubernetes/manifests sur votre ou vos nœuds master ou sur le pod serveur API Kubernetes, et assurez-vous qu’il contient l’indicateur :

--authorization-mode=Node,RBAC

Définir les utilisateurs et les comptes de service

Ensuite, vous devez définir les utilisateurs et/ou les comptes de service, auxquels vous attribuerez plus tard des autorisations. À titre d’exemple simple, voici les étapes de la création d’un compte d’utilisateur pour un utilisateur que nous appellerons Jean.

Commencez par créer une nouvelle clé privée :

openssl genrsa -out john.key 2048

Ensuite, vous devez créer une demande de signature de certificat contenant la clé publique et d’autres

informations sur le sujet :

openssl req -new -key john.key -out john.csr -subj "/CN=john/
O=examplegroup"

Notez que Kubernetes utilisera le champ Organisation (O=examplegroup) pour déterminer

l’appartenance du groupe d’utilisateurs pour RBAC.

Vous signerez ce CSR à l’aide de l’autorité de certification racine de Kubernetes, qui se trouve dans /etc/kubernetes/pki dans cet exemple (l’emplacement du fichier dans votre déploiement peut varier) :

openssl x509 -req -in john.csr -CA /etc/kubernetes/pki/ca.crt
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out john.crt
Signature ok
subject=/CN=john/O=examplegroup
Getting CA Private Key

Vous pouvez contrôler le nouveau certificat :

openssl x509 -in john.crt -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 11309651818125161147 (0x9cf3f46850b372bb)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=kubernetes
Validity
Not Before: Apr 2 20:20:54 2018 GMT
Not After : May 2 20:20:54 2018 GMT
Subject: CN=john, O=examplegroup
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)

Enfin, enregistrez les nouvelles informations d’identification et le contexte de configuration :

kubectl config set-credentials john --client-certificate=/home/newusers/john.crt --client-
key=/home/newusers/john.key


kubectl config set-context john@kubernetes --cluster=kubernetes --user=john

Créer un rôle ou un ClusterRole

Ensuite, nous devons créer un rôle ou ClusterRole. C’est à cette étape que nous définissons les actions qui peuvent être effectuées sur une ressource.

Par exemple, voici un rôle qui accorde des autorisations get (récupérer), watch (surveiller) et list (lister) pour les pods.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Créer un RoleBinding ou ClusterRoleBinding

Enfin, nous devons « lier » notre Rôle ou ClusterRole à l’utilisateur ou au compte que nous avons créé. La liaison est ce qui permet réellement à l’utilisateur ou au compte spécifié de remplir le rôle donné.

kubectl create rolebinding podreader-binding --user=john

Meilleures pratiques de Kubernetes RBAC

Kubernetes RBAC est un outil puissant. Voici les meilleures pratiques pour l’utiliser de la manière la plus responsable possible.

Réduire le nombre d’indicateurs du serveur API

L’API Kubernetes comporte un certain nombre d’indicateurs facultatifs qui, lorsqu’ils sont activés, peuvent simplifier certains aspects de la gestion de Kubernetes. Mais ils augmentent également les risques de sécurité. Évitez ces indicateurs dans la mesure du possible :

–insecure-port : Ouvre l’accès à des requêtes non autorisées et non authentifiées. Si ce

paramètre est sur 0, cela signifie aucun port insécurisé.

–insecure-bind-address : Idéalement, vous devriez éviter toute connexion non sécurisée, mais si vous en avez vraiment besoin, vous pouvez utiliser ce paramètre pour vous lier à localhost. Assurez-vous que ce paramètre n’est pas défini, ou du moins pas défini sur une adresse IP accessible par le réseau.
–anonymous-auth : Active les requêtes anonymes vers le port sécurisé du serveur API.

Suivre le moindre privilège

Comme tout système RBAC, celui de Kubernetes est plus efficace lorsque les administrateurs suivent le principe du moindre privilège, ce qui signifie que chaque utilisateur ou compte ne reçoit que les privilèges minimums nécessaires à l’exécution de son travail.

Dans la pratique, cela revient à des actions comme utiliser des rôles plutôt que des ClusterRoles lorsque c’est possible. Même si la configuration des rôles pour chaque namespace est un peu plus lourde que la possibilité de définir un ClusterRole pour l’ensemble du cluster, les rôles sont plus sûrs car ils s’appliquent à moins de ressources.

De même, évitez les caractères de remplacement [« * »] lorsque vous définissez des verbes ou l’accès à des ressources. Les caractères génériques sont les « chmod 777 » de Kubernetes : ils sont pratiques à appliquer, mais ils ouvrent toutes sortes de trous d’accès non autorisés.

Éviter les comptes de services par défaut

Kubernetes crée des comptes de services par défaut pour identifier les processus exécutés dans un pod.

Vous pouvez être tenté d’utiliser ces comptes par défaut pour attribuer des autorisations plutôt que de vous donner la peine de configurer vos propres comptes. Ce n’est pas une bonne pratique. Au lieu de cela, créez des comptes de services spécifiques aux services, qui constituent la base de contrôles d’accès plus granulaires.

Au fait, si vous vous interrogez sur les utilisateurs par défaut, sachez que Kubernetes n’a pas de comptes d’utilisateurs par défaut, donc vous n’avez pas à vous en soucier. Vous devez créer les utilisateurs explicitement si vous voulez leur attribuer des Rôles ou des ClusterRoles.

Mettre à jour les politiques RBAC en permanence

L’efficacité de Kubernetes RBAC dépend des politiques RBAC que vous créez. Et si vos politiques deviennent obsolètes, vous risquez de vous retrouver rapidement avec des utilisateurs ou des comptes de service sur-autorisés.

C’est pourquoi il est préférable de s’assurer que chaque fois que vous créez, supprimez ou mettez à jour les autorisations d’un compte d’utilisateur ou de service, ou lorsque vous créez un namespace ou des pods, vous modifiez ou supprimez également toutes les politiques RBAC associées à cette entité. Cela peut être quelque peu fastidieux, étant donné que Kubernetes possède plusieurs types de fichiers associés à RBAC (Roles, RoleBindings, ClusterRoles et ClusterRoleBindings). Il est néanmoins important de faire des mises à jour des politiques RBAC une partie systématique et continue de la gestion de Kubernetes.

Utiliser pleinement Kubernetes RBAC

Il est impossible d’exécuter un cluster Kubernetes sécurisé, quelle que soit sa taille, sans tirer parti de RBAC. Si vous pouvez vous passer des politiques RBAC si vous exécutez un cluster à un seul nœud sur votre ordinateur portable à des fins de test, un cluster avec plusieurs utilisateurs, pods, namespaces, etc. a besoin de politiques RBAC pour définir qui peut faire quoi et qu’est-ce qui peut être fait au sein du cluster.

Ainsi, bien que l’approche de Kubernetes en matière de RBAC puisse sembler un peu inhabituelle à certains égards, et qu’il ne s’agisse pas toujours du type de système RBAC le plus simple à utiliser, investir du temps pour comprendre comment fonctionne RBAC dans Kubernetes et comment l’utiliser efficacement est une bonne pratique de base pour sécuriser tout environnement Kubernetes de production.