Configurer la multilocation avec les espaces de noms Kubernetes

Les espaces de noms fournissent des éléments de base du contrôle d'accès pour les applications, les utilisateurs ou les groupes d'utilisateurs.

La plupart des entreprises souhaitent une plate-forme multi-tenant pour exécuter leurs applications cloud natives, car elle permet de gérer les ressources, les coûts et l'efficacité opérationnelle et de contrôler le gaspillage du cloud.

Kubernetes est la principale plateforme open source pour la gestion des charges de travail et des services conteneurisés. Il a acquis cette réputation en raison de sa flexibilité en permettant aux opérateurs et aux développeurs d'établir une automatisation avec une configuration déclarative. Mais il y a un problème : comme Kubernetes se développe rapidement, le vieux problème de la vitesse devient un problème. Plus votre adoption est importante, plus vous découvrez de problèmes et de gaspillage de ressources.

Un exemple d'échelle

Imaginez que votre entreprise ait démarré modestement en adoptant Kubernetes en déployant diverses applications internes. Il comporte plusieurs flux de projets exécutés avec plusieurs développeurs dédiés à chaque flux de projet.

Dans un scénario comme celui-ci, vous devez vous assurer que votre administrateur de cluster a un contrôle total sur le cluster pour gérer ses ressources et mettre en œuvre la politique et les normes de sécurité du cluster. D'une certaine manière, l'administrateur incite les utilisateurs du cluster à utiliser les meilleures pratiques. Un espace de noms est très utile dans ce cas car il permet à différentes équipes de partager un seul cluster où les ressources informatiques sont subdivisées en plusieurs équipes.

Bien que les espaces de noms constituent votre première étape vers la multilocation Kubernetes, ils ne suffisent pas à eux seuls. Vous devez prendre en compte un certain nombre de primitives Kubernetes afin de pouvoir administrer correctement votre cluster et le mettre en œuvre dans une implémentation prête pour la production.

Les primitives Kubernetes pour la multilocation sont :

RBAC : contrôle d'accès basé sur les rôles pour Kubernetes
Règles de réseau : pour isoler le trafic entre les espaces de noms
Quotas de ressources : pour contrôler un accès équitable aux ressources du cluster

Cet article explique comment utiliser les espaces de noms Kubernetes et certaines configurations RBAC de base pour partitionner un seul cluster Kubernetes et tirer parti de ces outils Kubernetes intégrés.

Qu'est-ce qu'un espace de noms Kubernetes ?

Avant d'explorer comment utiliser les espaces de noms pour préparer votre cluster Kubernetes à devenir prêt pour le multi-tenant, vous devez savoir ce que sont les espaces de noms.

Un espace de noms est un objet Kubernetes qui partitionne un cluster Kubernetes en plusieurs clusters virtuels. Cela se fait à l’aide des noms et identifiants Kubernetes. Les espaces de noms utilisent l'objet de nom Kubernetes, ce qui signifie que chaque objet à l'intérieur d'un espace de noms obtient un nom et un ID uniques dans le cluster pour permettre le partitionnement virtuel.

Comment les espaces de noms sont utiles dans la multilocation

Les espaces de noms sont l'une des primitives Kubernetes que vous pouvez utiliser pour partitionner votre cluster en plusieurs clusters virtuels afin de permettre la multilocation. Chaque espace de noms est isolé de l’espace de noms de tous les autres utilisateurs, équipes ou applications. Cette isolation est essentielle dans la multilocation afin que les mises à jour et les modifications apportées aux applications, aux utilisateurs et aux équipes soient contenues dans l'espace de noms spécifique. (Notez que l'espace de noms ne fournit pas de segmentation du réseau.)

Avant de continuer, vérifiez l'espace de noms par défaut dans un cluster Kubernetes fonctionnel :

[root@master ~]# kubectl get namespace
NAME              STATUS   AGE
default           Active   3d
kube-node-lease   Active   3d
kube-public       Active   3d
kube-system       Active   3d

Créez ensuite votre premier espace de noms, appelé test :

[root@master ~]# kubectl create namespace test
namespace/test created

Vérifiez l'espace de noms nouvellement créé :

[root@master ~]# kubectl get namespace
NAME              STATUS   AGE
default           Active   3d
kube-node-lease   Active   3d
kube-public       Active   3d
kube-system       Active   3d
test              Active   10s
[root@master ~]#

Décrivez l'espace de noms nouvellement créé :

[root@master ~]# kubectl describe namespace test
Name:         test
Labels:       <none>
Annotations:  <none>
Status:       Active
No resource quota.
No LimitRange resource.

Pour supprimer un espace de noms :

[root@master ~]# kubectl delete namespace test
namespace "test" deleted

Votre nouvel espace de noms est actif, mais aucune étiquette, annotation ou plage de limite de quota n’est définie. Cependant, maintenant que vous savez comment créer, décrire et supprimer un espace de noms, je vais vous montrer comment utiliser un espace de noms pour partitionner virtuellement un cluster Kubernetes.

Partitionnement des clusters à l'aide de l'espace de noms et de RBAC

Déployez l'application simple suivante pour apprendre à partitionner un cluster à l'aide d'un espace de noms et à isoler une application et ses objets associés des « autres » utilisateurs.

Tout d’abord, vérifiez l’espace de noms que vous utiliserez. Pour plus de simplicité, utilisez l'espace de noms test que vous avez créé ci-dessus :

[root@master ~]# kubectl get namespaces
NAME              STATUS   AGE
default           Active   3d
kube-node-lease   Active   3d
kube-public       Active   3d
kube-system       Active   3d
test              Active   3h

Déployez ensuite une application simple appelée test-app dans l'espace de noms de test en utilisant la configuration suivante :

apiVersion: v1
kind: Pod
metadata:
  name: test-app                 ⇒ name of the application
  namespace: test                ⇒ the namespace where the app runs
  labels:
     app: test-app			⇒ labels for the app
spec:
  containers:
  - name: test-app
    image: nginx:1.14.2         ⇒ the image we used for the app. 
    ports:
    - containerPort: 80

Déployez-le :

$ kubectl create -f test-app.yaml
    pod/test-app created

Vérifiez ensuite que le pod d'application a été créé :

$ kubectl get pods -n test
  NAME       READY   STATUS    RESTARTS   AGE
  test-app   1/1     Running   0          18s

Maintenant que l'application en cours d'exécution se trouve dans l'espace de noms test, testez un cas d'utilisation dans lequel :

L'utilisateur auth peut modifier et afficher tous les objets à l'intérieur de l'espace de noms de test.
un-auth-user ne peut afficher que l'espace de noms

J'ai pré-créé les utilisateurs pour que vous puissiez les tester. Si vous voulez savoir comment j'ai créé les utilisateurs dans Kubernetes, consultez les commandes ici.

$ kubectl config view -o jsonpath='{.users[*].name}' 
  auth-user 
  kubernetes-admin
  un-auth-user

Avec cette configuration, créez un rôle Kubernetes et des RoleBindings pour isoler l'espace de noms cible test afin de permettre à l'utilisateur auth d'afficher et de modifier les objets à l'intérieur de l'espace de noms et de ne pas autoriser un-auth-user pour accéder ou afficher les objets à l'intérieur de l'espace de noms test.

Commencez par créer un ClusterRole et un rôle. Ces objets sont une liste de verbes (action) autorisés sur des ressources et des espaces de noms spécifiques.

Créez un ClusterRole :

$ cat clusterrole.yaml 
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: list-deployments
  namespace: test
rules:
  - apiGroups: [ apps ]
    resources: [ deployments ]
    verbs: [ get, list ]

Créer un rôle :

$ cat role.yaml 
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: list-deployments
  namespace: test
rules:
  - apiGroups: [ apps ]
    resources: [ deployments ]
    verbs: [ get, list ]

Appliquer le rôle :

$ kubectl create -f role.yaml 
roles.rbac.authorization.k8s.io "list-deployments" created

Utilisez la même commande pour créer un ClusterRole :

$ kubectl create -f clusterrole.yaml

$ kubectl get role -n test
  NAME               CREATED AT
  list-deployments   2021-01-18T00:54:00Z

Vérifiez les rôles :

$ kubectl describe roles -n test
  Name:         list-deployments
  Labels:       <none>
  Annotations:  <none>
  PolicyRule:
    Resources         Non-Resource URLs  Resource Names  Verbs
    ---------         -----------------  --------------  -----
    deployments.apps  []                 []              [get list]

N'oubliez pas que vous devez créer des RoleBindings par espace de noms et non par utilisateur. Cela signifie que vous devez créer deux liaisons de rôle pour l'utilisateur auth-user.

Voici les exemples de fichiers YAML RoleBinding pour permettre à utilisateur auth de modifier et d'afficher.

Pour modifier :

$ cat rolebinding-auth-edit.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: auth-user-edit
  namespace: test
subjects:
- kind: User
  name: auth-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Pour afficher :

$ cat rolebinding-auth-view.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: auth-user-view
  namespace: test
subjects:
- kind: User
  name: auth-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Créez ces fichiers YAML :

$ kubectl create rolebinding-auth-view.yaml 
$ kubectl create rolebinding-auth-edit.yaml

Vérifiez si les RoleBindings ont été créés avec succès :

$ kubectl get rolebindings -n test
NAME             ROLE               AGE
auth-user-edit   ClusterRole/edit   48m
auth-user-view   ClusterRole/view   47m

Une fois la configuration requise configurée, testez le partitionnement du cluster :

[root@master]$ sudo su un-auth-user
[un-auth-user@master ~]$ kubect get pods -n test
[un-auth-user@master ~]$ kubectl get pods -n test
Error from server (Forbidden): pods is forbidden: User "un-auth-user" cannot list resource "pods" in API group "" in the namespace "test"

Connectez-vous en tant qu'utilisateur auth :

[root@master ]# sudo su auth-user
[auth-user@master auth-user]$ kubectl get pods -n test
NAME       READY   STATUS    RESTARTS   AGE
test-app   1/1     Running   0          3h8m
[auth-user@master un-auth-user]$

[auth-user@master auth-user]$ kubectl edit pods/test-app -n test
Edit cancelled, no changes made.

Vous pouvez afficher et modifier les objets dans l'espace de noms test. Que diriez-vous de visualiser les nœuds du cluster ?

[auth-user@master auth-user]$ kubectl get nodes 
Error from server (Forbidden): nodes is forbidden: User "auth-user" cannot list resource "nodes" in API group "" at the cluster scope
[auth-user@master auth-user]$

Vous ne pouvez pas le faire, car les liaisons de rôle pour l'utilisateur auth-user exigent qu'il ait accès à l'affichage ou à la modification des objets uniquement à l'intérieur de l'espace de noms test.

Activer le contrôle d'accès avec les espaces de noms

Les espaces de noms fournissent les éléments de base du contrôle d'accès utilisant RBAC et de l'isolation pour les applications, les utilisateurs ou les groupes d'utilisateurs. Mais utiliser uniquement des espaces de noms comme solution multi-tenant ne suffit pas dans une mise en œuvre en entreprise. Il est recommandé d'utiliser d'autres primitives d'hébergement multiclient Kubernetes pour obtenir une isolation plus poussée et mettre en œuvre une sécurité appropriée.

Les espaces de noms peuvent fournir une certaine isolation de base dans votre cluster Kubernetes ; il est donc important de les prendre en compte dès le départ, en particulier lors de la planification d'un cluster multi-tenant. Les espaces de noms vous permettent également de séparer et d'attribuer logiquement des ressources à des utilisateurs individuels, des équipes ou des applications.

En utilisant des espaces de noms, vous pouvez augmenter l'efficacité des ressources en permettant à un seul cluster d'être utilisé pour un ensemble diversifié de charges de travail.