Best Practices für die Sicherheit von Cloud Service Mesh

In diesem Dokument werden Best Practices zur Einrichtung und Steuerung einer sicheren Cloud Service Mesh Konfiguration, die in Google Kubernetes Engine (GKE) ausgeführt wird Die Anleitungen in der Dokument geht über die Einstellungen hinaus, die zum Konfigurieren und Installieren 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überliegen.

Die Zielgruppe dieses Dokuments sind Administratoren, die Richtlinien in einem Cloud Service Mesh und Nutzer, die Dienste in einem Cloud Service Mesh ausführen. 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 sicher Dienste auf einheitliche Weise bereitstellen 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 deklarative Kontrolle über das Netzwerk Verhalten, was dazu beiträgt, die Arbeit von Teams zu entkoppeln, die für Bereitstellung und Freigabe von Anwendungsfunktionen 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 für Cloud Service Mesh wurden ausgewählt zum Schutz von Anwendungen. In einigen Fällen müssen Sie jedoch oder Ausnahmen gewähren, indem bestimmte Apps, Ports oder IP-Adressen aus einem Mesh-Netzwerk. Kontrollen zur Steuerung von Mesh-Konfigurationen und Sicherheitsausnahmen sind wichtig.

Angriffsvektoren und Sicherheitsrisiken

Angriffsvektoren

Die Sicherheit von Cloud Service Mesh folgt dem Zero-Trust-Sicherheitsmodell, Sicherheitsbedrohungen entstehen innerhalb und außerhalb der Sicherheitsbereich. 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 versuchen möglicherweise, erweiterte Berechtigungen zu erhalten, um böswillige Vorgänge in einem Mesh-Netzwerk auszuführen, wie z. B. Ändern 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) aus den Cloud Service Mesh-Sicherheitsrichtlinien ausgeschlossen werden. Informationen zur sicheren Handhabung solcher Fälle finden Sie im Abschnitt Ausnahmen von Richtlinien sicher einrichten.
  • Vernachlässigung der Image-Upgrades. Für die in einem Mesh-Netzwerk verwendeten Images können Sicherheitslücken erkannt 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 bzw. 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 den vorgeschlagenen Cloud Service Mesh-Sicherheitsstatus.

Sicherheitsstatus des 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.
    • Zertifikatsverwaltung des Cloud Service Mesh-Gateways die privaten Schlüssel und X.509-Zertifikate schützt und rotiert, Cloud Service Mesh-Gateways für eingehenden und ausgehenden Traffic mit Certificate Authority Service.
    • Cloud Armor kann sich vor externe Distributed-Denial-of-Service- (DDoS)- und Layer-7-Angriffe. Es dient als Web Application Firewall (WAF), um das Mesh-Netzwerk vor Netzwerkangriffen zu schützen. Zum Beispiel Angriffe durch Injektion und Remote-Codeausführung.
    • VPC und VPC Service Controls schützen das Edge des Mesh-Netzwerks durch die private Netzwerkzugriffssteuerung.
  • Clustersicherheit
    • Gegenseitiges TLS (mTLS) von Cloud Service Mesh erzwingt Arbeitslast-zu-Arbeitslast-Traffic Verschlüsselung und Authentifizierung.
    • Verwaltete Zertifizierungsstelle, z. B. Cloud Service Mesh-Zertifizierungsstelle und Certificate Authority Service, stellt die verwendeten Zertifikate sicher bereit und verwaltet sie. durch die Arbeitslasten.
    • Cloud Service Mesh-Autorisierung erzwingt Zugriffssteuerung für Mesh-Dienste basierend auf ihrer Identität und anderen Attributen.
    • GKE Enterprise-Sicherheitsdashboard 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.
    • Die Sicherheit der Steuerungsebene schützt vor Angriffen auf der Steuerungsebene. Dieser Schutz verhindert, dass Angreifer Dienst- und Mesh-Konfigurationsdaten ändern, ausnutzen oder umgehen.
  • Arbeitslastsicherheit
    • Bleiben Sie mit den Sicherheitsreleases von Cloud Service Mesh auf dem Laufenden, um sicherzustellen, In Ihrem Mesh ausgeführte Cloud Service Mesh-Binärdateien sind frei von öffentlich bekannten Sicherheitslücken.
    • Mit Workload Identity können Arbeitslasten Anmeldedaten erhalten, um Google-Dienste sicher aufzurufen.
    • 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.
    • Kubernetes CNI (Container Network Interface) verhindert Berechtigungen Eskalationsangriffe, da keine privilegierten Initialisierungscontainer für Cloud Service Mesh
  • 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 zu verhindern, dass Fehlkonfigurationen.
    • 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.
    • Google Cloud-Audit-Logging prüft Mesh-Vorgänge.

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

Grafik: Trafficfluss des Sicherheitsdiagramms

Clustersicherheit

Strikte mTLS-Authentifizierung aktivieren

Bei MitM-Angriffen (Man-in-the-Middle) wird versucht, eine schädliche Entität zwischen zwei kommunizierenden Parteien einzufügen, um die Kommunikation abzuhören oder zu manipulieren. Cloud Service Mesh schützt vor MitM- und Daten-Exfiltrationsangriffen, indem mTLS-Authentifizierung und -Verschlüsselung für alle kommunizierenden Parteien. Der Modus "Moderat" verwendet mTLS, wenn von beiden Seiten unterstützt, lässt jedoch Verbindungen ohne mTLS zu. 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 Mindestversion für TLS konfigurieren für die TLS-Verbindungen zwischen Ihren Arbeitslasten, um Ihre Sicherheits- und Compliance-Anforderungen.

Weitere Informationen finden Sie unter Cloud Service Mesh by example: mTLS | mTLS für das gesamte Mesh-Netzwerk erzwingen

Zugriffssteuerungen aktivieren

Cloud Service Mesh-Sicherheitsrichtlinien (z. B. Authentifizierung und Autorisierung) Richtlinien) sollten für den gesamten eingehenden und ausgehenden Traffic des Mesh-Netzwerks erzwungen werden, es sei denn, es gibt sind gute Gründe, um einen Dienst oder Pod aus dem Cloud Service Mesh auszuschließen Sicherheitsrichtlinien. In einigen Fällen können Nutzer berechtigte Gründe haben, diese zu umgehen Cloud Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Bereiche. Zum Beispiel Sie stellen native Verbindungen zu Diensten her, die nicht von Cloud Service Mesh verwaltet werden. Bis sicheren Cloud Service Mesh in solchen Anwendungsfällen zu erhalten, finden Sie unter Sichere Verarbeitung von Cloud Service Mesh-Richtlinienausnahmen:

Die Dienstzugriffskontrolle ist entscheidend, um unbefugten Zugriff auf . Mit der mTLS-Erzwingung wird eine Anfrage verschlüsselt und authentifiziert, aber ein Mesh-Netzwerk ist weiterhin vorhanden. braucht Cloud Service Mesh-Autorisierungsrichtlinien um die Zugriffssteuerung für Dienste zu erzwingen. Beispielsweise werden nicht autorisierte Anfragen von authentifizierten Clients abgelehnt.

Cloud Service Mesh-Autorisierungsrichtlinien bieten eine flexible Möglichkeit, den Zugriff zu konfigurieren Kontrollen zum Schutz Ihrer Dienste vor unbefugtem Zugriff. Cloud-Service-Mesh Autorisierungsrichtlinien sollten basierend auf den authentifizierten Identitäten erzwungen werden Aus den Authentifizierungsergebnissen abgeleitet – auf mTLS- oder JSON-Webtoken (JWT) Authentifizierungen sollten im Rahmen der Cloud Service Mesh-Autorisierung gemeinsam verwendet werden Richtlinien.

Cloud Service Mesh-Authentifizierungsrichtlinien erzwingen

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

Cloud Service Mesh-Nutzerauthentifizierung ist eine integrierte Lösung für die browserbasierte Endnutzer-Authentifizierung und den Zugriff die Kontrolle über Ihre Arbeitslasten. Ein Service Mesh wird in die vorhandene Identität eingebunden. Anbieter (IdP), die eine standardmäßige webbasierte OpenID Connect-Anmeldung (OIDC) implementieren und dem Einwilligungsvorgang und nutzt Cloud Service Mesh-Autorisierungsrichtlinien für den Zugriff Steuerung.

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.

Cloud Service Mesh-Autorisierungsrichtlinien sollten basierend auf authentifizierten Daten erzwungen werden Identitäten, die aus den Authentifizierungsergebnissen abgeleitet wurden, um sich vor unautorisierten Zugriff auf Dienste oder Daten.

Standardmäßig sollte der Zugriff auf einen Dienst verweigert werden, sofern keine Autorisierungsrichtlinie explizit definiert ist, die den Zugriff auf diesen Dienst zulässt. Beispiele für Autorisierungsrichtlinien, die Zugriffsanfragen verweigern, finden Sie unter Best Practices für Autorisierungsrichtlinien.

Autorisierungsrichtlinien sollten 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 ein Dienst A auf den Pfad /admin eines Dienstes B zugreifen kann.

Autorisierungsrichtlinien können zusammen mit Kubernetes-Netzwerkrichtlinien verwendet werden, die nur auf der Netzwerkebene (Ebene 3 und Ebene 4) funktionieren und den Netzwerkzugriff für IP-Adressen und Ports auf Kubernetes-Pods und Kubernetes-Namespaces steuern.

Tokenaustausch für den Zugriff auf Mesh-Dienste erzwingen

Zum Schutz vor Tokenwiederholungsangriffen, bei denen Tokens gestohlen und die gestohlenen Tokens für den Zugriff auf Mesh-Dienste wiederverwendet werden, sollte ein Token in einer Anfrage von außerhalb des Mesh-Netzwerks gegen ein kurzlebiges Token innerhalb des Mesh-Netzwerks am Edge ausgetauscht werden.

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 Integration in Identity-Aware Proxy (IAP), wodurch ein RequestContextToken generiert wird (ein kurzlebiges, internes Mesh-Token). von einem externen Token ausgetauscht werden), das im Cloud Service Mesh zur Autorisierung verwendet wird. Mit dem Austausch von Tokens wird erreicht, dass Angreifer im Mesh-Netzwerk keine gestohlenen Tokens für den Zugriff auf Dienste verwenden können. Der begrenzte Umfang und die Lebensdauer des ausgetauschten Tokens verringern die Wahrscheinlichkeit eines Angriffs durch Tokenwiederholung.

Ausnahmen von Cloud Service Mesh-Richtlinien sicher verarbeiten

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 müssen Sie manchmal Ausnahmen erstellen, um bestimmte Interner oder externer Traffic, der von der Cloud Service Mesh-Sicherheit ausgeschlossen wird Richtlinien, was zu Sicherheitsbedenken führt.

Sie haben möglicherweise berechtigte Gründe, Cloud Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Bereiche. Sie können Anmerkungen (z. B. excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) an Pods, um Traffic von der Verarbeitung durch den Envoy-Sidecar. Neben Annotationen zum Ausschließen des Traffics können Sie das Mesh-Netzwerk komplett umgehen. Dazu stellen Sie eine Anwendung mit deaktivierter Sidecar-Injektion bereit. Fügen Sie beispielsweise dem Anwendungs-Pod das Label sidecar.istio.io/inject="false" hinzu:

Das Umgehen von Cloud Service Mesh-Sicherheitsrichtlinien wirkt sich negativ auf die Gesamtheit aus Systemsicherheit. Wenn z. B. Cloud Service Mesh mTLS und Autorisierungsrichtlinien für einen Netzwerkport durch Anmerkungen umgangen werden, gibt es keinen Zugriff Kontrolle für den Traffic am Anschluss und das Abhören oder Ändern des Traffics möglich sein. Darüber hinaus wirkt sich das Umgehen von Cloud Service Mesh-Richtlinien auf nicht sicherheitsbezogene Richtlinien wie Netzwerkrichtlinien.

Wenn die Cloud Service Mesh-Sicherheitsrichtlinie für einen Port oder eine IP-Adresse (entweder absichtlich oder unabsichtlich) sollten andere Sicherheitsmaßnahmen um das Mesh-Netzwerk zu sichern, Sicherheitsausnahmen, potenzielle Sicherheit Lücken und den allgemeinen Status der Sicherheitsdurchsetzung. So sichern Sie das Mesh-Netzwerk in solchen Szenarien:

  • Der Traffic, der die Sidecars umgeht, muss nativ verschlüsselt und authentifiziert werden, um MitM-Angriffe zu verhindern.
  • Kubernetes-Netzwerkrichtlinien erzwingen um die Konnektivität von Ports mit Richtlinienausnahmen einzuschränken (z. B. Einen Port mit Richtlinienausnahmen beschränken, um nur Traffic von einem anderen zuzulassen im selben Namespace) oder nur Traffic durch den Ports mit erzwungener Cloud Service Mesh-Sicherheitsrichtlinie.
  • GKE Enterprise Policy Controller erzwingen, um Cloud Service Mesh-Richtlinien automatisch validieren. Sie können z. B. erzwingen, dass die Cloud Service Mesh-Sidecars immer in Arbeitsbelastungen.

Kubernetes-Netzwerkrichtlinien erzwingen

Cloud Service Mesh baut auf der zugrunde liegenden Plattform auf (z. B. Kubernetes). Daher hängt die Cloud Service Mesh-Sicherheit von der Sicherheit des zugrunde liegenden Plattform. Beispiel: Ohne Kontrolle darüber, wer Kubernetes-Ressourcen aktualisieren kann, kann ein Nutzer das Kubernetes-Deployment eines Dienstes ändern, um die Sidecar-Datei des Dienstes zu umgehen.

Um ein starkes Sicherheitsniveau für ein Service Mesh zu schaffen, Es sollte erzwungen werden, dass die zugrunde liegende Plattform gemeinsam mit dem Cloud Service Mesh funktioniert. Sicherheitsrichtlinien.

Kubernetes-Netzwerkrichtlinien werden in der Netzwerkschicht (L3 und L4) für IP-Adressen und Ports Kubernetes-Pods und -Namespaces. Kubernetes-Netzwerkrichtlinien können erzwungen werden in in Verbindung mit Cloud Service Mesh-Richtlinien, um die Sicherheit des Mesh-Netzwerks zu verbessern.

Der Mesh-Administrator kann Kubernetes-Netzwerkrichtlinien beispielsweise so konfigurieren, dass Traffic darf nur Ports mit erzwungener Cloud Service Mesh-Sicherheitsrichtlinie verwenden. Wenn der gesamte Traffic mit Cloud Service Mesh mTLS erzwungen werden muss, kann der Administrator Kubernetes-Netzwerkrichtlinie so konfigurieren, dass Traffic nur an Ports zugelassen wird, mit der Cloud Service Mesh-mTLS-Richtlinie konfiguriert. Der Mesh-Administrator kann auch Kubernetes-Netzwerkrichtlinien konfigurieren, um die Konnektivität von Ports mit Richtlinienausnahmen zu beschränken. Beispielsweise können Sie die Konnektivität solcher Ports innerhalb eines Namespace beschränken.

Sicherer Zugriff auf die Steuerungsebene

Die Cloud Service Mesh-Steuerungsebene authentifiziert alle Clients, die eine Verbindung herstellen. Das heißt: Nur Aufrufer mit gültigen Anmeldedaten (Kubernetes-JWT- oder X.509-Zertifikat durch zugelassene Zertifizierungsstellen) auf die Cloud Service Mesh-Steuerungsebene zugreifen kann. TLS verschlüsselt die Verbindungen zwischen Arbeitslasten und der Cloud Service Mesh-Steuerungsebene.

Neben dem Authentifizierungsmechanismus kann für das Cloud Service Mesh im Cluster, Kubernetes Netzwerkrichtlinien können bereitgestellt werden, um den Cloud Service Mesh-System-Namespace zu isolieren. (standardmäßig istio-system) von nicht verwalteten Namespaces und Clients außerhalb des und Datenebenen den Zugriff auf die Steuerungsebene. VPC-Firewallregeln können verhindern, dass Traffic außerhalb eines Clusters Istiod erreicht. Mit solchen Netzwerkisolationsmaßnahmen kann ein Angreifer von außerhalb des Mesh-Netzwerks nicht auf die Steuerungsebene zugreifen, selbst wenn er gültige Anmeldedaten hat. Für verwaltete Steuerungsebenen übernimmt Google die Sicherheit für die Steuerungsebenen und solche Richtlinien zur Netzwerkisolation für Steuerungsebenen sind nicht erforderlich.

Namespace-Grenzen erzwingen

So verhindern Sie, dass der Nutzer eines Namespace auf Ressourcen in einem nicht autorisierten Namespace zugreift bzw. diese aktualisiert:

Kubernetes-RBAC-Netzwerkrichtlinien erzwingen

Die Administratoren des Mesh-Netzwerks sollten Kubernetes-RBAC-Richtlinien um zu steuern, wer auf Kubernetes-Ressourcen zugreifen und diese aktualisieren darf. Die Kubernetes-Zugriffssteuerung kann die Sicherheitsrisiken im Mesh-Netzwerk minimieren. Beispiel: Unbefugten Nutzern ist es nicht gestattet, Kubernetes-Deployments und Umgehung der Cloud Service Mesh-Richtlinienerzwingungen. Die Rollen eines Nutzers sollten an einen Namespace gebunden sein, damit der Nutzer nicht auf mehr Namespaces zugreifen kann, als er benötigt. Ausführliche Anleitungen und Beispiele für die Konfiguration von RBAC finden Sie unter Rollenbasierte Zugriffssteuerung konfigurieren. Nachdem Sie Workload Identity aktiviert haben, können Sie auch ein Kubernetes-Dienstkonto als IAM-Dienstkonto zulassen.

Sicherheit am Edge des Mesh-Netzwerks

Da die meisten Angriffe auch von außerhalb eines Clusters stammen können, ist die Sicherheit am Edge des Mesh-Netzwerks entscheidend.

Zugriffssteuerung für eingehenden Cluster-Traffic

Cloud Service Mesh empfängt eingehenden externen Traffic über das Ingress-Gateway. Über das Eingangsgateway bereitgestellte Dienste sind möglicherweise Angriffe von externen Quellen ausgesetzt. Sicherheitsadministratoren sollten Dienste, die externem Traffic über Eingangsgateways ausgesetzt sind, immer ausreichend sichern, um sie vor Angriffen zu schützen.

Bei eingehendem Traffic sollten Authentifizierung und Autorisierung für Dienste erzwungen werden, die externen Aufrufern zur Verfügung gestellt werden.

  • Sicherheitsrichtlinien für eingehenden Cluster-Traffic erzwingen Wenn der Cluster externen Traffics, sollte der Mesh-Administrator die Sicherheit für eingehenden Traffic erzwingen Richtlinien, einschließlich Cloud Service Mesh Gateway-TLS Authentifizierung und Autorisierungsrichtlinien, um externe Nutzer zu authentifizieren, Anfragen und überprüfen Sie, ob externe Anfragen für den Zugriff auf Dienste autorisiert sind. die vom Ingress-Gateway bereitgestellt werden. Die Erzwingung von Sicherheitsrichtlinien für eingehenden Traffic schützt vor Angriffen von außerhalb des Mesh-Netzwerks, die versuchen, ohne gültige Anmeldedaten oder Berechtigungen auf einen Dienst zuzugreifen.
  • Verwenden Sie Cloud Armor als Web Application Firewall (WAF) zum Schutz vor webbasierten Angriffen wie Injektionsangriffen und Remote-Ausführungsangriffen. Weitere Informationen finden Sie unter Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen.

Ausgehenden Cluster-Traffic regulieren

Die Sicherheit des ausgehenden Cluster-Traffics ist für die Sicherheit des Mesh-Netzwerks entscheidend, da Sicherheitsrichtlinien für ausgehenden Traffic vor Daten-Exfiltration-Angriffen schützen, die Filterung von ausgehendem Traffic erzwingen und den TLS-Ursprung für ausgehenden Traffic erzwingen können. Sicherheitsadministratoren sollten den ausgehenden Cluster-Traffic regulieren und prüfen.

Zusätzlich zur Verwendung von VPC-Firewalls, um ausgehenden Traffic zu beschränken, sollten die Administratoren des Mesh-Netzwerks auch Sicherheitsrichtlinien für ausgehenden Cluster-Traffic erzwingen und ausgehenden Traffic so konfigurieren, dass er Ausgangsgateways durchläuft.

Richtlinien für ausgehenden Traffic können die folgenden Angriffe minimieren:

  • Daten-Exfiltration-Angriffe.
  • Dienst-Pods können von Angreifern ausgenutzt werden, wenn ihre CVEs nicht gepatcht wurden. Manipulierte Pods können zu einem von Angreifern kontrollierten Botnet werden, das Spam sendet oder DoS-Angriffe startet.

Mit Autorisierungsrichtlinien für Eingangsgateways kann sichergestellt werden, dass nur autorisierte Dienste Traffic an bestimmte Hosts außerhalb des Mesh-Netzwerks senden dürfen. Für Traffic, der das Mesh-Netzwerk verlässt, kann der TLS-Ursprung an Ausgangsgateways erfolgen, anstatt an einzelnen Sidecars. So kann der TLS-Ursprung für Traffic einheitlich und sicher erfolgen, da die Clientzertifikate für mTLS von den Namespaces isoliert werden können, in denen Anwendungen ausgeführt werden.

Mit privatem Cluster oder VPC Service Control externe Zugriffe sperren

Sie erzwingen Richtlinien für eingehenden und ausgehenden Traffic und sperren externen Zugriff mit einem privaten Cluster oder VPC Service Controls, sofern möglich. Sicherheitsrichtlinien werden von Sicherheitsadministratoren für das Mesh-Netzwerk gesteuert. Die Konfiguration eines privaten Clusters oder von VPC Service Controls hingegen kann von Sicherheitsadministratoren der Organisation erzwungen werden.

VPC Service Controls kann erzwungen werden, um einen Sicherheitsbereich für die Dienste zu definieren. Damit können Sie Folgendes erreichen:

  • Verhindern, dass Dienste auf externe Ressourcen zugreifen.
  • Verhindern, dass externe Nutzer auf die Dienste in einem Sicherheitsperimeter zugreifen.

VPC Service Controls trägt zum Schutz vor Daten-Exfiltration-Angriffen bei und verhindert, dass externe Angreifer auf Dienste innerhalb eines Mesh-Netzwerks zugreifen.

Schutz vor externen DDoS-Angriffen

Externe DDoS-Angriffe können Eingangsgateways und Backend-Dienste überlasten, sodass legitime Anfragen nicht verarbeitet werden. Cloud Armor kann zum Schutz vor DDoS-Angriffen verwendet werden. Cloud Armor schützt nicht nur vor DDoS-Angriffen auf Netzwerkebene (L3 und L4), sondern auch vor DDoS-Angriffen auf Anwendungsebene (L7).

Sicherheit bei der Verwaltung und Automatisierung von Mesh-Netzwerken

Es ist wichtig, die Sicherheit für administrative Vorgänge und Automatisierungen zu berücksichtigen, die Sie für Ihr Mesh-Netzwerk einrichten, z. B. CI/CD. Mit den folgenden Vorgehensweisen können Sie für einen sicheren Betrieb des Mesh-Netzwerks sorgen, ohne das Risiko, Dienste zusätzlichen Angriffen auszusetzen.

Rollen für Vorgänge im Mesh-Netzwerk segmentieren

Nach dem Prinzip der rollenbasierten Zugriffssteuerung sollten Nutzer eines Mesh-Netzwerks nach ihren Rollen klassifiziert werden. Jeder Rolle sollte nur der Mindestsatz an Berechtigungen gewährt werden, der für die Rolle benötigt wird.

Beispielsweise sollte die Gruppe von Nutzern, die Dienstbereitstellungen durchführen, keine Berechtigungen zum Aktualisieren von Authentifizierungs- und Autorisierungsrichtlinien haben.

Es gibt verschiedene Operatorkategorien. Beispiel: Clusteroperatoren und Namespace-Operatoren. Es ist wichtig, die Rechteausweitung bei einem Operator zu verhindern, was zu einem unberechtigten Zugriff auf nicht autorisierte Ressourcen führen kann.

Mit Kubernetes-RBAC-Richtlinien können Mesh-Administratoren den Ressourcenzugriff nur auf autorisierte Nutzer beschränken.

Richtlinienkonfigurationen automatisch validieren

Operatoren können Cloud Service Mesh-Richtlinien versehentlich falsch konfigurieren, was zu schwerwiegenden Sicherheitsvorfällen. Um Fehlkonfigurationen und automatische Cloud Service Mesh-Richtlinien validieren, die Mesh-Administratoren verwenden können Policy Controller bis Einschränkungen durchsetzen zu Richtlinienkonfigurationen.

Um Personen mit der Berechtigung zur Aktualisierung nicht zu viel Vertrauen zu schaffen Cloud Service Mesh-Sicherheitsrichtlinien und Automatisierung der Validierung von Cloud Service Mesh sollten die Mesh-Administratoren Einschränkungen für das Cloud Service Mesh implementieren. Richtlinien mithilfe von Policy Controller:

Policy Controller basiert auf dem Open-Source-Projekt Gatekeeper und kann entweder als Kubernetes-Admission-Controller ausgeführt werden, um die Anwendung ungültiger Ressourcen zu verhindern, oder im Prüfmodus, damit Administratoren über Richtlinienverstöße informiert werden. Policy Controller kann die Bereitstellung von Ressourcen im Mesh-Netzwerk, z. B. um zu prüfen, ob die Annotationen in einer Bereitstellung Cloud Service Mesh-Richtlinien nicht umgehen und prüfen, ob Cloud Service Mesh-Richtlinien sind und zu überprüfen, ob eine Bereitstellung keine Root-Funktionen enthält (z. B. NET_ADMIN und NET_RAW).

Policy Controller kann auch prüfen, Vorhandene Cloud Service Mesh-Ressourcen anhand von Einschränkungen zum Erkennen der Richtlinie Fehlkonfigurationen.

Im Folgenden finden Sie einige Beispiele für die Erzwingung von GKE Enterprise Policy Controller Sicherheitsrichtlinien:

Die Einschränkungsvorlagenbibliothek die mit Policy Controller bereitgestellt werden, enthält eine Reihe von kann mit der vorkonfigurierten Bundle für Cloud Service Mesh-Sicherheitseinschränkungen um bestimmte Best Practices für die Cloud Service Mesh-Sicherheit durchzusetzen, z. B. Authentifizierungs-, Autorisierungs- und Trafficrichtlinien. Im Folgenden sind einige Beispieleinschränkungen aufgeführt, die im Bundle enthalten sind:

  • Mesh-Netzwerkebene erzwingen strikter mTLS-Modus PeerAuthentication.
  • Erzwingen, dass PeerAuthentications keine strikte mTLS-Authentifizierung überschreiben können.
  • Mesh-Netzwerkebene erzwingen Standardeinstellung ablehnen AuthorizationPolicy.
  • Sichere Muster der AuthorizationPolicy erzwingen.
  • Die Sidecar-Datei von Cloud Service Mesh wird immer in Arbeitslasten eingefügt.

Zum Umgang mit Ausnahmen und Break-Glass-Situationen kann der Mesh-Administrator Folgendes tun:

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.

Audit-Logging und Monitoring erzwingen

Mesh-Administratoren sollten Folgendes überwachen:

Diese Beobachtbarkeitsressourcen können verwendet werden, 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-Software zur Beobachtbarkeit (z. B. Prometheus) kann Cloud Service Mesh verwendet werden, empfehlen wir dringend, Google Cloud Observability (früher Stackdriver). Die integrierte Beobachtbarkeitslösung für Google Cloud bietet vollständig verwaltete und nutzerfreundliche Funktionen für Logging, Messwerterfassung, Monitoring und Benachrichtigungen.

Zertifizierungsstelle für clusterinterne Zertifikate schützen

Cloud Service Mesh verwendet standardmäßig eine von Google verwaltete Zertifizierungsstelle namens Cloud Service Mesh-Zertifizierungsstelle.

Wenn Sie die nicht verwaltete Istio-Zertifizierungsstelle (CA) verwenden, die als Teil von Istiod gehostet wird, wird der Signaturschlüssel der Zertifizierungsstelle in einem Kubernetes-Secret gespeichert und kann von Operatoren mit Zugriff auf die Secret-Ressource im Namespace istio-system aufgerufen werden. Dies ist ein Risiko, da ein Operator den CA-Schlüssel möglicherweise unabhängig von der CA von Istiod verwenden und möglicherweise Arbeitslastzertifikate unabhängig signieren kann. Es besteht auch die Gefahr, dass ein selbstverwalteter CA-Signaturschlüssel aufgrund eines Betriebsfehlers versehentlich gestohlen wird.

Zum Schutz des CA-Signaturschlüssels kann der Mesh-Administrator das Mesh-Netzwerk aktualisieren auf Cloud Service Mesh-Zertifizierungsstelle oder Certificate Authority Service (CA Service), die von Google gesichert und verwaltet werden. Verglichen mit mit Cloud Service Mesh-Zertifizierungsstelle unterstützt CA Service pro Kunde, Schlüssel über Cloud KMS signieren, das von Cloud HSM: CA-Dienst unterstützt auch regulierte Arbeitslasten, die Cloud Service Mesh-Zertifizierungsstelle jedoch nicht.

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 dem Cluster auswirken. 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.
  • Kubernetes-Pods, die im privilegierten Modus ausgeführt werden, können Netzwerkstacks und andere Kernelfunktionen auf dem Host bearbeiten. GKE Enterprise Policy Controller kann gewöhnt werden, verhindern, dass Pods privilegierte Container ausführen.
  • Cloud Service Mesh kann so konfiguriert werden, dass zur Konfiguration ein Init-Container verwendet wird. die Weiterleitung des iptables-Traffics an die Sidecar-Datei. Dadurch muss der Nutzer, der Arbeitslasten-Deployments erstellt, Berechtigungen zum Bereitstellen von Containern mit den Funktionen NET_ADMIN und NET_RAW haben. Um das Risiko der Ausführung von Containern zu vermeiden mit erweiterten Berechtigungen können Mesh-Administratoren enable 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

  • Container Analysis. Container Analysis kann Sicherheitslücken in GKE-Arbeitslasten scannen und erkennen.
  • Umgang mit CVEs (Common Vulnerabilities and Exposures). In einem Container-Image erkannte Sicherheitslücken sollten von den Mesh-Administratoren so schnell wie möglich behoben werden. Für verwaltetes Cloud Service Mesh mit verwaltete Datenebene, Google patcht automatisch CVEs, die sich auf die Mesh-Images auswirken.

Workload Identity für einen sicheren Zugriff auf Google-Dienste verwenden

Workload Identity 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

Ein Service Mesh kann Sicherheitsausnahmen und potenzielle Sicherheitsücken haben. 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. GKE Enterprise-Sicherheitsdashboard und mithilfe von Telemetriedaten den Sicherheitsstatus des Mesh-Netzwerks im Blick behalten.

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 analysiert und visualisiert die Sicherheitsrichtlinien auf eine Arbeitslast in einem Service Mesh angewendet, einschließlich Zugriffssteuerungsrichtlinien (Kubernetes-Netzwerkrichtlinien, Richtlinien für die Binärautorisierung und Dienstzugriff) Kontrollrichtlinien) und Authentifizierungsrichtlinien (mTLS).

Sicherheit für vertrauliche Nutzerdaten und Anmeldedaten

Vertrauliche Nutzerdaten oder Anmeldedaten können anfällig für Angriffe durch Pods oder schädliche Vorgänge sein, die im nichtflüchtigen Clusterspeicher gespeichert sind, z. B. mithilfe von Kubernetes-Secrets oder direkt in Pods. Sie 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.

Nächste Schritte