Il a toujours été difficile d'héberger en toute sécurité un grand nombre d'utilisateurs sur un seul cluster Kubernetes. La raison principale est que toutes les organisations utilisent Kubernetes différemment, il est donc peu probable qu'un seul modèle multi-utilisateur fonctionne pour tout le monde. Au lieu de cela, Kubernetes propose des composants pour créer votre propre solution, tels que le contrôle d'accès basé sur les rôles (RBAC) et NetworkPolicies; plus ces composants sont performants, plus il est facile de créer un cluster multi-utilisateurs sécurisé.
Les espaces de noms se précipitent à la rescousse
Les espaces de noms sont de loin les plus importants de ces composants . Ils forment la base de presque toutes les politiques de partage de plan de sécurité et de contrôle dans Kubernetes. Par exemple, RBAC, NetworkPolicies et ResourceQuotas prennent en charge les espaces de noms par défaut, tandis que des objets tels que Secret, ServiceAccount et Ingress sont disponibles gratuitement dans un espace mais complètement isolés des autres .
Les espaces de noms ont quelques caractéristiques clés qui les rendent idéaux pour l'application des stratégies. Premièrement, ils peuvent être utilisés pour représenter une propriété . La plupart des objets Kubernetes devraientêtre dans n'importe quel espace de noms. En utilisant des espaces de noms pour représenter la propriété, vous pouvez toujours compter sur la propriété de ces objets.
Deuxièmement, seuls les utilisateurs disposant des droits appropriés peuvent créer et utiliser des espaces de noms . Vous avez besoin de privilèges élevés pour créer des espaces de noms, et les autres utilisateurs ont besoin d'une autorisation explicite pour travailler avec eux, c'est-à-dire pour créer, afficher ou modifier des objets dans ces espaces de noms. Ainsi, un espace de noms est d'abord créé avec un ensemble élaboré de politiques, et ce n'est qu'ensuite que les utilisateurs non privilégiés peuvent créer des objets "normaux" comme des pods et des services.
Restrictions d'espace de noms
Malheureusement, dans la pratique, les espaces de noms ne sont pas assez flexibles et ne s'intègrent pas bien dans certains cas d'utilisation courants. Par exemple, une certaine équipe possède plusieurs microservices avec différents secrets et quotas. Idéalement, ils devraient diviser ces services en espaces de noms séparés pour les isoler les uns des autres, mais cela pose deux problèmes.
Premièrement, ces espaces de noms n'ont pas de concept unique de propriété, même s'ils appartiennent tous deux à la même équipe. Cela signifie que non seulement Kubernetes ne sait rien du fait que ces espaces de noms ont un seul propriétaire, mais qu'il n'a pas non plus la possibilité d'appliquer des stratégies globales à tous les espaces de noms contrôlés à la fois.
Deuxièmement, comme vous le savez, l'autonomie est la clé d'un travail d'équipe efficace. Étant donné que la création d'espaces de noms nécessite des privilèges élevés, il est peu probable que quiconque dans l'équipe de développement ait ces privilèges. En d'autres termes, chaque fois qu'une équipe décide de créer un nouvel espace de noms, elle doit contacter l'administrateur du cluster. Cela peut être parfaitement acceptable pour une petite entreprise, mais à mesure qu'elle se développe, l'effet négatif d'une telle organisation devient plus prononcé.
Présentation des espaces de noms hiérarchiques
Les espaces de noms hiérarchiques sont un nouveau concept développé par le groupe de travail multi-tenancy de Kubernetes ( wg-multitenancy ) pour résoudre ces problèmes. Dans une forme simplifiée, un espace de noms hiérarchique est un espace de noms Kubernetes standard avec une petite ressource personnalisée incluse qui pointe vers un espace de noms parent (facultatif). Cela étend le concept de propriété aux espaces de noms eux - mêmes , pas seulement les objets dans eux.
Le concept de propriété met également en œuvre deux types de relations supplémentaires:
- : namespace' . : subnamespaces, .
Cela résout les deux problèmes d'une équipe de développement typique. L'administrateur du cluster peut créer un espace «racine» pour celui-ci avec les stratégies nécessaires et déléguer le pouvoir de créer des sous-espaces aux membres de l'équipe. De cette façon, les développeurs peuvent créer des sous-espaces de noms pour leur propre usage sans enfreindre les stratégies définies par les administrateurs de cluster.
Un peu de pratique
Les espaces de noms hiérarchiques sont implémentés à l'aide d'une extension Kubernetes appelée Hierarchical Namespace Controller ou HNC . HNC se compose de deux composants:
- Manager fonctionne dans un cluster, gère les sous-espaces de noms, distribue les objets de stratégie, s'assure que les hiérarchies sont valides et gère les points d'extension.
- Un plugin kubectl appelé
kubectl-hnsil permet aux utilisateurs d'interagir avec le gestionnaire.
Le guide d'installation des composants se trouve sur la page des versions dans le référentiel du projet.
Jetons un coup d'œil au fonctionnement de HNC. Supposons que je n'ai pas de privilèges pour créer des espaces de noms, mais que je puisse parcourir l'espace de noms
team-aet y créer des sous- espaces de noms *. Le plugin me permet de saisir la commande suivante:
$ kubectl hns create svc1-team-a -n team-a
* Techniquement parlant, vous créez un petit objet appelé «ancre de sous-espace de nom» dans l'espace parent, puis HNC crée un sous-espace de nom.
Cela créera un espace de noms
svc1-team-a. Veuillez noter que les sous-espaces de noms ne sont pas différents des espaces de noms Kubernetes classiques, leurs noms doivent donc être uniques.
Vous pouvez afficher la structure résultante à l'aide de la commande
tree:
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
S'il y a des politiques dans l'espace parent, elles seront copiées dans l'enfant *. Par exemple, supposons que vous
team-aayez appelé un RoleBinding RBAC sres. Ce RoleBinding apparaîtra également dans l'espace de noms correspondant:
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
* Par défaut, seuls les rôles et les liaisons de rôle dans RBAC sont redistribués, mais vous pouvez configurer HNC pour propager n'importe quel objet Kubernetes.
Enfin, HNC ajoute des étiquettes à ces espaces de noms avec des informations utiles sur la hiérarchie. Ils peuvent être utilisés pour appliquer d'autres politiques. Par exemple, vous pouvez créer la NetworkPolicy suivante:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
Cette stratégie sera propagée aux descendants
team-aet autorisera également le trafic entrant entre tous ces espaces de noms. Seul HNC peut attribuer l'étiquette «arbre». Il est garanti de refléter la hiérarchie actuelle.
Vous trouverez des détails sur la fonctionnalité HNC dans le manuel de l'utilisateur .
Prochaines étapes et participation au processus
Si vous pensez que l'espace de noms hiérarchique est utile dans votre organisation, la version HNC v0.5.1 est disponible sur GitHub (disponible du 28 août à la version v0.5.2 - ca. Perevi ..) . Nous aimerions savoir ce que vous en pensez, quels problèmes vous résolvez et quelles fonctionnalités vous aimeriez y ajouter. Comme pour tout logiciel aux premiers stades de développement, il faut faire attention lors de l'utilisation de HNC en production. Et plus nous recevons de commentaires, plus vite nous pouvons arriver à HNC 1.0.
Nous apprécions également les contributions de contributeurs tiers, qu'il s'agisse de corrections de bogues / d'informations les concernant ou d'aide au prototypage de nouvelles fonctionnalités telles que des exceptions, une surveillance améliorée, des devis de ressources hiérarchiques ou une optimisation de la configuration.
Vous pouvez nous contacter dans le référentiel , la liste de diffusion ou Slack . Nous attendons vos commentaires avec impatience!
L'annonce originale a été faite par Adrian Ludwin , ingénieur logiciel et responsable technique pour le contrôleur d'espace de noms hiérarchique.
Prime! Feuille de route et problèmes
Veuillez publier des problèmes - plus il y en a, plus c'est amusant! Les bogues seront analysés en premier et les demandes de fonctionnalités seront priorisées, après quoi elles seront incluses dans le plan de travail ou le backlog.
HNC n'a pas encore atteint le statut GA, soyez donc prudent lorsque vous l'utilisez sur des clusters avec des objets de configuration que vous ne pouvez pas vous permettre de perdre (par exemple, ceux qui ne sont pas stockés dans un référentiel Git).
Toutes les questions HNC sont incluses dans le plan de travail correspondant. À l'heure actuelle, les principales étapes suivantes de ce plan ont été mises en œuvre ou planifiées:
- v1.0: fin I - début II trimestre 2021; HNC est recommandé pour la production.
- v0.8: début 2021; de nouvelles fonctions critiques peuvent apparaître.
- v0.7: fin 2020; probablement l'API v1beta1 apparaîtra.
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
PS du traducteur
Lisez aussi sur notre blog: