Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Isolement des locataires
Lorsque nous pensons à la mutualisation, nous voulons souvent isoler un utilisateur ou une application des autres utilisateurs ou des applications exécutées sur une infrastructure partagée.
Kubernetes est un orchestrateur à locataire unique, c'est-à-dire qu'une seule instance du plan de contrôle est partagée entre tous les locataires d'un cluster. Il existe cependant différents objets Kubernetes que vous pouvez utiliser pour créer un semblant de mutualisation. Par exemple, les espaces de noms et les contrôles d'accès basés sur les rôles (RBAC) peuvent être mis en œuvre pour isoler logiquement les locataires les uns des autres. De même, les quotas et les plages de limites peuvent être utilisés pour contrôler la quantité de ressources du cluster que chaque locataire peut consommer. Néanmoins, le cluster est la seule construction qui fournit une limite de sécurité solide. En effet, un attaquant qui parvient à accéder à un hôte au sein du cluster peut récupérer tous ConfigMaps les secrets et volumes montés sur cet hôte. Ils pourraient également se faire passer pour le Kubelet, ce qui leur permettrait de manipuler les attributs du nœud et de and/or se déplacer latéralement au sein du cluster.
Les sections suivantes expliquent comment implémenter l'isolation des locataires tout en atténuant les risques liés à l'utilisation d'un seul orchestrateur de locataires tel que Kubernetes.
Multi-location souple
Avec la mutualisation souple, vous utilisez des structures Kubernetes natives, par exemple des espaces de noms, des rôles et des liaisons de rôles, ainsi que des politiques réseau, pour créer une séparation logique entre les locataires. Le RBAC, par exemple, peut empêcher les locataires d'accéder aux ressources des autres ou de les manipuler. Les quotas et les plages de limites contrôlent la quantité de ressources du cluster que chaque locataire peut consommer, tandis que les politiques réseau peuvent empêcher les applications déployées dans différents espaces de noms de communiquer entre elles.
Aucun de ces contrôles n'empêche toutefois les pods de différents locataires de partager un nœud. Si une isolation renforcée est requise, vous pouvez utiliser un sélecteur de nœuds, des règles anti-affinité, des and/or contraintes et des tolérances pour obliger les pods de différents locataires à être planifiés sur des nœuds distincts, souvent appelés nœuds à locataire unique. Cela peut devenir assez compliqué et coûteux dans un environnement comptant de nombreux locataires.
Important
La mutualisation souple mise en œuvre avec les espaces de noms ne vous permet pas de fournir aux locataires une liste filtrée d'espaces de noms, car les espaces de noms sont un type à portée globale. Si un locataire a la possibilité de consulter un espace de noms particulier, il peut afficher tous les espaces de noms du cluster.
Avertissement
Avec soft-multi-tenancy, les locataires conservent la possibilité d'interroger CoreDNS pour tous les services exécutés par défaut au sein du cluster. Un attaquant pourrait exploiter cela en exécutant dig SRV
..svc.cluster.local à partir de n'importe quel pod du cluster. Si vous devez restreindre l'accès aux enregistrements DNS des services exécutés au sein de vos clusters, pensez à utiliser les plug-ins Firewall ou Policy pour CoreDNS. Pour plus d'informations, consultez https://github.com/coredns/policy# kubernetes-metadata-multi-tenancy -policy.
Kiosk
-
Comptes et utilisateurs de comptes pour séparer les locataires d'un cluster Kubernetes partagé
-
Provisionnement d'espaces de noms en libre-service pour les utilisateurs du compte
-
Limites de compte pour garantir la qualité de service et l'équité lors du partage d'un cluster
-
Modèles d'espaces de noms pour l'isolation sécurisée des locataires et l'initialisation d'espaces de noms en libre-service
Loft
-
Accès multi-clusters pour accorder l'accès aux espaces de différents clusters
-
Le mode veille réduit les déploiements dans un espace pendant les périodes d'inactivité
-
Authentification unique avec des fournisseurs d'authentification OIDC tels que GitHub
Trois principaux cas d'utilisation peuvent être traités par la mutualisation souple.
Cadre d'entreprise
Le premier est dans un environnement d'entreprise où les « locataires » sont semi-fiables dans la mesure où ils sont des employés, des sous-traitants ou qu'ils sont autrement autorisés par l'organisation. Chaque locataire s'alignera généralement sur une division administrative telle qu'un département ou une équipe.
Dans ce type de configuration, un administrateur de cluster est généralement chargé de créer des espaces de noms et de gérer les politiques. Ils peuvent également mettre en œuvre un modèle d'administration déléguée dans lequel certaines personnes sont chargées de superviser un espace de noms, leur permettant d'effectuer des opérations CRUD pour des objets non liés aux politiques, tels que des déploiements, des services, des modules, des tâches, etc.
L'isolation fournie par l'environnement d'exécution d'un conteneur peut être acceptable dans ce paramètre ou il peut être nécessaire de la renforcer par des contrôles supplémentaires pour la sécurité du pod. Il peut également être nécessaire de restreindre la communication entre les services de différents espaces de noms si une isolation plus stricte est requise.
Kubernetes en tant que service
En revanche, la mutualisation souple peut être utilisée dans les environnements où vous souhaitez proposer Kubernetes en tant que service (KaaS). Avec le KaaS, votre application est hébergée dans un cluster partagé avec un ensemble de contrôleurs CRDs fournissant un ensemble de services PaaS. Les locataires interagissent directement avec le serveur d'API Kubernetes et sont autorisés à effectuer des opérations CRUD sur des objets non liés aux politiques. Il existe également un élément de libre-service dans la mesure où les locataires peuvent être autorisés à créer et à gérer leurs propres espaces de noms. Dans ce type d'environnement, les locataires sont supposés exécuter du code non fiable.
Pour isoler les locataires dans ce type d'environnement, vous devrez probablement mettre en œuvre des politiques réseau strictes ainsi que le sandboxing des pods. Le sandboxing consiste à exécuter les conteneurs d'un pod dans une micro-machine virtuelle telle que Firecracker ou dans un noyau d'espace utilisateur. Aujourd'hui, vous pouvez créer des pods en bac à sable avec EKS Fargate.
Logiciel en tant que service (SaaS)
Le dernier cas d'utilisation de la mutualisation souple se situe dans un environnement ( Software-as-a-ServiceSaaS). Dans cet environnement, chaque locataire est associé à une instance particulière d'une application exécutée au sein du cluster. Chaque instance possède souvent ses propres données et utilise des contrôles d'accès distincts qui sont généralement indépendants du RBAC de Kubernetes.
Contrairement aux autres cas d'utilisation, le locataire d'un environnement SaaS n'interagit pas directement avec l'API Kubernetes. L'application SaaS est plutôt chargée de l'interfaçage avec l'API Kubernetes afin de créer les objets nécessaires pour prendre en charge chaque locataire.
Constructions Kubernetes
Dans chacun de ces cas, les constructions suivantes sont utilisées pour isoler les locataires les uns des autres :
Espaces de noms
Les espaces de noms sont essentiels à la mise en œuvre de la mutualisation souple. Ils vous permettent de diviser le cluster en partitions logiques. Les quotas, les politiques réseau, les comptes de service et les autres objets nécessaires à la mise en œuvre de la mutualisation sont limités à un espace de noms.
Stratégies réseau
Par défaut, tous les pods d'un cluster Kubernetes sont autorisés à communiquer entre eux. Ce comportement peut être modifié à l'aide de politiques réseau.
Les politiques réseau limitent la communication entre les pods à l'aide d'étiquettes ou de plages d'adresses IP. Dans un environnement multi-tenant où une isolation réseau stricte entre les locataires est requise, nous recommandons de commencer par une règle par défaut qui refuse la communication entre les pods, et une autre règle qui autorise tous les pods à interroger le serveur DNS pour la résolution de noms. Une fois cela en place, vous pouvez commencer à ajouter des règles plus permissives qui permettent la communication au sein d'un espace de noms. Cela peut être affiné selon les besoins.
Note
Amazon VPC CNI prend désormais en charge les politiques réseau Kubernetes afin de créer des politiques
Important
Les politiques de réseau sont nécessaires mais ne sont pas suffisantes. L'application des politiques réseau nécessite un moteur de politiques tel que Calico ou Cilium.
Contrôle d’accès basé sur les rôles (RBAC)
Les rôles et les liaisons de rôles sont les objets Kubernetes utilisés pour appliquer le contrôle d'accès basé sur les rôles (RBAC) dans Kubernetes. Les rôles contiennent des listes d'actions qui peuvent être effectuées sur des objets de votre cluster. Les liaisons de rôles spécifient les individus ou les groupes auxquels les rôles s'appliquent. Dans les paramètres d'entreprise et KaaS, le RBAC peut être utilisé pour permettre l'administration d'objets par des groupes ou des individus sélectionnés.
Quotas
Les quotas sont utilisés pour définir les limites des charges de travail hébergées dans votre cluster. Avec les quotas, vous pouvez spécifier la quantité maximale de processeur et de mémoire qu'un pod peut consommer, ou vous pouvez limiter le nombre de ressources pouvant être allouées dans un cluster ou un espace de noms. Les plages de limites vous permettent de déclarer des valeurs minimales, maximales et par défaut pour chaque limite.
Il est souvent avantageux de surengager des ressources dans un cluster partagé, car cela vous permet de maximiser vos ressources. Cependant, un accès illimité à un cluster peut entraîner une privation de ressources, ce qui peut entraîner une dégradation des performances et une perte de disponibilité des applications. Si les demandes d'un pod sont définies à un niveau trop faible et que l'utilisation réelle des ressources dépasse la capacité du nœud, le nœud commencera à subir une pression sur le processeur ou la mémoire. Dans ce cas, les pods peuvent être redémarrés et and/or expulsés du nœud.
Pour éviter que cela ne se produise, vous devez prévoir d'imposer des quotas sur les espaces de noms dans un environnement multi-locataires afin de forcer les locataires à spécifier des demandes et des limites lors de la planification de leurs pods sur le cluster. Cela permettra également d'atténuer un éventuel déni de service en limitant la quantité de ressources qu'un pod peut consommer.
Vous pouvez également utiliser des quotas pour répartir les ressources du cluster afin de les aligner sur les dépenses du locataire. Cela est particulièrement utile dans le scénario KaaS.
Priorité et préemption des pods
La priorité et la préemption des pods peuvent être utiles lorsque vous souhaitez accorder plus d'importance à un pod par rapport aux autres pods. Par exemple, avec la priorité des pods, vous pouvez configurer les pods du client A pour qu'ils fonctionnent avec une priorité plus élevée que le client B. Lorsque la capacité disponible est insuffisante, le planificateur expulse les pods les moins prioritaires du client B pour accueillir les pods les plus prioritaires du client A. Cela peut être particulièrement pratique dans un environnement SaaS où les clients prêts à payer un supplément reçoivent une priorité plus élevée.
Important
La priorité des pods peut avoir un effet indésirable sur les autres pods moins prioritaires. Par exemple, bien que les modules concernés soient résiliés gracieusement mais que cela ne PodDisruptionBudget soit pas garanti, cela pourrait endommager une application de moindre priorité qui dépend d'un quorum de pods, voir Limitations de préemption
Contrôles d'atténuation
En tant qu'administrateur d'un environnement mutualisé, votre principale préoccupation est d'empêcher un attaquant d'accéder à l'hôte sous-jacent. Les contrôles suivants doivent être envisagés pour atténuer ce risque :
Environnements d'exécution en sandbox pour les conteneurs
Le sandboxing est une technique par laquelle chaque conteneur est exécuté sur sa propre machine virtuelle isolée. Les technologies qui permettent de réaliser le sandboxing en nacelle incluent Firecracker
Agent de politique ouverte (OPA) et contrôleur d'accès
Gatekeeper
Il existe également un plugin OPA expérimental pour CoreDNS
Kyverno
Kyverno
Vous pouvez utiliser Kyverno pour isoler les espaces de noms, renforcer la sécurité des pods et appliquer d'autres bonnes pratiques, et générer des configurations par défaut telles que des politiques réseau. Plusieurs exemples sont inclus dans le GitHub référentiel
Isolation des charges de travail des locataires sur des nœuds spécifiques
Le fait de restreindre les charges de travail des locataires pour qu'elles s'exécutent sur des nœuds spécifiques peut être utilisé pour renforcer l'isolation dans le modèle de mutualisation souple. Avec cette approche, les charges de travail spécifiques aux locataires ne sont exécutées que sur des nœuds provisionnés pour les locataires respectifs. Pour obtenir cette isolation, les propriétés natives de Kubernetes (affinité des nœuds, contraintes et tolérances) sont utilisées pour cibler des nœuds spécifiques pour la planification des pods et empêcher les pods, provenant d'autres locataires, d'être planifiés sur les nœuds spécifiques aux locataires.
Partie 1 - Affinité des nœuds
L'affinité des nœudsrequiredDuringSchedulingIgnoredDuringExecution nœuds est appliquée au pod correspondant. Le résultat est que le pod ciblera les nœuds étiquetés avec la clé/valeur suivante :. node-restriction.kubernetes.io/tenant: tenants-x
... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-restriction.kubernetes.io/tenant operator: In values: - tenants-x ...
Avec cette affinité de nœud, l'étiquette est requise lors de la planification, mais pas pendant l'exécution ; si les étiquettes des nœuds sous-jacents changent, les pods ne seront pas expulsés uniquement en raison de ce changement d'étiquette. Cependant, la planification future pourrait être affectée.
Avertissement
Le préfixe d'étiquette node-restriction.kubernetes.io/ a une signification particulière dans Kubernetes. NodeRestrictionkubelet empêche adding/removing/updating les étiquettes comportant ce préfixe. Les attaquants ne peuvent pas utiliser le kubelet’s credentials to update the node object or modify the system setup to pass these labels into `kubelet car ils kubelet ne sont pas autorisés à modifier ces étiquettes. Si ce préfixe est utilisé pour toute la planification entre un pod et un nœud, il permet d'éviter les scénarios dans lesquels un attaquant pourrait vouloir attirer un ensemble différent de charges de travail vers un nœud en modifiant les étiquettes des nœuds.
Au lieu de l'affinité des nœuds, nous aurions pu utiliser le sélecteur de nœuds
Partie 2 - Taches et tolérances
Attirer les pods vers les nœuds n'est que la première partie de cette approche en trois parties. Pour que cette approche fonctionne, nous devons empêcher les pods de planifier sur des nœuds pour lesquels les pods ne sont pas autorisés. Pour repousser les pods indésirables ou non autorisés, Kubernetes utilise des nœuds souillés.tenant: tenants-x
... taints: - key: tenant value: tenants-x effect: NoSchedule ...
Compte tenu du nœud ci-dessustaint, seuls les pods qui tolèrent cette odeur seront autorisés à être planifiés sur le nœud. Pour permettre de programmer des pods autorisés sur le nœud, les spécifications des pods respectifs doivent inclure un toleration point de contact, comme indiqué ci-dessous.
... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
Les pods présentant les caractéristiques ci-dessus ne toleration seront pas empêchés de planifier sur le nœud, du moins pas à cause de cette odeur spécifique. Kubernetes utilise également Taints pour arrêter temporairement la planification des pods dans certaines conditions, telles que la pression sur les ressources des nœuds. Grâce à l'affinité des nœuds, aux taches et aux tolérances, nous pouvons attirer efficacement les pods souhaités vers des nœuds spécifiques et repousser les pods indésirables.
Important
Certains pods Kubernetes sont nécessaires pour fonctionner sur tous les nœuds. Des exemples de ces pods sont ceux démarrés par le Container Network Interface (CNI)
Partie 3 - Gestion basée sur des politiques pour la sélection des nœuds
Plusieurs outils peuvent être utilisés pour aider à gérer l'affinité des nœuds et les tolérances des spécifications des pods, y compris l'application des règles dans les pipelines CICD. Cependant, l'application de l'isolation doit également être effectuée au niveau du cluster Kubernetes. À cette fin, les outils de gestion des politiques peuvent être utilisés pour modifier les demandes entrantes du serveur d'API Kubernetes, en fonction des charges utiles des demandes, afin d'appliquer les règles d'affinité des nœuds et les tolérances respectives mentionnées ci-dessus.
Par exemple, les pods destinés à l'espace de noms tenants-x peuvent être estampillés avec l'affinité et la tolérance de nœuds correctes afin de permettre la planification sur les nœuds tenants-x. À l'aide des outils de gestion des politiques configurés à l'aide du Kubernetes Mutating Admission Webhook
apiVersion: mutations.gatekeeper.sh/v1alpha1 kind: Assign metadata: name: mutator-add-nodeaffinity-pod annotations: aws-eks-best-practices/description: >- Adds Node affinity - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity spec: applyTo: - groups: [""] kinds: ["Pod"] versions: ["v1"] match: namespaces: ["tenants-x"] location: "spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms" parameters: assign: value: - matchExpressions: - key: "tenant" operator: In values: - "tenants-x"
La politique ci-dessus est appliquée à une demande du serveur d'API Kubernetes, afin d'appliquer un pod à l'espace de noms tenants-x. La politique ajoute la règle d'affinité des requiredDuringSchedulingIgnoredDuringExecution nœuds, afin que les pods soient attirés par les nœuds portant l'tenant: tenants-xétiquette.
Une deuxième politique, présentée ci-dessous, ajoute la tolérance à la même spécification de pod, en utilisant les mêmes critères de correspondance pour l'espace de noms cible, les groupes, les types et les versions.
apiVersion: mutations.gatekeeper.sh/v1alpha1 kind: Assign metadata: name: mutator-add-toleration-pod annotations: aws-eks-best-practices/description: >- Adds toleration - https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ spec: applyTo: - groups: [""] kinds: ["Pod"] versions: ["v1"] match: namespaces: ["tenants-x"] location: "spec.tolerations" parameters: assign: value: - key: "tenant" operator: "Equal" value: "tenants-x" effect: "NoSchedule"
Les politiques ci-dessus sont spécifiques aux modules ; cela est dû aux chemins d'accès aux éléments mutés dans les éléments des politiques. location Des politiques supplémentaires pourraient être rédigées pour gérer les ressources qui créent des pods, telles que les ressources Deployment et Job. Les politiques répertoriées et d'autres exemples peuvent être consultés dans le GitHubprojet
Le résultat de ces deux mutations est que les gousses sont attirées par le nœud souhaité, sans pour autant être repoussées par l'odeur spécifique du nœud. Pour vérifier cela, nous pouvons voir les extraits de sortie de deux kubectl appels pour obtenir les nœuds étiquetés avec et pour obtenir tenant=tenants-x les pods dans l'tenants-xespace de noms.
kubectl get nodes -l tenant=tenants-x NAME ip-10-0-11-255... ip-10-0-28-81... ip-10-0-43-107... kubectl -n tenants-x get pods -owide NAME READY STATUS RESTARTS AGE IP NODE tenant-test-deploy-58b895ff87-2q7xw 1/1 Running 0 13s 10.0.42.143 ip-10-0-43-107... tenant-test-deploy-58b895ff87-9b6hg 1/1 Running 0 13s 10.0.18.145 ip-10-0-28-81... tenant-test-deploy-58b895ff87-nxvw5 1/1 Running 0 13s 10.0.30.117 ip-10-0-28-81... tenant-test-deploy-58b895ff87-vw796 1/1 Running 0 13s 10.0.3.113 ip-10-0-11-255... tenant-test-pod 1/1 Running 0 13s 10.0.35.83 ip-10-0-43-107...
Comme nous pouvons le voir sur les résultats ci-dessus, tous les pods sont planifiés sur les nœuds étiquetés avectenant=tenants-x. En termes simples, les pods ne fonctionneront que sur les nœuds souhaités, tandis que les autres pods (sans l'affinité et les tolérances requises) ne le feront pas. Les charges de travail des locataires sont efficacement isolées.
Un exemple de spécification de pod muté est présenté ci-dessous.
apiVersion: v1 kind: Pod metadata: name: tenant-test-pod namespace: tenants-x spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: tenant operator: In values: - tenants-x ... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
Important
Les outils de gestion des politiques intégrés au flux de demandes du serveur d'API Kubernetes, à l'aide de webhooks d'admission mutants et validants, sont conçus pour répondre à la demande du serveur d'API dans un délai spécifié. Cette durée est généralement inférieure ou égale à 3 secondes. Si l'appel webhook ne renvoie pas de réponse dans le délai configuré, la and/or validation de la mutation de la demande du serveur d'API entrante peut avoir lieu ou non. Ce comportement dépend du fait que les configurations du webhook d'admission sont définies sur Fail Open ou Fail Close
Dans les exemples ci-dessus, nous avons utilisé des politiques écrites pour OPA/Gatekeeper. Cependant, il existe d'autres outils de gestion des politiques qui gèrent également notre cas d'utilisation de la sélection de nœuds. Par exemple, cette politique Kyverno
Note
Si elles fonctionnent correctement, les politiques mutantes apporteront les modifications souhaitées aux charges utiles des demandes du serveur d'API entrantes. Cependant, des politiques de validation doivent également être incluses pour vérifier que les modifications souhaitées se produisent, avant que les modifications ne soient autorisées à persister. Cela est particulièrement important lorsque vous utilisez ces politiques à des fins tenant-to-node d'isolation. Il est également conseillé d'inclure des politiques d'audit pour vérifier régulièrement la présence de configurations indésirables dans votre cluster.
Références
-
k-rail
Conçu pour vous aider à sécuriser un environnement multi-locataires grâce à l'application de certaines politiques. -
Pratiques de sécurité pour les applications MultiTenant SaaS utilisant Amazon EKS
Multi-location rigide
La mutualisation stricte peut être mise en œuvre en provisionnant des clusters distincts pour chaque locataire. Bien que cela assure un très fort isolement entre les locataires, cela présente plusieurs inconvénients.
Tout d'abord, lorsque vous avez de nombreux locataires, cette approche peut rapidement devenir coûteuse. Non seulement vous devrez payer les coûts du plan de contrôle pour chaque cluster, mais vous ne pourrez pas partager les ressources de calcul entre les clusters. Cela finira par provoquer une fragmentation dans laquelle un sous-ensemble de vos clusters sera sous-utilisé tandis que d'autres seront surutilisés.
Ensuite, vous devrez probablement acheter ou créer des outils spéciaux pour gérer tous ces clusters. Avec le temps, la gestion de centaines ou de milliers de clusters peut tout simplement devenir trop complexe.
Enfin, la création d'un cluster par locataire sera lente par rapport à la création d'un espace de noms. Néanmoins, une approche de location rigide peut être nécessaire dans les secteurs hautement réglementés ou dans les environnements SaaS où une forte isolation est requise.
Orientations futures
La communauté Kubernetes a reconnu les lacunes actuelles de la mutualisation souple et les défis liés à la mutualisation stricte. Le Multi-Tenancy Special Interest Group (SIG)
La proposition HNC (KEP) décrit un moyen de créer des relations parent-enfant entre les espaces de noms grâce à l'héritage d'objets [policy] ainsi qu'à la possibilité pour les administrateurs locataires de créer des sous-espaces de noms.
La proposition de cluster virtuel décrit un mécanisme permettant de créer des instances distinctes des services du plan de contrôle, y compris le serveur d'API, le gestionnaire de contrôleurs et le planificateur, pour chaque locataire du cluster (également connu sous le nom de « Kubernetes on Kubernetes »).
La proposition Multi-Tenancy Benchmarks
Outils et ressources de gestion multi-clusters
