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 clients 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 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 :

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 des ensembles 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.
  • 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 :

Nous pouvons, bien sûr, créer des Role et ClusterRole spécifiques, mais nous vous recommandons d’utiliser les rôles 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 servant de master puis se rendre dans son home directory pour effectuer les étapes restantes.
  • Création de sa private key.
  • 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.
  • Signer le CSR avec le CA de Kubernetes. Le certificat et la clé de Kubernetes sont localisés dans  /etc/kubernetes/pki. Les certificats générés ci-dessous seront valides pour 500 jours.
  • Création d’un répertoire “.certs” où sera stocké les clé public et privées de l’utilisateur.
  • Création de l’utilisateur dans Kubernetes.
  • Création d’un contexte associé à l’utilisateur.
  • 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.

    Ensuite, nous devons copier la configuration ci-dessus dans le répertoire .kube.
  • Appliquer les permission sur tous les fichiers et répertoires associés à l’utilisateur.

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’ai édité 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 :

Comme nous n’avons défini aucune autorisation pour les utilisateurs, ceux-ci auront des accès “Forbidden” à toutes les ressources du cluster.

  • Utilisateur  Jean

  • Utilisateur Sarah

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 :

Créable ainsi :

Association des types Role et ClusterRole aux utilisateurs

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

  • jean:
    • “Edit” sur le namespace “my-project-dev”
    • “View” sur le namespace “my-project-prod”
  • Sarah:
    • “Edit” 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:

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” :

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 :
    • my-project-dev :

  • Utilisateur jean (rôle “view” sur “my-project-prod” et “edit” sur “my-project-dev”)

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.

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.

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.

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 :

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

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 ?

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

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 les groupes ?

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

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. Pour l’installer, vous pouvez télécharger le fichier YAML à partir du repôt Github:

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

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 : obtenir 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.