This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

Sicherheit

Dieses Thema bietet einen allgemeinen Überblick über die Sicherheit von Tanzu Kubernetes Grid.

Einführung

Tanzu Kubernetes Grid (TKG) ermöglicht eine konsistente systemeigene Kubernetes-Erfahrung in jeder Cloud. Die Sicherheitskontrollen können daher auch in verschiedenen Umgebungen einheitlich angewendet werden, indem mehrere vorgefertigte Komponenten in TKG verwendet werden, die zu einer größeren Sicherheit für Arbeitslastcluster und die zugrunde liegende Umgebung beitragen. Das Modell der gemeinsamen Verantwortung gilt auch für die Sicherung von Umgebungen, in denen von Tanzu Kubernetes Grid bereitgestellte Cluster für alle Ebenen im cloudnativen Stack ausgeführt werden: Code, Container, Cluster und Cloud.

In diesem Dokument wird versucht, den aktuellen Stand der TKG-Sicherheit darzulegen. Mit jeder neuen Version verbessert VMware die Sicherheit von TKG. Der Schwerpunkt liegt dabei darauf, die Sicherheit zu einem integralen Bestandteil des Produkts zu machen und gleichzeitig ein reibungsloses Entwicklererlebnis zu gewährleisten. Alle Empfehlungen in diesem Dokument sollten auf Basis der Sicherheitsausrichtung und Risikobereitschaft des Unternehmens betrachtet werden.

Die Sicherheitsdetails unterscheiden sich zwischen TKG, das mit einem vSphere with Tanzu-Supervisor bereitgestellt wird, und TKG, das mit einem eigenständigen Verwaltungscluster bereitgestellt wird. Die Sicherheitsstory für Supervisor-basierte Bereitstellungen wird in der unten verlinkten vSphere with Tanzu-Dokumentation behandelt. Im verbleibenden Teil dieses Themas werden TKG-Bereitstellungen mit eigenständigen Verwaltungsclustern beschrieben.

Sicherheit eines vSphere with Tanzu-Supervisors

Bei Tanzu Kubernetes Grid v2.0 auf vSphere 8 mit Supervisor handelt es sich um ein Add-On-Modul für vSphere, das viele vSphere-Funktionen nutzt, einschließlich vSphere-Sicherheit und vCenter SSO. Weitere Informationen zur Sicherheit von Tanzu Kubernetes Grid v2.0 finden Sie unter vSphere with Tanzu Security in der vSphere 8-Dokumentation.

Dieses Dokument bezieht sich ausschließlich auf das Multi-Cloud-Angebot für Tanzu Kubernetes Grid. Die offizielle Produktdokumentation und Unterschiede zu anderen Angeboten finden Sie hier.

Hier finden Sie Sicherheitshinweise zu anderen VMware Tanzu-Angeboten:

Sicherheit für eigenständige Verwaltungscluster

In den folgenden Abschnitten wird die Sicherheit in und rund um TKG beschrieben, das mit einem eigenständigen Verwaltungscluster bereitgestellt wird. Dazu gehören die Sicherheitskontrollen, die im Produkt integriert sind, sowie Best Practices zur Implementierung ergänzender Sicherheitskontrollen, die die Umgebungen schützen, in denen Tanzu Kubernetes Grid-Cluster bereitgestellt werden.

Code

Tanzu Kubernetes Grid führt Code aus, der von Anwendungsentwicklern geschrieben und als Kubernetes-Pods bereitgestellt wird. Tanzu Kubernetes Grid besteht aus verschiedenen Komponenten. Bei den meisten handelt es sich um Open Source-Komponenten, es gibt aber auch einige proprietäre VMware-Komponenten. Wenn der Code all dieser Anwendungen und Komponenten sicher ist, verbessert sich die Sicherheitslage der Umgebung, in der die mit Tanzu Kubernetes Grid bereitgestellten Cluster ausgeführt werden.

Tanzu Kubernetes Grid wurde in Übereinstimmung mit dem VMware Security Development Lifecycle-Prozess entwickelt. Zur Gewährleistung der Produktsicherheit von Tanzu Kubernetes Grid werden insbesondere die folgenden Best Practices implementiert:

  • Überarbeitung des Bedrohungsmodells bei jeder größeren Designänderung im Produkt.

  • Bearbeitung von Fehlerkorrekturen mit hoher Priorität entsprechend der Ergebnisse aus der Bedrohungsmodellierung.

  • Automatisierte Builds für alle Tanzu Kubernetes Grid-Kernkomponenten zur Kompilierung aus dem Quellcode.

  • Teilnahme an Upstream-Projekten für Sicherheitspatches, Versionsmanagement und Priorisierung von Schwachstellen.

  • Für proprietären VMware Code vor der Zusammenführung in den main-Zweig:

    • Implementieren von Peer-Codeprüfungen zu Qualitätssicherungszwecken.

    • Ausführen automatisierter statischer Codeprüfungen mit Tools wie golint, gosec, govet.

  • Signieren von Binärdateien wie kubectl oder tanzu-cli mit VMware-Signaturschlüsseln.

Zum Sichern des Codes der Container-Anwendungen, die auf Tanzu Kubernetes Grid ausgeführt werden, können sich die folgenden Ressourcen als hilfreich erweisen:

Container

Container werden als isolierte Prozesse im Linux-Namespace instanziiert, wobei vorgefertigte Images verwendet werden, bei denen es sich im Wesentlichen um Tarballs mit allen Laufzeitabhängigkeiten und eine App-Binärdatei zur Ausführung der Container-Anwendung handelt. Tanzu Kubernetes Grid führt diese Container als Teil von Kubernetes-Pods aus. Viele Tanzu Kubernetes Grid-Komponenten sind auch als Container-Images gepackt und zur Ausführung als Pods konfiguriert (manchmal als Kubernetes-DaemonSets oder statische Pods). Die folgenden Best Practices werden implementiert, um Container mit Tanzu Kubernetes Grid-Komponenten zu sichern:

  • Überprüfen Sie während des push-Zugriffs auf die Registrierung des Staging-Containers alle Container-Images mit dem Schwachstellen-Scanner auf CVEs (Common Vulnerability and Exposures).

  • Beschränken Sie den push-Zugriff auf die externe Container-Registrierung nach dem Prinzip der geringsten Berechtigung auf das Tanzu Kubernetes Grid-Release-Team.

  • Verwenden Sie nach Erfüllung der Freigabekriterien und Abschluss der entsprechenden Tests einen zentral (LDAP) verwalteten Dienst oder ein Roboter-Konto, das den push-Vorgang von Container-Images von Staging bis zur Produktion automatisiert.

  • Führen Sie eine interne Folgenabschätzung durch, in der alle kritischen, nicht behobenen Schwachstellen in den Container-Images dokumentiert werden.

  • Beheben Sie Schwachstellen mit erheblichen Auswirkungen auf das Produkt [1][2], ohne auf die nächste Nebenversion zu warten.

  • Führen Sie regelmäßige Updates der Tanzu Kubernetes Grid-Komponenten auf neuere Basisimages durch, um Fehlerkorrekturen für neu erkannte Schwachstellen zu erhalten.

  • Beschleunigen Sie gegebenenfalls die Umstellung auf minimale Images für alle Tanzu Kubernetes Grid-Komponenten. Minimieren Sie darüber hinaus die Verteilung von Basisimages, um die Patches für alle Images zu verringern.

Die folgenden Ressourcen erweisen sich als hilfreich für die sichere Erstellung, Ausführung und Nutzung von Container-Images:

Betriebssystem-Updates und Knoten-Image-Versionen

VMware packt Betriebssystem-Images versionierter Basismaschinen in Tanzu Kubernetes-Releases (TKrs) zusammen mit kompatiblen Versionen von Kubernetes und unterstützenden Komponenten. Tanzu Kubernetes Grid verwendet dann diese gepackten Betriebssystem-, Kubernetes- und Komponentenversionen, um Cluster- und Steuerungsebenenknoten zu erstellen. Weitere Informationen finden Sie unter Tanzu Kubernetes-Releases und benutzerdefinierte Knoten-Images.

Jedes veröffentlichte TKr verwendet das neueste stabile und allgemein verfügbare Update der von ihm gepackten Betriebssystemversion mit allen aktuellen CVE- und USN-Fehlerkorrekturen ab dem Tag, an dem das Image erstellt wurde. VMware erstellt diese Knoten-Images (vSphere-OVAs, AWS-AMIs und Azure-VM-Images) mit jeder Version von Tanzu Kubernetes Grid neu (gegebenenfalls auch häufiger). Die Image-Dateien sind von VMware signiert und weisen Dateinamen auf, die einen eindeutigen Hashcode-Bezeichner enthalten.

Wenn kritische oder hoch priorisierte CVEs gemeldet werden, arbeitet VMware an einer Fehlerkorrektur und erstellt nach Veröffentlichung dieser Korrektur alle betroffenen Knoten-Images und Container-Basisimages neu, um das Update einzubeziehen.

FIPS-fähige Versionen

Sie können eine FIPS-fähige Version von Tanzu Kubernetes Grid v2.1.0 und v2.1.1 installieren und ausführen, in der Kernkomponenten kryptografische Primitive verwenden, die von einer FIPS-konformen Bibliothek auf Basis des Moduls BoringCrypto/BoringSSL bereitgestellt werden. Zu diesen Kernkomponenten gehören Komponenten von Kubernetes, Containerd und CRI, CNI-Plug-Ins, CoreDNS und etcd.

Informationen zum Installieren von FIPS-fähigem Tanzu Kubernetes Grid v2.1 finden Sie unter FIPS-fähige Versionen in der Dokumentation zu TKG v2.1.

Cluster

Ein Kubernetes-Cluster besteht aus mehreren Komponenten, die als Steuerungsebene des Clusters fungieren, sowie aus einer Reihe unterstützender Komponenten und Worker-Knoten, die die Ausführung der bereitgestellten Arbeitslasten unterstützen. Das Tanzu Kubernetes Grid-Setup enthält zwei Arten von Clustern: Verwaltungscluster und Arbeitslastcluster. Der Tanzu Kubernetes Grid-Verwaltungscluster hostet alle Tanzu Kubernetes Grid-Komponenten, die zum Verwalten von Arbeitslastclustern verwendet werden. Von Tanzu Kubernetes Grid-Administratoren erstellte Arbeitslastcluster werden dann zum Ausführen der Container-Anwendungen verwendet. Clusteradministratoren, Entwickler und Operatoren von Tanzu Kubernetes Grid, die Apps auf von Tanzu Kubernetes Grid bereitgestellten Clustern ausführen, sind gemeinsam für die Clustersicherheit verantwortlich. In diesem Abschnitt werden die in Tanzu Kubernetes Grid standardmäßig enthaltenen Komponenten aufgelistet, die bei der Implementierung sicherer Best Practices für Verwaltungs- und Arbeitslastcluster hilfreich sein können.

Identitäts- und Zugriffsverwaltung

Tanzu Kubernetes Grid verfügt über ein Pinniped-Paket, das den sicheren Zugriff auf Kubernetes-Cluster ermöglicht, wie in Identity- und Zugriffsverwaltung beschrieben.

Tanzu Kubernetes Grid-Operatoren sind weiterhin dafür verantwortlich, anderen Kubernetes-Benutzern über die integrierte rollenbasierte Zugriffssteuerung Zugriff auf Clusterressourcen zu gewähren. Zu den empfohlenen Best Practices für die Verwaltung von Identitäten in von Tanzu Kubernetes Grid bereitgestellten Clustern gehören:

  • Beschränken des Zugriffs auf Clusterressourcen nach dem Prinzip der geringsten Berechtigung.

  • Beschränken des Zugriffs auf Verwaltungscluster auf die entsprechende Benutzergruppe. Gewähren Sie beispielsweise nur Benutzern Zugriff, die für die Verwaltung von Infrastruktur- und Cloud-Ressourcen verantwortlich sind, nicht jedoch Anwendungsentwicklern. Dies ist besonders wichtig, da mit dem Zugriff auf den Verwaltungscluster grundsätzlicher Zugriff auf alle Arbeitslastcluster gewährt wird.

  • Beschränken des Clusteradministratorzugriffs für Arbeitslastcluster auf die entsprechende Benutzergruppe, wie z. B. auf Benutzer, die für die Verwaltung von Infrastruktur- und Plattformressourcen in Ihrem Unternehmen verantwortlich sind, nicht aber auf Anwendungsentwickler.

  • Herstellen einer Pinniped-Verbindung zu einem zentralen Identitätsanbieter für die Verwaltung von Benutzeridentitäten mit zulässigem Zugriff auf Clusterressourcen. Hierdurch entfällt die Notwendigkeit, sich auf vom Administrator erzeugte kubeconfig-Dateien zu verlassen.

Mehrmandantenfähigkeit

Einer der Hauptvorteile von Tanzu Kubernetes Grid besteht darin, dass der gesamte Lebenszyklus mehrerer Cluster über eine einzelne Verwaltungsebene verwaltet werden kann. Dies ist wichtig, da vom Standpunkt der Mehrmandantenfähigkeit aus betrachtet die höchste Form der Isolation zwischen nicht vertrauenswürdigen Arbeitslasten nur möglich ist, wenn sie in separaten Kubernetes-Clustern ausgeführt werden. Im Folgenden werden bestimmte Standardeinstellungen aufgelistet, die für die Unterstützung von Mehrmandantenarbeitslasten in Tanzu Kubernetes Grid konfiguriert sind:

  • Knoten werden von Clustern nicht gemeinsam genutzt.

  • Knoten sind so konfiguriert, dass sie nur Containerarbeitslasten hosten können.

  • Die Verwaltungsebene wird in einem eigenen dedizierten Cluster ausgeführt, um die Trennung von Interessen bei Arbeitslastclustern zu ermöglichen.

  • Kubernetes-Verwaltungskomponenten wie api-server, scheduler, controller-manager usw. werden auf dedizierten Knoten ausgeführt. Darüber hinaus sollten Sie die Anwendung einer Überwachungsregel in Betracht ziehen, um die Bereitstellung beliebiger Arbeitslast-Pods auf Steuerungsebenenknoten zu erkennen.

  • Die Planung von Anwendungs-Pods auf dedizierten Knoten für Verwaltungskomponenten (siehe oben) wird über Knotenfunktionen und Affinitätsregeln deaktiviert.

Um die Sicherheit in einer AWS-Umgebung mit mehreren Mandanten zu verbessern, stellen Sie die Arbeitslastcluster in einem AWS-Konto bereit, das sich von dem für die Bereitstellung des Verwaltungsclusters verwendeten Konto unterscheidet. Informationen zum Bereitstellen von Arbeitslastclustern für mehrere AWS-Konten finden Sie unter Cluster auf verschiedenen AWS-Konten.

Ausführliche Informationen zu den Designüberlegungen bei der Bereitstellung von Umgebungen mit mehreren Mandanten finden Sie unter Mandantenfähigkeit von Arbeitslasten.

Isolation von Arbeitslasten

Die Anforderungen an die Isolation von Arbeitslasten sind für jeden Kunden einzigartig. Um Arbeitslasten mit akzeptabler Risikotoleranz sinnvoll voneinander zu isolieren, ist zusätzlicher Aufwand in Übereinstimmung mit dem Modell der gemeinsamen Verantwortung erforderlich. Dieser Aufwand besteht in der Begrenzung der Anzahl der mit höheren Berechtigungen auszuführenden Container auf eine paar Namespaces sowie in der Implementierung tiefgreifender Sicherheitsmechanismen wie AppArmor und SELinux zur Laufzeit auf Pod- und Knotenebene. In Tanzu Kubernetes Grid 1.6 und höher ist AppArmor standardmäßig in Ubuntu 20.04-Images aktiviert.

Diese Konfigurationen können über Pod-Sicherheitsrichtlinien zentral auf Pods durchgesetzt werden. Ziehen Sie in Betracht, die Sicherheitsrichtlinien durch Migration zu ersetzen. Zugangssteuerung für Pod-Sicherheit.

Für fortgeschrittene Anwendungsfälle und benutzerdefinierte Richtlinienverwaltung stellen die folgenden Ressourcen im Allgemeinen einen guten Ausgangspunkt dar: OPA, Zugangssteuerung und Pod-Sicherheitsstandards.

Schützen der dienstübergreifenden Kommunikation

Einer der grundlegenden Aspekte einer Microservices-Architektur besteht in der Erstellung von Diensten mit einer einzigen Aufgabe. Dies ermöglicht die Trennung von Interessen und erlaubt es Teams, effektiver zu arbeiten, erhöht jedoch auch die Notwendigkeit zur Kommunikation mit verschiedenen Microservices, die häufig im selben Cluster in eigenen Pods ausgeführt werden. Deshalb sollten die folgenden Best Practices für die Sicherung dieser Kommunikationen zur Laufzeit in Betracht gezogen werden:

  • Netzwerkrichtlinien mit geringsten Berechtigungen: Antrea ist das standardmäßige CNI-Plug-In, das in Tanzu Kubernetes Grid aktiviert ist. Weitere Informationen zur Verwendung von Antrea für die Implementierung von Netzwerkrichtlinien, die je nach Risikobereitschaft angewendet werden können, finden Sie in den offiziellen Dokumenten zu Antrea. Zur Verwendung eines anderen CNI-Plug-Ins Ihrer Wahl nutzen Sie dieses Handbuch: Pod- und Containernetzwerke

  • Mutual TLS (standardmäßig): Die Implementierung von Mutual TLS liegt in der Verantwortung der Kunden von Tanzu Kubernetes Grid. Mutual TLS kann als Teil des Anwendungsmanifests oder mithilfe eines Service Meshs implementiert werden, mit dem ein Sidecar-Container die TLS-Kommunikation für den App-Container verarbeiten kann.

  • Schützen von Geheimnissen: Beim Verwalten von Geheimnissen in einem Kubernetes-Cluster stehen verschiedene Optionen zur Auswahl bereit. Eine kurze Übersicht über die Optionen finden Sie unter Geheimnisverwaltung.

Überwachung, Protokollierung und Monitoring

Um die Beobachtbarkeit und Ablehnung von Clusterressourcen, einschließlich Anwendungs-Pods, sicherzustellen, müssen Sie die Überwachung von Clustern ermöglichen, die von Tanzu Kubernetes Grid bereitgestellt werden. Im Lieferumfang von Tanzu Kubernetes Grid befinden sich mehrere Erweiterungen, die Administratoren eine native Aktivierung ermöglichen. In den folgenden Anleitungen wird dies ausführlich erläutert:

  1. Überwachungsprotokollierung des API-Servers und Systems: Vorgehensweise zum Aktivieren der Überwachungsprotokollierung des API-Servers sowie der Überwachung auf Systemebene (Knoten), um die Ablehnung der Clusternutzung zu verhindern. Tanzu Kubernetes Grid enthält eine Standardrichtlinie für die API-Serverüberwachung. Es wird empfohlen, eine geeignete Richtlinie für den Überwachungs-Daemon auf Knotenebene festzulegen und sicherzustellen, dass Manipulationen an zur Laufzeit im Container vorhandenen Binärdateien sowie an der Konfiguration erkannt werden können.

  2. Protokollweiterleitung mit Fluent Bit: Vorgehensweise zum Aktivieren einer zentralen Protokollerfassung, die den Verlust von Ablehnungen aufgrund lokaler Manipulationen von Protokollen verhindern kann.

  3. Überwachung mit Prometheus und Grafana: Vorgehensweise zum Aktivieren der Beobachtbarkeit von Cluster- und Systemmetriken für Warnungen und Visualisierungen, wobei plötzliche Spitzen beim Ressourcenverbrauch aufgrund von Denial-of-Service-Angriffen erkannt werden können.

Je nach der angegebenen relevanten Bedrohung können einige oder alle der oben genannten Steuerelemente auf einen Tanzu Kubernetes Grid-Cluster angewendet werden.

Cloud-Anbieter

Cloud-Anbieter fungieren als Underlay-Ressource für alle von Tanzu Kubernetes Grid bereitgestellten Kubernetes-Cluster. Dabei spielt es keine Rolle, ob es sich um eine lokale Bereitstellung (z. B. vSphere) oder um eine Public Cloud-Bereitstellung (z. B. AWS, Azure oder Google Cloud) handelt. Für die Sicherung der zugrunde liegenden Infrastruktur sind in der Regel die Kunden von Tanzu Kubernetes Grid und die Cloud-Anbieter gemeinsam verantwortlich. Bei Folgendem handelt es sich um Empfehlungen zur Verbesserung der Sicherheit der Cloud, die den von Tanzu Kubernetes Grid bereitgestellten Clustern zugrunde liegt:

  • Rotieren oder aktualisieren Sie Ihre Cloud-Anmeldedaten regelmäßig mithilfe dieser Anleitung (nur vSphere): Geheime Schlüssel für Tanzu-Cluster. (Bei automatisierter Rotation sollten Sie Tests in Nicht-Produktionsumgebungen durchführen, um mögliche Störungen zu beobachten und einzuplanen.)

  • Wenden Sie für Cloud-Anmeldedaten Berechtigungen nach dem Prinzip der geringsten Berechtigung an (siehe Beschreibung in der Dokumentation für AWS-, Azure- und vSphere-Anbieter). Führen Sie Verwaltungs- und Arbeitslastcluster nach Möglichkeit in separaten (VPCs) und Firewallzonen aus. Hierbei handelt es sich um die Standardeinstellung für von Tanzu Kubernetes Grid bereitgestellte Cluster.

  • SSH-Knotenzugriff, insbesondere auf Knoten der Steuerungsebene, sollte auf eine kleine Gruppe von Benutzern beschränkt werden, die die Rolle des Infrastrukturadministrators innehaben.

  • SSH-Zugriff sollte nur selten und hauptsächlich als Notzugriffsverfahren verwendet werden, wie z. B. beim Verlust der Anmeldedaten für den Verwaltungscluster.

  • Stellen Sie sicher, dass nicht authentifizierte Benutzer im Internet keinen Zugriff auf Clusterressourcen erhalten. Kunden mit geringer Risikobereitschaft sollten Cluster bereitstellen, ohne den API-Serverport mit der entsprechenden Lastausgleichskonfiguration im Internet zur Verfügung zu stellen.

  • Isolieren Sie die Tanzu Kubernetes Grid-Umgebung (Verwaltungs- und Arbeitslastcluster) in dedizierten VPCs oder hinter einer Firewall von anderen Tanzu-fremden Cloud-Arbeitslasten, um laterale Bewegungen zu beschränken und die Angriffsfläche im Falle eines beschädigten Clusters zu verringern.

  • Wenden Sie Notfallwiederherstellungsszenarien für clusterübergreifende Redundanz und Verfügbarkeit mehrerer Regionen an, testen und validieren Sie sie.

  • Implementieren Sie einen Plan zur Wiederherstellung nach Datenverlusten, die durch Datenbeschädigung, Ransomware-Angriffe oder Naturkatastrophen verursacht wurden und zu Schäden an der Hardware geführt haben.

  • Ziehen Sie die Verwendung nativer Sicherung und Wiederherstellung von Clusterressourcen mit Velero in Betracht, um bei der Planung der Notfallwiederherstellung und der Wiederherstellung von Daten Unterstützung zu leisten.

Diese Empfehlungen gelten zusätzlich zu den allgemeinen Anweisungen zur Sicherheit für alle Cloud-Anbieter. Allgemeine Anleitungen zur Cloud-Sicherheit finden Sie in der offiziellen Sicherheitsdokumentation des jeweiligen Cloud-Anbieters.

Abschließend bietet dieses Dokument einen umfassenden Überblick über den aktuellen Stand der Technik und empfohlene Sicherheitskontrollen, die auf Tanzu Kubernetes Grid angewendet werden können. Unser Ziel ist es, Tanzu Kubernetes Grid mit jeder neuen Version noch sicherer zu machen und dabei den Wunsch nach einem reibungslosen Entwicklererlebnis zu berücksichtigen.

Wenn Sie Feedback zum Dokument geben oder Funktionen im Rahmen der Sicherheit anfordern möchten, wenden Sie sich an Ihren VMware-Vertreter.

Verweise

Von der Upstream-Community geführte Ressourcen

Hierbei handelt es sich um einige von der Upstream-Community (CNCF/Kubernetes) betriebene sicherheitsrelevante Ressourcen:

Standards und Richtlinien von Drittanbietern

Nachfolgend finden Sie eine Liste der Dokumente, die von Behörden und Normungsgremien veröffentlicht wurden, in zufälliger Reihenfolge:

check-circle-line exclamation-circle-line close-line
Scroll to top icon