Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Isolierung von Mandanten Wenn wir an Mehrmandantenfähigkeit denken, wollen wir oft einen Benutzer oder eine Anwendung von anderen Benutzern oder Anwendungen isolieren, die auf einer gemeinsam genutzten Infrastruktur ausgeführt werden. Kubernetes ist ein * Single-Tenant-Orchestrator*, d. h. eine einzelne Instanz der Steuerungsebene wird von allen Mandanten innerhalb eines Clusters gemeinsam genutzt. Es gibt jedoch verschiedene Kubernetes-Objekte, mit denen Sie den Anschein einer Mehrmandantenfähigkeit erwecken können. Beispielsweise können Namespaces und Role-based Zugriffskontrollen (RBAC) implementiert werden, um Mandanten logisch voneinander zu isolieren. In ähnlicher Weise können Kontingente und Grenzbereiche verwendet werden, um die Menge an Clusterressourcen zu steuern, die jeder Mandant verbrauchen kann. Dennoch ist der Cluster das einzige Konstrukt, das eine starke Sicherheitsgrenze bietet. Dies liegt daran, dass ein Angreifer, der Zugriff auf einen Host innerhalb des Clusters erlangt, * alle * Secrets und Volumes abrufen kannConfigMaps, die auf diesem Host gemountet sind. Sie könnten sich auch als Kubelet ausgeben, was es ihnen ermöglichen würde, die Attribute des Knotens zu manipulieren, der sich seitlich innerhalb des Clusters and/or bewegt. In den folgenden Abschnitten wird erklärt, wie Sie die Mandantenisolierung implementieren und gleichzeitig die Risiken mindern, die mit der Verwendung eines Single-Tenant-Orchestrators wie Kubernetes verbunden sind. ## Weiche Mehrmandantenfähigkeit Bei der weichen Mehrmandantenfähigkeit verwenden Sie native Kubernetes-Konstrukte, z. B. Namespaces, Rollen und Rollenbindungen sowie Netzwerkrichtlinien, um eine logische Trennung zwischen den Mandanten herzustellen. RBAC kann beispielsweise verhindern, dass Mandanten auf die Ressourcen des jeweils anderen zugreifen oder sich gegenseitig manipulieren. Kontingente und Grenzbereiche steuern die Menge an Clusterressourcen, die jeder Mandant verbrauchen kann, während Netzwerkrichtlinien dazu beitragen können, zu verhindern, dass Anwendungen, die in verschiedenen Namespaces bereitgestellt werden, miteinander kommunizieren. Keine dieser Steuerungen verhindert jedoch, dass Pods verschiedener Mandanten einen Knoten gemeinsam nutzen. Wenn eine stärkere Isolierung erforderlich ist, können Sie eine Knotenauswahl, Anti-Affinitätsregeln, and/or Taints und Toleranzen verwenden, um zu erzwingen, dass Pods verschiedener Mandanten auf separaten Knoten geplant werden. Diese werden oft als * Knoten für einzelne Mandanten bezeichnet. * In einer Umgebung mit vielen Mandanten könnte dies ziemlich kompliziert und unerschwinglich werden. **Wichtig** Die mit Namespaces implementierte Soft-Multi-Tenancy ermöglicht es Ihnen nicht, Mandanten eine gefilterte Liste von Namespaces zur Verfügung zu stellen, da es sich bei Namespaces um einen Typ mit globaler Gültigkeitsdauer handelt. Wenn ein Mandant einen bestimmten Namespace anzeigen kann, kann er alle Namespaces innerhalb des Clusters sehen. **Warnung** Bei Soft-Multi-Tenancy behalten Mandanten die Möglichkeit, CoreDNS für alle Dienste abzufragen, die standardmäßig innerhalb des Clusters ausgeführt werden. Ein Angreifer könnte dies ausnutzen, indem er dig SRV von einem beliebigen Pod im Cluster ` ..svc.cluster.local` aus ausführt. Wenn Sie den Zugriff auf DNS-Einträge von Diensten einschränken müssen, die in Ihren Clustern ausgeführt werden, sollten Sie die Firewall- oder Policy-Plug-ins für CoreDNS verwenden. Weitere Informationen finden Sie unter https://github.com/coredns/policy \#kubernetes -metadata-multi-tenancy-policy. [Kiosk ](https://github.com/kiosk-sh/kiosk) ist ein Open-Source-Projekt, das bei der Implementierung von Soft Multi-Tenancy helfen kann. Es ist als eine Reihe von CRDs und Controllern implementiert, die die folgenden Funktionen bieten: + **Konten und Kontobenutzer ** zur Trennung von Mandanten in einem gemeinsam genutzten Kubernetes-Cluster + **Self-Service Namespace-Bereitstellung ** für Kontonutzer + **Kontolimits ** zur Gewährleistung der Servicequalität und Fairness bei der gemeinsamen Nutzung eines Clusters + **Namespace-Vorlagen ** für sichere Mandantenisolierung und Self-Service-Namespace-Initialisierung [Loft ](https://loft.sh) ist ein kommerzielles Angebot der Betreiber von Kiosk, das die folgenden Funktionen bietet: [ DevSpace ](https://github.com/devspace-cloud/devspace) + **Multi-cluster Zugriff, ** um Zugriff auf Bereiche in verschiedenen Clustern zu gewähren + **Im Ruhemodus werden Bereitstellungen in einem Space in Zeiten der Inaktivität ** herunterskaliert + **Einmaliges Anmelden bei ** OIDC-Authentifizierungsanbietern wie GitHub Es gibt drei Hauptanwendungsfälle, die mit Soft-Multi-Tenancy angegangen werden können. ### Einstellung für Unternehmen Die erste ist in einer Unternehmensumgebung, in der den „Mietern“ ein gewisses Vertrauen entgegengebracht wird, da sie Mitarbeiter oder Auftragnehmer sind oder anderweitig von der Organisation autorisiert wurden. Jeder Mandant gehört in der Regel einer Verwaltungsabteilung an, z. B. einer Abteilung oder einem Team. In einer solchen Umgebung ist in der Regel ein Clusteradministrator für die Erstellung von Namespaces und die Verwaltung von Richtlinien verantwortlich. Sie können auch ein Modell der delegierten Verwaltung implementieren, bei dem bestimmte Personen die Aufsicht über einen Namespace erhalten, sodass sie CRUD-Operationen für Objekte ausführen können, die nichts mit Richtlinien zu tun haben, wie Bereitstellungen, Dienste, Pods, Jobs usw. Die durch eine Container-Runtime bereitgestellte Isolierung kann innerhalb dieser Einstellung akzeptabel sein, oder sie muss möglicherweise durch zusätzliche Steuerelemente für die Pod-Sicherheit erweitert werden. Es kann auch erforderlich sein, die Kommunikation zwischen Diensten in verschiedenen Namespaces einzuschränken, wenn eine strengere Isolierung erforderlich ist. ### Kubernetes als Dienst Im Gegensatz dazu kann Soft Multi-Tenancy in Einstellungen verwendet werden, in denen Sie Kubernetes as a Service (KaaS) anbieten möchten. Bei KaaS wird Ihre Anwendung zusammen mit einer Sammlung von Controllern und CRDs, die eine Reihe von PaaS-Diensten bereitstellen, in einem gemeinsam genutzten Cluster gehostet. Mandanten interagieren direkt mit dem Kubernetes-API-Server und dürfen CRUD-Operationen an Objekten ausführen, die keine Richtlinien sind. Es gibt auch ein Element des Self-Service, da Mandanten möglicherweise ihre eigenen Namespaces erstellen und verwalten dürfen. In dieser Art von Umgebung wird davon ausgegangen, dass Mandanten nicht vertrauenswürdigen Code ausführen. Um Mandanten in einer solchen Umgebung zu isolieren, müssen Sie wahrscheinlich strenge Netzwerkrichtlinien sowie * Pod-Sandboxing * implementieren. Beim Sandboxing werden die Container eines Pods in einer Micro-VM wie Firecracker oder in einem User-Space-Kernel ausgeführt. Heute können Sie mit EKS Fargate Sandbox-Pods erstellen. ### Software-as-a-Service (SaaS) Der letzte Anwendungsfall für Soft-Multi-Tenancy liegt in einer Software-as-a-Service (SaaS-) Umgebung. In dieser Umgebung ist jeder Mandant einer bestimmten * Instanz einer Anwendung zugeordnet, die innerhalb * des Clusters ausgeführt wird. Jede Instanz hat oft ihre eigenen Daten und verwendet separate Zugriffskontrollen, die normalerweise unabhängig von Kubernetes RBAC sind. Im Gegensatz zu den anderen Anwendungsfällen ist der Tenant in einer SaaS-Einstellung nicht direkt mit der Kubernetes-API verbunden. Stattdessen ist die SaaS-Anwendung für die Schnittstelle zur Kubernetes-API verantwortlich, um die erforderlichen Objekte zur Unterstützung der einzelnen Mandanten zu erstellen. ## Kubernetes-Konstrukte In jeder dieser Instanzen werden die folgenden Konstrukte verwendet, um Mandanten voneinander zu isolieren: ### Namespaces Namespaces sind grundlegend für die Implementierung von Soft-Multi-Tenancy. Sie ermöglichen es Ihnen, den Cluster in logische Partitionen zu unterteilen. Kontingente, Netzwerkrichtlinien, Dienstkonten und andere Objekte, die für die Implementierung der Mehrmandantenfähigkeit erforderlich sind, sind einem Namespace zugeordnet. ### Netzwerkrichtlinien Standardmäßig dürfen alle Pods in einem Kubernetes-Cluster miteinander kommunizieren. Dieses Verhalten kann mithilfe von Netzwerkrichtlinien geändert werden. Netzwerkrichtlinien schränken die Kommunikation zwischen Pods mithilfe von Labels oder IP-Adressbereichen ein. In einer Umgebung mit mehreren Mandanten, in der eine strikte Netzwerkisolierung zwischen Mandanten erforderlich ist, empfehlen wir, mit einer Standardregel zu beginnen, die die Kommunikation zwischen Pods verweigert, und einer weiteren Regel, die es allen Pods ermöglicht, den DNS-Server zur Namensauflösung abzufragen. Damit können Sie beginnen, weitere freizügige Regeln hinzuzufügen, die die Kommunikation innerhalb eines Namespaces ermöglichen. Dies kann bei Bedarf weiter verfeinert werden. **Anmerkung** Amazon [ VPC CNI unterstützt jetzt Kubernetes-Netzwerkrichtlinien, ](https://aws.amazon.com/blogs/containers/amazon-vpc-cni-now-supports-kubernetes-network-policies/) um Richtlinien zu erstellen, mit denen sensible Workloads isoliert und vor unbefugtem Zugriff geschützt werden können, wenn Kubernetes auf AWS ausgeführt wird. Das bedeutet, dass Sie alle Funktionen der Network Policy API in Ihrem Amazon EKS-Cluster nutzen können. Diese Ebene der granularen Steuerung ermöglicht es Ihnen, das Prinzip der geringsten Rechte zu implementieren, das sicherstellt, dass nur autorisierte Pods miteinander kommunizieren dürfen. **Wichtig** Netzwerkrichtlinien sind notwendig, reichen aber nicht aus. Die Durchsetzung von Netzwerkrichtlinien erfordert eine Policy-Engine wie Calico oder Cilium. ### Role-based Zugriffskontrolle (RBAC) Rollen und Rollenbindungen sind die Kubernetes-Objekte, die zur Durchsetzung der rollenbasierten Zugriffskontrolle (RBAC) in Kubernetes verwendet werden. **Rollen ** enthalten Listen von Aktionen, die für Objekte in Ihrem Cluster ausgeführt werden können. **Rollenbindungen ** geben die Personen oder Gruppen an, für die die Rollen gelten. In den Unternehmens- und KaaS-Einstellungen kann RBAC verwendet werden, um die Verwaltung von Objekten durch ausgewählte Gruppen oder Einzelpersonen zu ermöglichen. ### Kontingente Kontingente werden verwendet, um Grenzwerte für Workloads zu definieren, die in Ihrem Cluster gehostet werden. Mit Kontingenten können Sie die Gesamtmenge an CPU und Arbeitsspeicher begrenzen, die in einem Namespace verbraucht werden kann, oder die Anzahl der Objekte begrenzen, die erstellt werden können. **Grenzbereiche ** ermöglichen es Ihnen, die Mindest-, Höchst- und Standardwerte für CPU und Arbeitsspeicher für einzelne Pods und Container innerhalb eines Namespace zu deklarieren. Das Überbeanspruchen von Ressourcen in einem gemeinsam genutzten Cluster ist oft von Vorteil, da Sie so Ihre Ressourcen optimal nutzen können. Unbegrenzter Zugriff auf einen Cluster kann jedoch zu einem Mangel an Ressourcen führen, was zu Leistungseinbußen und zum Verlust der Anwendungsverfügbarkeit führen kann. Wenn die Anforderungen eines Pods zu niedrig eingestellt sind und die tatsächliche Ressourcenauslastung die Kapazität des Knotens übersteigt, kommt es auf dem Knoten zu einer Belastung der CPU oder des Speichers. In diesem Fall werden die Pods möglicherweise neu gestartet und vom and/or Knoten entfernt. Um dies zu verhindern, sollten Sie planen, in einer Umgebung mit mehreren Mandanten Kontingente für Namespaces festzulegen, um Mandanten zu zwingen, bei der Planung ihrer Pods im Cluster Anforderungen und Grenzwerte anzugeben. Außerdem wird so ein potenzieller Denial-of-Service eingedämmt, indem die Menge an Ressourcen, die ein Pod verbrauchen kann, begrenzt wird. Sie können auch Kontingente verwenden, um die Ressourcen des Clusters so aufzuteilen, dass sie den Ausgaben eines Mandanten entsprechen. Dies ist besonders im KaaS-Szenario nützlich. ### Pod-Priorität und Präemption Pod-Priorität und Präemption können nützlich sein, wenn Sie einem Pod im Vergleich zu anderen Pods eine höhere Bedeutung beimessen möchten. Mit Pod-Priorität können Sie beispielsweise Pods von Kunde A so konfigurieren, dass sie mit einer höheren Priorität als Kunde B ausgeführt werden. Wenn nicht genügend Kapazität verfügbar ist, entfernt der Scheduler die Pods mit niedrigerer Priorität von Kunde B, um die Pods mit höherer Priorität von Kunde A aufzunehmen. Dies kann besonders in einer SaaS-Umgebung praktisch sein, in der Kunden, die bereit sind, eine Prämie zu zahlen, eine höhere Priorität erhalten. **Wichtig** Die Priorität von Pods kann unerwünschte Auswirkungen auf andere Pods mit niedrigerer Priorität haben. Beispielsweise werden die Pods des Opfers zwar ordnungsgemäß beendet, dies PodDisruptionBudget ist jedoch nicht garantiert. Dadurch kann eine Anwendung mit niedrigerer Priorität, die auf ein Quorum von Pods angewiesen ist, zum Erliegen kommen, siehe [ Einschränkungen der Präemption. ](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#limitations-of-preemption) ## Abschwächende Kontrollen Ihr Hauptanliegen als Administrator einer Umgebung mit mehreren Mandanten besteht darin, zu verhindern, dass ein Angreifer Zugriff auf den zugrunde liegenden Host erhält. Zur Minderung dieses Risikos sollten die folgenden Maßnahmen in Betracht gezogen werden: ### Sandbox-Ausführungsumgebungen für Container Sandboxing ist eine Technik, bei der jeder Container auf einer eigenen isolierten virtuellen Maschine ausgeführt wird. Zu den Technologien, die Pod-Sandboxing durchführen, gehört [ Firecracker. ](https://firecracker-microvm.github.io/) Weitere Informationen zu den Bemühungen, Firecracker zu einer unterstützten Laufzeit für EKS zu machen, finden Sie unter https://threadreaderapp.com/thread/1238496944684597248.html. ### Öffnen Sie den Policy Agent (OPA) Gatekeeper & [Gatekeeper ](https://github.com/open-policy-agent/gatekeeper) ist ein Kubernetes-Zugangscontroller, der mit OPA erstellte Richtlinien durchsetzt. [https://www.openpolicyagent.org/](https://www.openpolicyagent.org/) Mit OPA können Sie eine Richtlinie erstellen, die Pods von Mandanten auf separaten Instanzen oder mit einer höheren Priorität als bei anderen Mandanten ausführt. Eine Sammlung gängiger OPA-Richtlinien finden Sie im GitHub [ Repository ](https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa) für dieses Projekt. Es gibt auch ein experimentelles [ OPA-Plugin für CoreDNS](https://github.com/coredns/coredns-opa), mit dem Sie OPA für die von CoreDNS zurückgegebenen Datensätze verwenden können. filter/control ### Kyverno [Kyverno ](https://kyverno.io) ist eine native Policy-Engine von Kubernetes, die Konfigurationen mit Richtlinien als Kubernetes-Ressourcen validieren, mutieren und generieren kann. Kyverno verwendet Kustomize-style Overlays zur Validierung, unterstützt JSON-Patch und strategischen Merge-Patch für Mutationen und kann Ressourcen auf der Grundlage flexibler Trigger namespace-übergreifend klonen. Sie können Kyverno verwenden, um Namespaces zu isolieren, die Pod-Sicherheit und andere bewährte Methoden durchzusetzen und Standardkonfigurationen wie Netzwerkrichtlinien zu generieren. Das Repository für dieses Projekt enthält mehrere Beispiele. GitHub [https://github.com/aws/aws-eks-best-practices/tree/master/policies/kyverno](https://github.com/aws/aws-eks-best-practices/tree/master/policies/kyverno) Viele andere sind in der [ Richtlinienbibliothek ](https://kyverno.io/policies/) auf der Kyverno-Website enthalten. ### Isolierung der Mandanten-Workloads auf bestimmte Knoten Das Beschränken der Mandanten-Workloads auf die Ausführung auf bestimmten Knoten kann verwendet werden, um die Isolierung im Soft-Multi-Tenancy-Modell zu erhöhen. Bei diesem Ansatz werden mandantenspezifische Workloads nur auf Knoten ausgeführt, die für die jeweiligen Mandanten bereitgestellt werden. Um diese Isolierung zu erreichen, werden native Kubernetes-Eigenschaften (Knotenaffinität sowie Taints und Toleranzen) verwendet, um für die Pod-Planung auf bestimmte Knoten abzuzielen und zu verhindern, dass Pods von anderen Mandanten auf den mandantenspezifischen Knoten geplant werden. #### Teil 1 — Node-Affinität Die [ Kubernetes-Knotenaffinität ](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) wird verwendet, um Knoten für die Planung auf der Grundlage von [ Knotenbezeichnungen anzuvisieren. ](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) Mit den Regeln für die Knotenaffinität werden die Pods zu bestimmten Knoten hingezogen, die den Selektorbedingungen entsprechen. In der folgenden Pod-Spezifikation wird die `requiredDuringSchedulingIgnoredDuringExecution` Node-Affinität auf den jeweiligen Pod angewendet. Das Ergebnis ist, dass der Pod auf Knoten abzielt, die mit den folgenden Bezeichnungen versehen sind 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 ... ``` Bei dieser Knotenaffinität ist das Label während der Planung erforderlich, aber nicht während der Ausführung. Wenn sich die Labels der zugrunde liegenden Knoten ändern, werden die Pods nicht allein aufgrund dieser Labeländerung entfernt. Die zukünftige Planung könnte jedoch beeinträchtigt werden. **Warnung** Das Labelpräfix von `node-restriction.kubernetes.io/` hat in Kubernetes eine besondere Bedeutung. [NodeRestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)was für EKS-Cluster aktiviert ist, `kubelet` verhindert, dass Labels mit adding/removing diesem Präfix /aktualisiert werden. Angreifer können das `kubelet’s credentials to update the node object or modify the system setup to pass these labels into `kubelet` da nicht verwenden, um diese Labels `kubelet` nicht zu ändern. Wenn dieses Präfix für die gesamte Planung von Pod zu Knoten verwendet wird, verhindert es Szenarien, in denen ein Angreifer möglicherweise andere Workloads auf einen Knoten übertragen möchte, indem er die Knotenbezeichnungen ändert. **Example** Anstelle der Knotenaffinität hätten wir den [ Node ](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) Selector verwenden können. Die Knotenaffinität ist jedoch aussagekräftiger und ermöglicht es, bei der Pod-Planung mehr Bedingungen zu berücksichtigen. Weitere Informationen zu den Unterschieden und erweiterten Planungsoptionen finden Sie in diesem CNCF-Blogbeitrag zur [ erweiterten Kubernetes-Pod-to-Node-Scheduling. ](https://www.cncf.io/blog/2021/07/27/advanced-kubernetes-pod-to-node-scheduling/) #### Teil 2 — Makel und Toleranzen Das Anziehen von Pods an Knoten ist nur der erste Teil dieses dreiteiligen Ansatzes. Damit dieser Ansatz funktioniert, müssen wir verhindern, dass Pods aus der Planung auf Knoten verteilt werden, für die die Pods nicht autorisiert sind. Um unerwünschte oder nicht autorisierte Pods abzuwehren, verwendet Kubernetes Node-Taints. [https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) Taints werden verwendet, um Nodes mit Bedingungen zu versehen, die verhindern, dass Pods geplant werden. Das folgende Taint verwendet ein Schlüssel-Wert-Paar von. `tenant: tenants-x` ``` ... taints: - key: tenant value: tenants-x effect: NoSchedule ... ``` Angesichts des obigen Knotens `taint` dürfen nur Pods, die * den Taint * tolerieren, auf dem Knoten geplant werden. Damit autorisierte Pods auf dem Knoten eingeplant werden können, müssen die jeweiligen Pod-Spezifikationen die Angabe „A `toleration` to the Taint“ enthalten (siehe unten). ``` ... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ... ``` Pods mit den oben genannten Bedingungen `toleration` werden nicht daran gehindert, auf dem Knoten zu planen, zumindest nicht aufgrund dieses speziellen Fehlers. Taints werden auch von Kubernetes verwendet, um die Pod-Planung unter bestimmten Bedingungen, wie z. B. unter Ressourcendruck auf dem Knoten, vorübergehend zu beenden. Mithilfe von Node-Affinität sowie Taints und Toleranzen können wir die gewünschten Pods effektiv an bestimmte Knoten binden und unerwünschte Pods abwehren. **Wichtig** Bestimmte Kubernetes-Pods müssen auf allen Knoten ausgeführt werden. Beispiele für diese Pods sind solche, die vom [ Container Network Interface (CNI) ](https://github.com/containernetworking/cni) und [ Kube-Proxy-Daemonsets gestartet wurden. ](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) [https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) Zu diesem Zweck enthalten die Spezifikationen für diese Pods sehr tolerante Toleranzen, um verschiedene Verunreinigungen zu tolerieren. Es sollte darauf geachtet werden, dass diese Toleranzen nicht geändert werden. Eine Änderung dieser Toleranzen kann zu einem falschen Clusterbetrieb führen. Darüber hinaus [ können Tools zur Richtlinienverwaltung wie [ OPA/Gatekeeper ](https://github.com/open-policy-agent/gatekeeper) und ](https://kyverno.io/) Kyverno verwendet werden, um validierende Richtlinien zu schreiben, die verhindern, dass nicht autorisierte Pods diese zulässigen Toleranzen verwenden. #### Teil 3 — Verwaltung Policy-based für die Knotenauswahl Es gibt mehrere Tools, mit denen Sie die Knotenaffinität und die Toleranzen von Pod-Spezifikationen verwalten können, einschließlich der Durchsetzung von Regeln in CICD-Pipelines. Die Durchsetzung der Isolation sollte jedoch auch auf Kubernetes-Cluster-Ebene erfolgen. Zu diesem Zweck können Tools zur Richtlinienverwaltung verwendet werden, um * eingehende Kubernetes-API-Serveranfragen auf der Grundlage von Anforderungsnutzlasten so zu * modifizieren, dass die oben genannten Regeln und Toleranzen für die Node-Affinität angewendet werden. Beispielsweise können Pods, die für den * * Tenants-X-Namespace bestimmt sind, * mit der richtigen Knotenaffinität und Toleranz * versehen werden, um die Planung auf den Tenants-X-Knoten zu ermöglichen. * * Mithilfe von Tools zur Richtlinienverwaltung, die mit dem Kubernetes [ Mutating Admission Webhook konfiguriert wurden, können Richtlinien verwendet werden, um die Spezifikationen für eingehende Pods zu ändern. ](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) Die Mutationen fügen die erforderlichen Elemente hinzu, um die gewünschte Planung zu ermöglichen. Eine OPA/Gatekeeper Beispielrichtlinie, die eine Node-Affinität hinzufügt, ist unten zu sehen. ``` 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" ``` Die obige Richtlinie wird auf eine Kubernetes-API-Serveranforderung angewendet, um einen Pod auf den * * Tenants-X-Namespace anzuwenden. Die Richtlinie fügt die `requiredDuringSchedulingIgnoredDuringExecution` Knotenaffinitätsregel hinzu, sodass Pods von Knoten mit dem Label angezogen werden. `tenant: tenants-x` Eine zweite Richtlinie (siehe unten) fügt die Toleranz derselben Pod-Spezifikation hinzu, wobei dieselben Übereinstimmungskriterien für den Ziel-Namespace sowie für Gruppen, Typen und Versionen verwendet werden. ``` 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" ``` Die oben genannten Richtlinien sind spezifisch für Pods. Das liegt an den Pfaden zu den mutierten Elementen in den Elementen der Richtlinien. `location` Zusätzliche Richtlinien könnten für den Umgang mit Ressourcen, die Pods erstellen, wie Bereitstellungs- und Jobressourcen, geschrieben werden. Die aufgeführten Richtlinien und andere Beispiele finden Sie im [ GitHub Begleitprojekt ](https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa/gatekeeper/node-selector) zu diesem Handbuch. Das Ergebnis dieser beiden Mutationen ist, dass die Schoten vom gewünschten Knoten angezogen werden, während sie gleichzeitig nicht durch den spezifischen Knotenfleck abgestoßen werden. Um dies zu überprüfen, können wir uns die Ausgabeschnipsel zweier `kubectl` Aufrufe ansehen, mit denen die Knoten beschriftet wurden`tenant=tenants-x`, und die Pods im Namespace abgerufen werden. `tenants-x` ``` 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... ``` Wie wir den obigen Ausgaben entnehmen können, sind alle Pods auf den Knoten geplant, die mit gekennzeichnet sind. `tenant=tenants-x` Einfach ausgedrückt, die Pods laufen nur auf den gewünschten Knoten und die anderen Pods (ohne die erforderliche Affinität und Toleranzen) nicht. Die Arbeitslasten der Mandanten sind effektiv isoliert. Ein Beispiel für eine mutierte Pod-Spezifikation ist unten zu sehen. ``` 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 ... ``` **Wichtig** Policy-management Tools, die in den Anforderungsablauf des Kubernetes-API-Servers integriert sind und mutierende und validierende Zulassungswebhooks verwenden, sind so konzipiert, dass sie innerhalb eines bestimmten Zeitrahmens auf die Anfrage des API-Servers antworten. Dies sind normalerweise 3 Sekunden oder weniger. Wenn der Webhook-Aufruf innerhalb der konfigurierten Zeit keine Antwort zurückgibt, kann die and/or Mutationsvalidierung der eingehenden API-Serveranfrage erfolgen oder auch nicht. Dieses Verhalten hängt davon ab, ob die Zugangs-Webhook-Konfigurationen auf [ Fail Open oder Fail Close gesetzt sind. ](https://open-policy-agent.github.io/gatekeeper/website/docs/#admission-webhook-fail-open-by-default) In den obigen Beispielen haben wir Richtlinien verwendet, die für OPA/Gatekeeper geschrieben wurden. Es gibt jedoch auch andere Tools zur Richtlinienverwaltung, die unseren Anwendungsfall der Knotenauswahl ebenfalls behandeln. Diese [ Kyverno-Richtlinie ](https://kyverno.io/policies/other/add-node-affinity/add-node-affinity/) könnte beispielsweise verwendet werden, um die Mutation der Knotenaffinität zu behandeln. **Anmerkung** Bei ordnungsgemäßer Funktionsweise wirken sich veränderte Richtlinien auf die gewünschten Änderungen an den Payloads eingehender API-Serveranfragen aus. Allerdings sollten auch validierende Richtlinien enthalten sein, um sicherzustellen, dass die gewünschten Änderungen tatsächlich eintreten, bevor die Änderungen fortbestehen. Dies ist besonders wichtig, wenn diese Richtlinien für die Isolierung von Mandant zu Knoten verwendet werden. Es ist auch eine gute Idee, * * Überwachungsrichtlinien einzubeziehen, um Ihren Cluster routinemäßig auf unerwünschte Konfigurationen zu überprüfen. ### Referenzen + [k-rail ](https://github.com/cruise-automation/k-rail) Entwickelt, um Sie bei der Absicherung einer Umgebung mit mehreren Mandanten durch die Durchsetzung bestimmter Richtlinien zu unterstützen. + [Sicherheitspraktiken für MultiTenant SaaS-Anwendungen, die Amazon EKS verwenden ](https://d1.awsstatic.com/whitepapers/security-practices-for-multi-tenant-saas-apps-using-eks.pdf) ## Harte Mehrmandantenfähigkeit Eine harte Mehrmandantenfähigkeit kann implementiert werden, indem für jeden Mandanten separate Cluster bereitgestellt werden. Dies sorgt zwar für eine sehr starke Isolierung zwischen den Mandanten, hat jedoch mehrere Nachteile. Erstens, wenn Sie viele Mieter haben, kann dieser Ansatz schnell teuer werden. Sie müssen nicht nur für die Kosten der Steuerungsebene für jeden Cluster aufkommen, Sie werden auch nicht in der Lage sein, Rechenressourcen zwischen Clustern gemeinsam zu nutzen. Dies führt letztendlich zu einer Fragmentierung, bei der ein Teil Ihrer Cluster nicht ausgelastet ist, während andere überlastet sind. Zweitens müssen Sie wahrscheinlich spezielle Tools kaufen oder bauen, um all diese Cluster zu verwalten. Mit der Zeit kann die Verwaltung von Hunderten oder Tausenden von Clustern einfach zu umständlich werden. Schließlich wird das Erstellen eines Clusters pro Mandant im Vergleich zum Erstellen eines Namespaces langsam vonstatten gehen. Dennoch kann in stark regulierten Branchen oder in SaaS-Umgebungen, in denen eine starke Isolierung erforderlich ist, ein Hardtenancy-Ansatz erforderlich sein. ## Künftige Richtungen Die Kubernetes-Community hat die aktuellen Mängel der weichen Mehrmandantenfähigkeit und die Herausforderungen erkannt, die eine harte Mehrmandantenfähigkeit mit sich bringt. Die [ Multi-Tenancy Special Interest Group (SIG) ](https://github.com/kubernetes-sigs/multi-tenancy) versucht, diese Mängel durch mehrere Inkubationsprojekte zu beheben, darunter Hierarchical Namespace Controller (HNC) und Virtual Cluster. Der HNC-Vorschlag (KEP) beschreibt eine Möglichkeit, Eltern-Kind-Beziehungen zwischen Namespaces mithilfe der [Policy] -Objektvererbung herzustellen. Außerdem wird Mandantenadministratoren die Möglichkeit gegeben, Unternamespaces zu erstellen. Der Virtual Cluster-Vorschlag beschreibt einen Mechanismus zur Erstellung separater Instanzen der Control-Plane-Dienste, einschließlich des API-Servers, des Controller-Managers und des Schedulers, für jeden Mandanten innerhalb des Clusters (auch bekannt als „Kubernetes on Kubernetes“). Der [ Multi-Tenancy ](https://github.com/kubernetes-sigs/multi-tenancy/blob/master/benchmarks/README.md) Benchmarks-Vorschlag enthält Richtlinien für die gemeinsame Nutzung von Clustern mithilfe von Namespaces zur Isolierung und Segmentierung sowie ein Befehlszeilentool kubectl-mtb zur Überprüfung der Einhaltung der Richtlinien. [https://github.com/kubernetes-sigs/multi-tenancy/blob/master/benchmarks/kubectl-mtb/README.md](https://github.com/kubernetes-sigs/multi-tenancy/blob/master/benchmarks/kubectl-mtb/README.md) ## Multi-cluster Management-Tools und Ressourcen + [Banzai Cloud ](https://banzaicloud.com/) + [Kommandant ](https://d2iq.com/solutions/ksphere/kommander) + [Linse ](https://github.com/lensapp/lens) + [Nirmata ](https://nirmata.com) + [Rafay ](https://rafay.co/) + [Rancher ](https://rancher.com/products/rancher/) + [Fluss ](https://fluxcd.io/)