Best Practices für die Sicherheit von Cloud Service Mesh mit Istio APIs

In diesem Dokument werden Best Practices zum Einrichten und Steuern einer sicheren Cloud Service Mesh-Konfiguration beschrieben, die in Google Kubernetes Engine (GKE) ausgeführt wird. Die Anleitungen in der Dokument geht über die Einstellungen hinaus, die zum Konfigurieren und Bereitstellen von Cloud Service Mesh verwendet werden und beschreibt, wie Sie Cloud Service Mesh mit anderen Google Cloud-Produkten Produkte und Funktionen zum Schutz vor Sicherheitsbedrohungen, in einem Mesh-Netzwerk gegenüberstellen.

Die Zielgruppe dieses Dokuments sind Administratoren, die Richtlinien in einem Cloud Service Mesh und Dienstinhabern, die Dienste in einem Cloud Service Mesh. Die hier beschriebenen Sicherheitsmaßnahmen sind auch für Organisationen nützlich, die die Sicherheit ihrer Service Meshes erhöhen müssen, um Compliance-Anforderungen zu erfüllen.

Das Dokument ist so aufgebaut:

Einleitung

Cloud Service Mesh bietet Features und Tools, mit denen Sie Dienste auf einheitliche Weise beobachten, verwalten und schützen können. Es verfolgt einen anwendungsorientierten Ansatz und verwendet vertrauenswürdige Anwendungsidentitäten anstelle eines auf Netzwerk-IP ausgerichteten Ansatzes. Sie können ein Service Mesh transparent bereitstellen, ohne vorhandenen Anwendungscode ändern zu müssen. Cloud Service Mesh bietet eine deklarative Steuerung des Netzwerkverhaltens, wodurch die Arbeit von Teams entkoppelt wird, d. h. die Bereitstellung und Freigabe von Anwendungsfeatures ist getrennt von den Verantwortlichkeiten der Administratoren, die für Sicherheit und Netzwerk verantwortlich sind.

Cloud Service Mesh basiert auf Open Source Istio Service Mesh, das komplexe Konfigurationen und Topologien ermöglicht. Je nach Struktur Ihrer Organisation sind möglicherweise mehrere Teams oder Rollen für die Installation und Konfiguration eines Mesh-Netzwerks verantwortlich. Die Standardeinstellungen von Cloud Service Mesh werden zum Schutz der Anwendungen ausgewählt. In einigen Fällen müssen Sie jedoch benutzerdefinierte Konfigurationen verwenden oder Ausnahmen gewähren, indem Sie bestimmte Anwendungen, Ports oder IP-Adressen von der Teilnahme an einem Mesh-Netzwerk ausschließen. Kontrollen zur Steuerung von Mesh-Konfigurationen und Sicherheitsausnahmen sind wichtig.

Dieses Dokument ergänzt die Dokumentation zu den Best Practices für die Sicherheit von Istio, die detaillierte Konfigurationsempfehlungen für gegenseitige TLS (mTLS), Autorisierungsrichtlinien, Gateways und andere Sicherheitskonfigurationen umfasst. Sie sollten diese Empfehlungen als Grundlage behandeln und zusammen mit den in diesem Dokument beschriebenen Best Practices verwenden. In diesem Dokument werden zusätzliche Best Practices für Cloud Service Mesh beschrieben und wie Technologien in Google Cloud alle Ebenen, Komponenten und Informationsflüsse in einem Mesh-Netzwerk schützen können.

Angriffsvektoren und Sicherheitsrisiken

Angriffsvektoren

Die Sicherheit von Cloud Service Mesh folgt dem Zero-Trust-Sicherheitsmodell. Dabei gehen wir davon aus, dass Sicherheitsbedrohungen innerhalb und außerhalb eines Sicherheitsbereich des Unternehmens. Im Folgenden finden Sie Beispiele für Sicherheitsangriffe, die Anwendungen in einem Service Mesh gefährden können:

  • Daten-Exfiltration-Angriffe. Beispielsweise Angriffe, die sensible Daten oder Anmeldedaten aus Dienst-zu-Dienst-Traffic abhören.
  • Man-in-the-Middle-Angriffe. Beispiel: Ein schädlicher Dienst, der sich als legitimer Dienst maskiert, um die Kommunikation zwischen Diensten zu abzurufen oder zu ändern.
  • Angriffe auf Rechteausweitung. Beispielsweise Angriffe, die unberechtigten Zugriff auf erweiterte Berechtigungen zum Ausführen von Vorgängen in einem Netzwerk nutzen.
  • DoS-Angriffe (Denial of Service).
  • Botnet-Angriffe, die versuchen, Dienste zu manipulieren und zu bearbeiten, um Angriffe auf andere Dienste zu starten.

Die Angriffe können auch anhand der Angriffsziele kategorisiert werden:

  • Angriffe auf das interne Mesh-Netzwerk. Angriffe, mit denen die interne Kommunikation zwischen Diensten oder Diensten und der Steuerungsebene manipuliert, abgehört oder gespooft werden soll.
  • Angriffe auf die Steuerungsebene. Angriffe, die darauf abzielen, die Steuerungsebene zu beeinträchtigen (z. B. ein DoS-Angriff) oder sensible Daten aus der Steuerungsebene exfiltrieren.
  • Angriffe auf das Mesh-Netzwerk am Edge. Angriffe, die auf das Manipulieren, Abhören oder Spoofing der Kommunikation für ein- oder ausgehenden Traffic im Mesh-Netzwerk abzielen.
  • Angriffe auf Vorgänge im Mesh-Netzwerk. Angriffe auf die Vorgänge im Mesh-Netzwerk. Angreifer könnten sich erweiterte Berechtigungen für schädliche Operationen in einem Mesh-Netzwerk zu verschaffen, z. B. die Änderung der Sicherheitsrichtlinien und Arbeitslast-Images.

Sicherheitsrisiken

Neben Sicherheitsangriffen hat ein Mesh-Netzwerk auch andere Sicherheitsrisiken. In der folgenden Liste werden einige mögliche Sicherheitsrisiken beschrieben:

  • Unvollständiger Schutzmaßnahmen für die Sicherheit. Ein Service Mesh wurde nicht mit Authentifizierungs- und Autorisierungsrichtlinien zum Schutz der Sicherheit konfiguriert. Beispielsweise wurden für Dienste in einem Mesh keine Authentifizierungs- oder Autorisierungsrichtlinien definiert.
  • Ausnahmen von Sicherheitsrichtlinien. Um ihren spezifischen Anwendungsfällen gerecht zu werden, erstellen möglicherweise Ausnahmen von Sicherheitsrichtlinien für bestimmten Traffic (interne oder extern) von Cloud Service Mesh-Sicherheitsrichtlinien ausgeschlossen werden. Informationen zur sicheren Handhabung solcher Fälle finden Sie in diesem Dokument unter Ausnahmen von Richtlinien sicher einrichten.
  • Vernachlässigung der Image-Upgrades. Möglicherweise werden Sicherheitslücken für die Images entdeckt die in einem Mesh-Netzwerk verwendet werden. Sie müssen die Mesh-Komponenten- und Arbeitslast-Images mit den neuesten Fehlerkorrekturen auf dem neuesten Stand halten.
  • Mangelnde Wartung (keine Fachkenntnisse oder Ressourcen). Die Mesh-Software und Richtlinienkonfigurationen erfordern eine regelmäßige Wartung, um die neuesten Sicherheitsmechanismen zu nutzen.
  • Mangelnde Sichtbarkeit. Fehlkonfigurationen oder unsichere Konfigurationen von Mesh-Richtlinien und abnormaler Traffic oder abnormale Vorgänge im Mesh-Netzwerk werden von Mesh-Administratoren nicht erkannt.
  • Konfigurationsabweichung. Die Konfiguration von Richtlinien in einem Mesh-Netzwerk weicht von der "Source of Truth" ab.

Maßnahmen zum Schutz eines Service Mesh

In diesem Abschnitt wird ein Betriebshandbuch zum Sichern von Service Mesh vorgestellt.

Sicherheitsarchitektur

Die Sicherheit eines Service Mesh hängt von der Sicherheit der Komponenten auf verschiedenen Ebenen des Mesh-Systems und seiner Anwendungen ab. Die allgemeine Ziel des vorgeschlagenen Cloud Service Mesh-Sicherheitsstatus ist es, einen Dienst zu sichern durch die Integration mehrerer Sicherheitsmechanismen auf verschiedenen Schichten, im Rahmen des Zero-Trust-Sicherheitsmodells gemeinsam die allgemeine Systemsicherheit zu erreichen. Das folgende Diagramm zeigt die vorgeschlagene Sicherheitslage des Cloud Service Mesh.

Sicherheitslage von Cloud Service Mesh

Cloud Service Mesh bietet Sicherheit auf mehreren Ebenen, darunter:

  • Sicherheit am Edge des Mesh-Netzwerks
    • Ingress-Sicherheit von Cloud Service Mesh bietet Zugriffssteuerung für externe und sichert den externen Zugriff auf die von den Diensten bereitgestellten APIs. im Mesh-Netzwerk.
    • Die Cloud Service Mesh-Sicherheit für ausgehenden Traffic reguliert den ausgehenden Traffic von internen Arbeitslasten.
    • Cloud Service Mesh-Nutzerauthentifizierung lässt sich in die Google-Infrastruktur einbinden, um externe Aufrufe zu authentifizieren von Webbrowsern bis hin zu Diensten, die Webanwendungen ausführen.
    • Die Gateway-Zertifikatsverwaltung von Cloud Service Mesh schützt und rotiert die privaten Schlüssel und X.509-Zertifikate, die von Cloud Service Mesh für eingehende und ausgehende Gateways mit Certificate Authority Service verwendet werden.
    • VPC und VPC Service Controls schützen das Edge des Mesh-Netzwerks durch die private Netzwerkzugriffssteuerung.
  • Clustersicherheit
    • Cloud Service Mesh – Gegenseitiges TLS (mTLS) erzwingt die Verschlüsselung und Authentifizierung von Traffic zwischen Arbeitslasten.
    • Die Cloud Service Mesh-Zertifizierungsstelle stellt von den Arbeitslasten verwendete Zertifikate sicher bereit und verwaltet sie.
    • Cloud Service Mesh-Autorisierung erzwingt Zugriffssteuerung für Mesh-Dienste basierend auf ihrer Identität und anderen Attributen.
    • Das GKE Enterprise-Sicherheitsdashboard ermöglicht das Monitoring der Konfigurationen von Sicherheitsrichtlinien und Kubernetes-Netzwerkrichtlinien für die Arbeitslasten.
    • Die Kubernetes-Netzwerkrichtlinie erzwingt die Zugriffssteuerung für Pods anhand von IP-Adressen, Pod-Labels, Namespaces und mehr.
  • Arbeitslastsicherheit
    • Bleiben Sie mit den Sicherheitsupdates von Cloud Service Mesh auf dem neuesten Stand, um zu gewährleisten, dass die in Ihrem Mesh-Netzwerk ausgeführten Cloud Service Mesh-Binärdateien frei von öffentlich bekannten Sicherheitslücken sind.
    • Identitätsföderation von Arbeitslasten für GKE Ermöglicht es Arbeitslasten, Anmeldedaten für den sicheren Aufruf von Google-Diensten abzurufen.
    • Der Cloud Key Management Service (Cloud KMS) schützt sensible Daten oder Anmeldedaten über Hardwaresicherheitsmodule (HSM). Arbeitslasten können beispielsweise mit Cloud KMS Anmeldedaten oder andere sensible Daten speichern. CA Service wird zum Ausstellen von Zertifikaten für Mesh-Arbeitslasten verwendet und unterstützt Kunden- und HSM-basierte Signaturschlüssel, die von Cloud KMS verwaltet werden.
    • Die Kubernetes Container Network Interface (CNI) verhindert Angriffe auf die Eskalation von Berechtigungen, da kein privilegierter Cloud Service Mesh-Init-Container benötigt wird.
  • Operatorsicherheit
    • Die rollenbasierte Zugriffssteuerung von Kubernetes (RBAC) beschränkt den Zugriff auf Kubernetes-Ressourcen und die Operatorberechtigungen, um Angriffe durch böswillige Operatoren oder Operator-Identitätsdiebstahl zu minimieren.
    • GKE Enterprise Policy Controller validiert und prüft Richtlinienkonfigurationen im Mesh-Netzwerk, um Fehlkonfigurationen zu verhindern.
    • Die Google Cloud-Binärautorisierung sorgt dafür, dass die im Mesh-Netzwerk enthaltenen Arbeitslast-Images mit den Images identisch sind, die von den Administratoren autorisiert werden.
    • Cloud-Audit-Logs prüft Mesh-Vorgänge.

Das folgende Diagramm zeigt die Kommunikations- und Konfigurationsabläufe mit den integrierten Sicherheitslösungen in Cloud Service Mesh.

Ablauf des Sicherheits-Traffics

Clustersicherheit

In diesem Abschnitt werden Best Practices im Zusammenhang mit der Clustersicherheit beschrieben.

Strikte mTLS-Authentifizierung aktivieren

Bei einem Man-in-the-Middle-Angriff (MitM) wird versucht, eine schädliche Entität zwischen zwei Hackergruppen um die Kommunikation zu überwachen oder zu manipulieren. Cloud Service Mesh schützt vor MitM- und Daten-Exfiltrationsangriffen, indem mTLS-Authentifizierung und -Verschlüsselung für alle kommunizierenden Parteien. Im Modus „Moderat“ wird mTLS verwendet, wenn beide Seiten dies unterstützen, aber Verbindungen ohne mTLS zulässig sind. Im Gegensatz dazu erfordert die strikte mTLS-Authentifizierung, dass der Traffic mit mTLS verschlüsselt und authentifiziert wird, und es wird kein Traffic im Nur-Text-Format zugelassen.

Mit Cloud Service Mesh können Sie die Mindestversion von TLS für die TLS-Verbindungen zwischen Ihren Arbeitslasten konfigurieren, um Ihre Sicherheits- und Complianceanforderungen zu erfüllen.

Weitere Informationen finden Sie unter Cloud Service Mesh am Beispiel: mTLS | Mesh-weites mTLS erzwingen.

Zugriffssteuerungen aktivieren

Wir empfehlen, Cloud Service Mesh-Sicherheitsrichtlinien (z. B. Authentifizierungs- und Autorisierungsrichtlinien) für den gesamten eingehenden und ausgehenden Traffic erzwungen werden. des Mesh-Netzwerks, es sei denn, es gibt sind überzeugende Gründe für den Ausschluss eines Dienstes oder Pods aus dem Cloud Service Mesh Sicherheitsrichtlinien. In einigen Fällen können Nutzer berechtigte Gründe haben, sie zu umgehen Cloud Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Adressen um native Verbindungen zu Diensten herzustellen, nicht vom Cloud Service Mesh verwaltet. Zum Sichern des Cloud Service Mesh mit solchen Anwendungsfällen, siehe Sichere Verarbeitung von Cloud Service Mesh-Richtlinienausnahmen:

Die Dienstzugriffskontrolle ist wichtig, um unbefugten Zugriff auf Dienstleistungen. Mit der mTLS-Erzwingung wird eine Anfrage verschlüsselt und authentifiziert, aber ein Mesh-Netzwerk ist weiterhin vorhanden. braucht Cloud Service Mesh-Autorisierungsrichtlinien um Zugriffskontrollen für Dienste zu erzwingen, z. B. durch Ablehnen nicht autorisierter Anfrage von einem authentifizierten Client.

Mit Cloud Service Mesh-Autorisierungsrichtlinien können Sie Zugriffssteuerungen flexibel konfigurieren, um Ihre Dienste vor unbefugtem Zugriff zu schützen. Cloud Service Mesh-Autorisierungsrichtlinien sollten anhand der authentifizierten Identitäten erzwungen werden, die aus den Authentifizierungsergebnissen abgeleitet wurden. mTLS- oder JWT-Authentifizierungen (JSON Web Token) können zusammen im Rahmen der Cloud Service Mesh-Autorisierungsrichtlinien verwendet werden.

Cloud Service Mesh-Authentifizierungsrichtlinien erzwingen

Beachten Sie bei der Auswahl von Cloud Service Mesh-Authentifizierungsrichtlinien die folgenden Punkte.

JSON-Webtoken (JWT)

Zusätzlich zur mTLS-Authentifizierung können Mesh-Administratoren von einem Dienst erfordern, dass Anfragen über JWT authentifiziert und autorisiert werden. Cloud Service Mesh agiert nicht als JWT-Anbieter, authentifiziert JWTs jedoch anhand des konfigurierte JWKS-Endpunkte (JSON Web Key Set) Die JWT-Authentifizierung kann auf Eingangsgateways für externen Traffic oder auf interne Dienste innerhalb des Mesh-Netzwerks angewendet werden. Die JWT-Authentifizierung kann mit der mTLS-Authentifizierung kombiniert werden, wenn ein JWT als Anmeldedaten zur Darstellung des Endnutzers verwendet wird. Der angeforderte Dienst erfordert einen Nachweis, dass er im Namen des Endnutzers aufgerufen wird. Die JWT-Authentifizierung schützt vor Angriffen, die ohne gültige Anmeldedaten und im Namen eines tatsächlichen Endnutzers auf einen Dienst zugreifen.

Cloud Service Mesh-Nutzerauthentifizierung

Die Cloud Service Mesh-Nutzerauthentifizierung ist eine integrierte Lösung für die browserbasierte Endnutzerauthentifizierung und Zugriffssteuerung für Ihre Arbeitslasten. Ein Service Mesh wird in die vorhandene Identität eingebunden. Anbieter (IdP), die eine standardmäßige webbasierte OpenID Connect-Anmeldung (OIDC) implementieren sowie die Autorisierung durch das Cloud Service Mesh. Richtlinien für die Zugriffssteuerung.

Autorisierungsrichtlinien erzwingen

Cloud Service Mesh-Autorisierungsrichtlinien steuern:

  • Wer oder was Zugriff auf einen Dienst hat
  • Auf welche Ressourcen zugegriffen werden kann
  • Welche Vorgänge für die zulässigen Ressourcen ausgeführt werden können

Mit Autorisierungsrichtlinien kann die Zugriffssteuerung basierend auf den tatsächlichen Identitäten, als die Dienste ausgeführt werden, auf den Attributen der Anwendungsebene (Ebene 7) (z. B. Anfrageheader) und der Netzwerkebene (Ebene 3 und Ebene 4) wie IP-Bereiche und Ports vielseitig konfiguriert werden.

Wir empfehlen, Cloud Service Mesh-Autorisierungsrichtlinien zu erzwingen basierend auf authentifizierten Identitäten, die aus Authentifizierungsergebnissen abgeleitet wurden, um vor unbefugtem Zugriff auf Dienste oder Daten.

Zugriff auf einen Dienst standardmäßig ablehnen, sofern keine Autorisierungsrichtlinie vorhanden ist explizit definiert ist, um den Zugriff auf den Dienst zu ermöglichen. Beispiele für Autorisierungsrichtlinien, die Zugriffsanfragen verweigern, finden Sie unter Best Practices für Autorisierungsrichtlinien.

Autorisierungsrichtlinien sollen das Vertrauen so weit wie möglich einschränken. Der Zugriff auf einen Dienst kann beispielsweise basierend auf einzelnen URL-Pfaden definiert werden, die von einem Dienst bereitgestellt werden, sodass nur Dienst A auf den Pfad /admin von Dienst B zugreifen kann.

Autorisierungsrichtlinien können zusammen mit Kubernetes-Netzwerkrichtlinien die nur in der Netzwerkschicht (Schicht 3 und Schicht 4) arbeiten und Netzwerkzugriff für IP-Adressen und Ports auf Kubernetes-Pods und Kubernetes Namespaces.

Tokenaustausch für den Zugriff auf Mesh-Dienste erzwingen

Zum Schutz vor Token-Replay-Angriffen, bei denen Tokens gestohlen und gestohlene Tokens wiederverwendet werden. Tokens für den Zugriff auf Mesh-Dienste verwenden, sorgen Sie dafür, dass ein Token in einer Anfrage von außerhalb wird das Mesh-Netzwerk am Rand des Mesh-Netzwerks gegen ein kurzlebiges, internes Token ausgetauscht.

Eine Anfrage von außerhalb des Mesh-Netzwerks für den Zugriff auf einen Mesh-Dienst muss ein Token wie JWT oder Cookie enthalten, um vom Mesh-Dienst authentifiziert und autorisiert zu werden. Ein Token von außerhalb des Mesh-Netzwerks kann langlebig sein. Zum Schutz vor Tokenwiederholungsangriffen sollte ein Token von außerhalb des Mesh-Netzwerks gegen ein kurzlebiges Mesh-internes Token mit einem eingeschränkten Bereich am Ingress des Mesh ausgetauscht werden. Der Mesh-Dienst authentifiziert ein Mesh-internes Token und autorisiert die Zugriffsanfrage anhand des Mesh-internen Tokens.

Cloud Service Mesh unterstützt die Einbindung in Identity-Aware Proxy (IAP), die ein RequestContextToken (ein kurzlebiges Mesh-internes Token, eingetauscht gegen ein externes Token) generiert, das in Cloud Service Mesh für die Autorisierung verwendet wird. Mit Token austauschen, können Angreifer kein Token verwenden, das im Mesh-Netzwerk gestohlen wurde, um auf Dienstleistungen. Der begrenzte Umfang und die Lebensdauer des ausgetauschten Tokens verringern die Wahrscheinlichkeit eines Angriffs durch Tokenwiederholung.

Ausnahmen von Cloud Service Mesh-Richtlinien sicher einrichten

Möglicherweise haben Sie spezielle Anwendungsfälle für Ihr Service Mesh. Es kann beispielsweise erforderlich sein, einen bestimmten Netzwerkport verfügbar zu machen, um den Texttraffic zu verarbeiten. Um bestimmte Nutzungsszenarien zu berücksichtigen, müssen Sie manchmal Ausnahmen erstellen, damit bestimmte interne oder externe Zugriffe von Cloud Service Mesh-Sicherheitsrichtlinien ausgeschlossen werden. Dies führt zu Sicherheitsproblemen.

Sie können berechtigte Gründe haben, Cloud Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Bereiche. Sie können Anmerkungen (z. B. excludeInboundPorts, excludeOutboundPorts und excludeOutboundIPRanges) zu Pods hinzufügen, um Traffic von der Verarbeitung durch den Envoy-Sidecar auszuschließen. Neben Anmerkungen zum Ausschließen von Traffic können Sie das Mesh-Netzwerk auch umgehen. indem Sie eine Anwendung mit Sidecar-Einschleusung deaktiviert: indem Sie beispielsweise das Label sidecar.istio.io/inject="false" zum Anwendungs-Pod.

Das Umgehen von Cloud Service Mesh-Sicherheitsrichtlinien wirkt sich negativ auf für die allgemeine Systemsicherheit. Wenn beispielsweise Cloud Service Mesh-mTLS und -Autorisierungsrichtlinien für einen Netzwerkport mithilfe von Anmerkungen umgangen werden, gibt es keine Zugriffssteuerung für den Traffic am Port und Abhören oder Trafficänderungen werden möglich. Darüber hinaus wirkt sich die Umgehung von Cloud Service Mesh-Richtlinien auch auf Richtlinien aus, die nicht sicherheitsrelevant sind, z. B. Netzwerkrichtlinien.

Wenn die Cloud Service Mesh-Sicherheitsrichtlinie für einen Port oder eine IP-Adresse (absichtlich oder unbeabsichtigt) umgangen wird, empfehlen wir dringend, andere Sicherheitsmaßnahmen zu ergreifen, um das Mesh-Netzwerk zu sichern sowie Sicherheitsausnahmen, potenzielle Sicherheitslücken und den Status der allgemeinen Sicherheitserzwingung zu überwachen. So sichern Sie das Mesh-Netzwerk in solchen Szenarien:

  • Traffic, der die Sidecars umgeht, muss nativ verschlüsselt und authentifiziert, um MitM-Angriffe zu verhindern.
  • Erzwingen Sie Kubernetes-Netzwerkrichtlinien, um die Konnektivität von Ports mit Richtlinienausnahmen einzuschränken. Sie können beispielsweise einen Port mit Richtlinienausnahmen so einschränken, dass nur Traffic von einem anderen Dienst im selben Namespace zugelassen wird, oder nur Traffic durch die Ports zulassen, für die die Cloud Service Mesh-Sicherheitsrichtlinie erzwungen wird.

Mit GitOps-Ansatz und Config Sync Konfigurationsabweichungen verhindern

Konfigurationsabweichungen treten auf, wenn die Konfiguration von Richtlinien in einem Mesh von ihrer "Source of Truth" abweicht. Mit Config Sync können Sie Konfigurationsabweichungen verhindern.

Cloud-Audit-Logs und Monitoring erzwingen

Wir empfehlen, dass Mesh-Administratoren Folgendes beobachten:

Administratoren können diese Ressourcen zur Beobachtung verwenden, um zu prüfen, ob die Sicherheitskonfiguration wie erwartet funktioniert, und um Ausnahmen von der Erzwingung von Sicherheitsrichtlinien zu überwachen. Beispiel: Zugriff, der nicht über Sidecars geleitet wurde, Zugriff, der keine gültigen Anmeldedaten hatte, aber einen Dienst erreicht hat.

Open-Source-Beobachtbarkeitssoftware (z. B. Prometheus) kann zwar mit Cloud Service Mesh verwendet werden, doch wird dringend empfohlen, Google Cloud Observability zu verwenden. Diese integrierte Beobachtbarkeitslösung für Google Cloud bietet vollständig verwaltete Funktionen für Logging, Messwerterfassung, Monitoring und Benachrichtigungen.

Arbeitslastsicherheit

Die Arbeitslastsicherheit schützt vor Angriffen, bei denen Arbeitslast-Pods manipuliert und diese manipulierten Pods dann für Angriffe auf den Cluster (z. B. Botnet-Angriffe) genutzt werden.

Pod-Berechtigungen einschränken

Ein Kubernetes-Pod kann Berechtigungen haben, die sich auf andere Pods auf dem Knoten oder auf dem Cluster. Es ist wichtig, Sicherheitseinschränkungen für Arbeitslast-Pods zu erzwingen, um zu verhindern, dass ein manipulierter Pod Angriffe auf den Cluster startet.

So erzwingen Sie das Prinzip der geringsten Berechtigung für die Arbeitslasten auf einem Pod:

  • Die in einem Mesh-Netzwerk bereitgestellten Dienste sollten mit möglichst wenigen Berechtigungen ausgeführt werden.
  • Sie können Cloud Service Mesh so konfigurieren, dass es einen init-Container verwendet, um die iptables-Trafficweiterleitung an die Sidecar-Datei einzurichten. Dazu muss der Nutzer Arbeitslasten-Deployments mit Berechtigungen zum Bereitstellen von Containern mit den Funktionen NET_ADMIN und NET_RAW erstellen. Um das Risiko der Ausführung von Containern zu vermeiden mit erweiterten Berechtigungen können Mesh-Administratoren aktivieren das Istio CNI-Plug-in zum Konfigurieren der Traffic-Weiterleitung zu Sidecars.

Container-Images sichern

Angreifer können Angriffe starten, indem sie anfällige Container-Images ausnutzen. Administratoren sollten die Binärautorisierung erzwingen, um die Integrität von Container-Images zu prüfen und sicherzustellen, dass nur vertrauenswürdige Container-Images im Mesh bereitgestellt werden.

Sicherheitslücken in Mesh-Netzwerken minimieren

  • Artefaktanalyse kann Sicherheitslücken in GKE-Arbeitslasten scannen und aufdecken.
  • Umgang mit gängigen Sicherheitslücken und Schwachstellen (Common Vulnerabilities and Exposures, CVEs). In einem Container-Image erkannte Sicherheitslücken können von den Mesh-Administratoren so schnell wie möglich behoben werden. Google übernimmt das Patching automatisch CVEs, die sich auf die Mesh-Images auswirken.

Mit der Identitätsföderation von Arbeitslasten für GKE sicher auf Google-Dienste zugreifen

Workload Identity-Föderation für GKE ist die empfohlene Methode für Mesh-Arbeitslasten, um sicher auf Google-Dienste zuzugreifen. Die Alternative zum Speichern eines Dienstkontoschlüssels in einem Kubernetes-Secret und zur Verwendung des Dienstkontoschlüssels für den Zugriff auf Google-Dienste ist aufgrund der Risiken von Datenlecks, Rechteausweitung, Offenlegung von Informationen und Nachweisbarkeit nicht so sicher.

Sicherheitsstatus über Sicherheitsdashboard und Telemetrie überwachen

Bei einem Service Mesh kann es Sicherheitsausnahmen und potenzielle Schlupflöcher geben. Es ist wichtig, den Sicherheitsstatus eines Mesh-Netzwerks aufzuzeigen und zu überwachen. Dazu gehören die erzwungenen Sicherheitsrichtlinien, Sicherheitsausnahmen und potenzielle Sicherheitslücken im Mesh-Netzwerk. Sie können das GKE Enterprise-Sicherheitsdashboard verwenden. und Telemetrie, um den Sicherheitsstatus des Mesh-Netzwerks zu ermitteln und zu überwachen.

Telemetrie überwacht den Zustand und die Leistung von Diensten in einem Mesh-Netzwerk, sodass Mesh-Administratoren das Verhalten von Diensten (z. B. SLOs, abnormaler Traffic, Dienstausfall, Topologie) beobachten können.

Das GKE Enterprise-Sicherheitsdashboard zeigt die Sicherheitsrichtlinien an, die auf eine Arbeitslast in einem Service Mesh angewendet werden, einschließlich Zugriffssteuerungsrichtlinien (Kubernetes-Netzwerkrichtlinien, Richtlinien für die Binärautorisierung und Richtlinien für die Dienstzugriffssteuerung) und Authentifizierungsrichtlinien (mTLS).

Sicherheit für vertrauliche Nutzerdaten und Anmeldedaten

Wenn Sie vertrauliche Nutzerdaten oder Anmeldedaten im nichtflüchtigen Clusterspeicher speichern, z. B. Kubernetes-Secrets oder direkt in Pods, sind die Daten oder Anmeldedaten anfällig für Angriffe durch Pods oder schädliche Vorgänge. Die Daten sind auch anfällig für Netzwerkangriffe, wenn sie zur Authentifizierung bei Diensten über das Netzwerk übertragen werden.

  • Speichern Sie vertrauliche Nutzerdaten und Anmeldedaten nach Möglichkeit in einem geschützten Speicher wie Secret Manager und Cloud KMS.
  • Legen Sie separate Namespaces für Kubernetes-Pods fest, die auf vertrauliche Daten zugreifen, und definieren Sie Kubernetes-Richtlinien, damit die Namespaces nicht von anderen Namespaces aus zugänglich sind. Segmentieren Sie die Rollen, die für Vorgänge verwendet werden, und erzwingen Sie Namespace-Grenzen.
  • Erzwingen Sie den Tokenaustausch, um die Exfiltration von langlebigen Tokens mit hohen Berechtigungen zu verhindern.