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.

Isolation des locataires

Lorsque nous pensons à la mutualisation, nous souhaitons souvent isoler un utilisateur ou une application des autres utilisateurs ou applications exécutés 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 toutefois différents objets Kubernetes que vous pouvez utiliser pour créer un semblant de mutualisation. Par exemple, des espaces de noms et des contrôles Role-based d'accès (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 de cluster que chaque locataire peut consommer. Néanmoins, le cluster est la seule structure qui fournit une limite de sécurité solide. En effet, un attaquant qui parvient à accéder à un hôte du cluster peut récupérer tous les ConfigMaps 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 and/or déplacement latéral du nœud 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 orchestrateur de locataires unique tel que Kubernetes.

Multilocation souple

Avec la multitenancy souple, vous utilisez des constructions 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 de 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.

Cependant, aucun de ces contrôles n'empêche 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 d'anti-affinité, and/or des nuances et des tolérances pour forcer les pods de différents locataires à être planifiés sur des nœuds distincts, souvent appelés nœuds à locataire unique. Cela pourrait devenir assez compliqué et coûter trop cher dans un environnement comptant de nombreux locataires.

Kiosk est un projet open source qui peut aider à la mise en œuvre de la mutualisation logicielle. Il est implémenté sous la forme d'une série de CRD et de contrôleurs offrant les fonctionnalités suivantes :

Loft est une offre commerciale des responsables de Kiosk DevSpace qui ajoute les fonctionnalités suivantes :

Il existe trois principaux cas d'utilisation qui peuvent être résolus par le soft multi-tenancy.

Configuration d'entreprise

La première se situe dans un environnement d'entreprise où les « locataires » sont semi-fiables dans la mesure où ils sont des employés, des sous-traitants ou 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 responsable de la création des espaces de noms et de la gestion des politiques. Ils peuvent également implémenter un modèle d'administration déléguée dans lequel certaines personnes sont chargées de superviser un espace de noms, ce qui leur permet d'effectuer des opérations CRUD pour des objets non liés à la politique tels que des déploiements, des services, des pods, des tâches, etc.

L'isolation fournie par un environnement d'exécution de conteneur peut être acceptable dans ce paramètre ou elle peut devoir être renforcée par des contrôles supplémentaires pour la sécurité des pods. Il peut également être nécessaire de restreindre la communication entre les services dans différents espaces de noms si une isolation plus stricte est requise.

Kubernetes en tant que service

En revanche, la mutualisation logicielle peut être utilisée dans les paramètres où vous souhaitez proposer Kubernetes en tant que service (KaaS). Avec KaaS, votre application est hébergée dans un cluster partagé avec un ensemble de contrôleurs et de CRD qui fournissent un ensemble de services PaaS. Les locataires interagissent directement avec le serveur API Kubernetes et sont autorisés à effectuer des opérations CRUD sur des objets ne relevant pas de la politique. 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 en espace utilisateur. Aujourd'hui, vous pouvez créer des modules en bac à sable avec EKS Fargate.

Logiciel en tant que service (SaaS)

Le dernier cas d'utilisation de la mutualisation logicielle se situe dans un environnement Software-as-a-Service (SaaS). Dans cet environnement, chaque locataire est associé à une instance particulière d'une application qui s'exécute 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 de Kubernetes RBAC.

Contrairement aux autres cas d'utilisation, le locataire dans un environnement SaaS n'interagit pas directement avec l'API Kubernetes. L'application SaaS est plutôt chargée de l'interface avec l'API Kubernetes afin de créer les objets nécessaires à la prise en charge de chaque locataire.

Constructions Kubernetes

Dans chacun de ces cas, les concepts suivants sont utilisés pour isoler les locataires les uns des autres :

Espaces de noms

Les espaces de noms sont essentiels à la mise en œuvre de la mutualisation logicielle. 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 multilocation 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 des 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-locataires où une isolation réseau stricte entre les locataires est requise, nous vous recommandons de commencer par une règle par défaut qui interdit la communication entre les espaces, et une autre règle qui autorise tous les espaces à interroger le serveur DNS pour la résolution des 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é davantage si nécessaire.

Role-based contrôle d'accès (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 les objets de votre cluster. Les attributions de rôles indiquent les personnes ou les groupes auxquels les rôles s'appliquent. Dans les paramètres d'entreprise et KaaS, le RBAC peut être utilisé pour autoriser 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. Les quotas vous permettent de limiter la quantité totale de CPU et de mémoire pouvant être consommée dans un espace de noms, ou de limiter le nombre d'objets pouvant être créés. Les plages limites vous permettent de déclarer les valeurs minimales, maximales et par défaut du processeur et de la mémoire pour les pods et les conteneurs individuels au sein d'un espace de noms.

L'utilisation excessive de ressources dans un cluster partagé est souvent bénéfique car cela vous permet de maximiser vos ressources. Cependant, l'accès illimité à un cluster peut entraîner une pénurie 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 trop bas et que l'utilisation réelle des ressources dépasse la capacité du nœud, celui-ci 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 aux espaces de noms dans un environnement multi-tenant afin de forcer les locataires à spécifier des demandes et des limites lors de la planification de leurs espaces 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 en fonction des 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 donner plus d'importance à un pod par rapport aux autres pods. Par exemple, avec la priorité aux modules, vous pouvez configurer les modules du client A pour qu'ils soient exécutés avec une priorité plus élevée que celle du client B. Lorsque la capacité disponible est insuffisante, le planificateur expulse les modules les moins prioritaires du client B pour accueillir les modules les plus prioritaires du client A. Cela peut être particulièrement pratique dans un environnement SaaS où les clients prêts à payer une prime reçoivent une priorité plus élevée.

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 bac à sable pour les conteneurs

Le sandboxing est une technique qui permet d'exécuter chaque conteneur dans sa propre machine virtuelle isolée. Les technologies qui permettent d'effectuer le sandboxing des pods incluent Firecracker.

Pour plus d'informations sur les efforts déployés pour faire de Firecracker un environnement d'exécution compatible pour EKS, voir https://threadreaderapp.com/thread/1238496944684597248.html.

Contrôleur d'accès Open Policy Agent (OPA) &

Gatekeeper est un contrôleur d'admission Kubernetes qui applique les politiques créées avec OPA. https://www.openpolicyagent.org/ Avec OPA, vous pouvez créer une politique qui gère les pods des locataires sur des instances distinctes ou avec une priorité plus élevée que celle des autres locataires. Une collection de politiques OPA courantes se trouve dans le GitHub référentiel de ce projet.

Il existe également un plugin OPA expérimental pour CoreDNS qui vous permet d'utiliser OPA pour les enregistrements renvoyés par CoreDNS. filter/control

Kyverno

Kyverno est un moteur de politiques natif de Kubernetes qui peut valider, muter et générer des configurations avec des politiques en tant que ressources Kubernetes. Kyverno utilise des Kustomize-style superpositions pour la validation, prend en charge le correctif JSON et le correctif de fusion stratégique pour la mutation, et peut cloner des ressources dans des espaces de noms sur la base de déclencheurs flexibles.

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 de ce projet. De nombreuses autres sont incluses dans la bibliothèque des politiques du site Web de Kyverno.

Isoler les charges de travail des locataires sur des nœuds spécifiques

La restriction des charges de travail des locataires à exécuter sur des nœuds spécifiques peut être utilisée pour renforcer l'isolation dans le modèle multi-tenant 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 réaliser cette isolation, les propriétés natives de Kubernetes (affinité des nœuds, ainsi que les limites et tolérances) sont utilisées pour cibler des nœuds spécifiques pour la planification des pods et empêcher que des pods provenant d'autres locataires ne soient planifiés sur les nœuds spécifiques au locataire.

Partie 1 - Affinité des nœuds

L'affinité des nœuds Kubernetes est utilisée pour cibler les nœuds à des fins de planification, en fonction des étiquettes des nœuds. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ Avec les règles d'affinité des nœuds, les pods sont attirés par des nœuds spécifiques qui correspondent aux termes du sélecteur. Dans la spécification de pod ci-dessous, l'affinité de requiredDuringSchedulingIgnoredDuringExecution nœud est appliquée au pod correspondant. Le résultat est que le pod ciblera les nœuds étiquetés comme suit key/value :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 à cause de ce changement d'étiquette. Cependant, la programmation future pourrait être affectée.

Partie 2 - Nuances 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 traces de nœuds. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Les failles sont utilisées pour placer des conditions sur les nœuds qui empêchent la planification des pods. La couleur ci-dessous utilise une paire clé-valeur de. tenant: tenants-x

...
    taints:
      - key: tenant
        value: tenants-x
        effect: NoSchedule
...

Compte tenu du nœud ci-dessustaint, seuls les pods qui tolèrent l'altération seront autorisés à être planifiés sur le nœud. Pour permettre la planification des pods autorisés sur le nœud, les spécifications respectives des pods doivent inclure un élément toleration à l'entache, comme indiqué ci-dessous.

...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

La planification des pods présentant les caractéristiques ci-dessus ne toleration sera pas empêchée sur le nœud, du moins pas à cause de cette caractéristique spécifique. Les failles sont également utilisées par Kubernetes 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 couleurs et aux tolérances, nous pouvons attirer efficacement les pods souhaités vers des nœuds spécifiques et repousser les pods indésirables.

Partie 3 : Policy-based gestion de 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, notamment l'application de règles dans les pipelines CICD. Cependant, l'application de l'isolation doit également être effectuée au niveau du cluster Kubernetes. À cette fin, des outils de gestion des politiques peuvent être utilisés pour muter les requêtes 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œud correctes pour permettre la planification sur les nœuds tenants-x. À l'aide d'outils de gestion des politiques configurés à l'aide du Webhook Kubernetes Mutating Admission, les politiques peuvent être utilisées pour modifier les spécifications des pods entrants. Les mutations ajoutent les éléments nécessaires pour permettre la planification souhaitée. Un exemple OPA/Gatekeeper de politique qui ajoute une affinité de nœud est présenté ci-dessous.

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 de serveur API Kubernetes, pour appliquer un pod à l'espace de noms tenants-x. La politique ajoute la règle d'affinité des requiredDuringSchedulingIgnoredDuringExecution nœuds, de sorte 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 d'espace de noms cible et de groupes, de types et de 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 pods ; cela est dû aux chemins vers les éléments mutés dans les éléments des politiques. location Des politiques supplémentaires pourraient être écrites pour gérer les ressources qui créent des pods, telles que les ressources de déploiement et de travail. Les politiques répertoriées et d'autres exemples peuvent être consultés dans le GitHub projet complémentaire de ce guide.

Le résultat de ces deux mutations est que les gousses sont attirées par le nœud souhaité, tout en n'étant pas 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 et obtenir les tenant=tenants-x 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 sorties 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, mais pas les autres pods (sans l'affinité et les tolérances requises). 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
...

Dans les exemples ci-dessus, nous avons utilisé des politiques rédigées pour OPA/Gatekeeper. Cependant, il existe d'autres outils de gestion des politiques qui gèrent également notre cas d'utilisation de sélection de nœuds. Par exemple, cette politique Kyverno pourrait être utilisée pour gérer la mutation d'affinité des nœuds.

Références

Multilocation stricte

La multilocation matérielle peut être mise en œuvre en provisionnant des clusters distincts pour chaque locataire. Bien que cela assure une isolation très forte entre les locataires, cela présente plusieurs inconvénients.

Tout d'abord, lorsque vous avez de nombreux locataires, cette approche peut vite 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 entraîner une fragmentation dans laquelle un sous-ensemble de vos clusters est sous-utilisé tandis que d'autres sont surutilisés.

Deuxièmement, 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 stricte 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 multilocation stricte. Le Multi-Tenancy Special Interest Group (SIG) tente de remédier à ces lacunes par le biais de plusieurs projets d'incubation, notamment le Hierarchical Namespace Controller (HNC) et le Virtual Cluster.

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 que la possibilité pour les administrateurs de 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 fournit des directives pour le partage de clusters à l'aide d'espaces de noms pour l'isolation et la segmentation, ainsi qu'un outil en ligne de commande kubectl-mtb pour valider la conformité aux directives.

Multi-cluster outils et ressources de gestion