Dienstsicherheit

Dieses Dokument bietet einen Überblick über die Dienstsicherheit mit Cloud Service Mesh. Es richtet sich an Cloud Service Mesh-Nutzer, die zu ihren Bereitstellungen Funktionen für Authentifizierung, Verschlüsselung und Autorisierung hinzufügen möchten. In diesem Dokument wird davon ausgegangen, dass Sie mit der Cloud Service Mesh-Übersicht und mit proxylosen gRPC-Anwendungen vertraut sind.

Mit Cloud Service Mesh können Sie die Dienst-zu-Dienst-Kommunikation in Ihrem Mesh-Netzwerk sichern. Im Mesh-Netzwerk hat jeder Dienst eine Identität. Die folgenden Features unterstützen die sichere Kommunikation:

  • Authentifizierung und Verschlüsselung, die Transport Layer Security (TLS) und gegenseitiges TLS (mTLS) für Cloud Service Mesh mit Envoy und Cloud Service Mesh mit proxylosen gRPC-Anwendungen verwenden. Client-TLS-Richtlinien und Server-TLS-Richtlinien steuern, ob Dienste ihre Identität gegenseitig bestätigen und verschlüsselte Kommunikationskanäle nutzen müssen.
  • Autorisierung anhand der Eigenschaften des Clients und der Anfrage. Mit Autorisierungsrichtlinien wird gesteuert, ob ein Dienst auf einen anderen Dienst zugreifen darf und welche Aktionen zulässig sind.

Mit Zertifikaten und Schlüsseln einer privaten Zertifizierungsstelle (CA) wie, Certificate Authority Service von Google können Sie die Dienstsicherheit einfacher gewährleisten. CA Service bietet GKE-Mesh-Zertifikate. Mit den GKE-Mesh-Zertifikatsfunktionen und Cloud Service Mesh können Sie diese Zertifikate automatisch zur Nutzung durch Arbeitslasten bereitstellen lassen. Sie ändern Ihre Pods, damit Arbeitslasten mTLS-Anmeldedaten empfangen und verwenden können. Die Dienstsicherheit für Cloud Service Mesh ist derzeit nur für GKE-basierte Arbeitslasten verfügbar.

In modernen, auf Mikrodiensten basierenden Architekturen ersetzen kleinere, stärker ausgerichtete Dienste große monolithische Anwendungen. Dienstaufrufe kommunizieren über das Netzwerk miteinander. Diese prozessinternen Aufrufe in monolithischen Anwendungen sind mit Sicherheitsherausforderungen verbunden. Daher sollten sie authentifiziert, verschlüsselt und autorisiert werden. Diese Schritte unterstützen das Zero-Trust-Prinzip, bei dem davon ausgegangen wird, dass der gesamte Netzwerktraffic gefährdet ist, unabhängig davon, ob der Traffic von innerhalb oder außerhalb des Netzwerks stammt.

Das Designmuster des Service Mesh trennt die Komplexität im Zusammenhang mit der Dienst-zu-Dienst-Kommunikation von der Geschäftslogik. Stattdessen verarbeitet die Datenebene diese Komplexität. Neben der Reduzierung der Komplexität der Anwendung ermöglicht das Service-Mesh-Designmuster Sicherheitsmuster, die andernfalls schwer zu implementieren und zu verwalten sind.

In diesem Modell authentifizieren proxyloses gRPC oder Envoy-Sidecars sicher die Kommunikation und verschlüsseln diese, indem sie Konfigurationsinformationen von Cloud Service Mesh und Zertifikate von einer privaten Zertifizierungsstelle abrufen, die von einem CA Service-Pool verwaltet wird.

Diese Sicherheitsfeatures erleichtern die Bereitstellung von Cloud Service Mesh, indem sie Folgendes bereitstellen:

  • Automatische Bereitstellung von Schlüsseln und Zertifikaten für alle Dienste in Ihrem Mesh-Netzwerk
  • Automatische Rotation von Schlüsseln und Zertifikaten für zusätzliche Sicherheit.
  • Einbindung in Google Kubernetes Engine (GKE), um alle Funktionen wie Deployment-Deskriptoren und Labels zu verwenden.
  • Hochverfügbarkeit für von Google verwaltete Dienste, einschließlich der von Cloud Service Mesh und CA Service verwalteten privaten CA-Pools.
  • An Google Identity and Access Management (IAM) gebundene Sicherheit: Dienstautorisierung basierend auf autorisierten Google-Dienstkonten.
  • Nahtlose Interoperabilität mit Ihren Envoy-basierten und proxylosen Arbeitslasten. Ein Dienst kann sich beispielsweise hinter einem Envoy-Proxy befinden, aber der Client verwendet die proxylose Service Mesh-Sicherheit von gRPC. Umgekehrt kann ein Dienst auch hinter der Proxy-Sicherheit eines gRPC-Proxys ausgeführt werden, aber der Client verwendet einen Envoy-Proxy.

Sichere Dienst-zu-Dienst-Kommunikation

Cloud Service Mesh bietet Autorisierung und Dienst-zu-Dienst-Sicherheit mit Verschlüsselung und Authentifizierung über TLS. Mit Client-TLS- und Server-TLS-Richtlinien haben Dienste folgende Möglichkeiten:

  • Identitäten bestätigen und validieren
  • Kommunikationssitzungen mithilfe von TLS oder mTLS verschlüsseln.

In einem Service Mesh wird diese Art der Sicherheit von der Datenebene abgewickelt, sodass Anwendungen keine speziellen Voraussetzungen erfüllen müssen, um die Sicherheit zu gewährleisten.

Mit Autorisierungsrichtlinien können Sie den Zugriff gemäß Ihren definierten Regeln verweigern oder zulassen.

TLS für Verschlüsselung verwenden

Wenn ein Dienst einen anderen Dienst über das HTTP-, HTTP/2- oder gRPC-Protokoll aufruft, wird der Traffic im Netzwerk als Klartext weitergeleitet. Dieser Traffic kann Man-in-the-Middle-Angriffen ausgesetzt sein, bei denen ein Angreifer den Traffic abfängt und seinen Inhalt untersucht oder manipuliert.

Zur Vermeidung dieses potenziellen Problems können Sie HTTP, HTTP/2 oder gRPC über TLS für Cloud Service Mesh verwenden. Wenn Sie diese Protokolle über TLS nutzen, wird der Traffic zwischen dem Client und dem Server mit TLS verschlüsselt, das auf dem Zertifikat des Servers basiert. Der Traffic ist dann nicht mehr im Klartextformat. Dies reduziert die Wahrscheinlichkeit, dass ein Angreifer die Inhalte abfangen und untersuchen oder manipulieren kann.

TLS zur Authentifizierung verwenden

Wenn ein Dienst einen anderen Dienst aufruft, sollten Sie die folgenden Fragen prüfen:

  • Woher weiß ein Client, dass er eine Antwort vom richtigen Server und nicht vom Betrüger erhalten hat? Bei einer typischen Anfrage-Antwort-Interaktion auf Basis von HTTP überprüft der Client beispielsweise nicht die Identität des Servers.

  • Was passiert, wenn ein Angreifer diesen Traffic abfängt? HTTP-Traffic ist beispielsweise nicht verschlüsselt. Somit kann jeder, der den Traffic empfängt, den Inhalt untersuchen. Das wird als Person-in-the-Middle-Angriff bezeichnet.

Zur Behebung dieser Probleme können Sie HTTP, HTTP/2 und gRPC über TLS verwenden. Bei diesem Austausch zwischen einem Client und einem Server muss der Server ein Serverzertifikat verwenden, um gegenüber dem Client seine Identität nachzuweisen. Anfragen und Antworten werden dann mit TLS verschlüsselt.

Gegenseitige TLS-Authentifizierung

Wenn Cloud Service Mesh das Anwendungsnetzwerk sowohl für den Client als auch Server verwenden, z. B. durch Konfigurieren eines Envoy-Proxys auf Clientseite und einen weiteren Envoy-Proxy auf der Serverseite bereitgestellt haben. Sie können wie die gegenseitige Authentifizierung.

Bei einem typischen HTTP-über-TLS-Austausch, der nicht auf der gegenseitigen Authentifizierung basiert, hat der Server ein Zertifikat, mit dem die Kommunikation zwischen Client und Server verschlüsselt wird. Der Client kann die Identität des Servers überprüfen, indem er die Signatur prüft, die der Server während des TLS-Handshakes sendet. Die Identität des Clients wird vom Server jedoch nicht überprüft.

Wenn die gegenseitige Authentifizierung aktiviert ist, hat der Client auch ein Zertifikat. Der Client überprüft die Identität des Servers wie im vorherigen Abschnitt beschrieben und der Server kann auch die Identität des Clients verifizieren. Zur Verschlüsselung des Kommunikationskanals werden sowohl das Client- als auch das Serverzertifikat verwendet. Dadurch kann der Server auch Clients anhand der überprüften Clientidentität autorisieren.

Grafik: mTLS-Authentifizierung in einem Service Mesh
Gegenseitige TLS-Authentifizierung (mTLS) in einem Service Mesh (zum Vergrößern klicken)

Dienstaufrufe autorisieren

Sie können den Zugriff mithilfe von Autorisierungsrichtlinien zulassen oder ablehnen. Mit Cloud Service Mesh können Sie Zulassungs- und Ablehnungsregeln definieren, um den Zugriff zu autorisieren basierend auf Anfrageparametern. Sie können diese Regeln auf Ebene-3- und Ebene-7-Parametern basieren lassen, einschließlich der Client-ID, die aus dem client-cert in einer mTLS-Verbindung, Quell-IP-Adresse, Hostübereinstimmung, Methodenübereinstimmung und Headerübereinstimmung abgeleitet wird. Das folgende Diagramm zeigt die Autorisierung mit Envoy-Proxys. Der Prozess ähnelt gRPC-Clients.

Grafik: Autorisierung in einem Service Mesh.
Autorisierung in einem Service Mesh mit Envoy (zum Vergrößern klicken)

Zugriff mit Autorisierung einschränken

Es hat sich bewährt, das Grundprinzip der geringsten Berechtigung für ein Service Mesh einzuhalten. Halten Sie sich an dieses Prinzip, indem Sie den Dienstzugriff auf die Aufrufer beschränken, die vom Dienst abhängig sind. Wenn ein Aufrufer versucht, auf einen Dienst zuzugreifen, für den er nicht autorisiert ist, wird der Versuch abgelehnt.

Mit Cloud Service Mesh können Sie Autorisierungsrichtlinien konfigurieren, mit denen die Datenebene basierend auf von Ihnen definierten Regeln den Dienstzugriff erlauben oder verweigern kann. Diese Richtlinien bestehen aus zwei Komponenten:

  • Einer Aktion: Zulassen oder Ablehnen
  • Einer Liste von Regeln

Wenn eine Anfrage oder ein RPC gesendet wird, bestimmt der Cloud Service Mesh-Client für den aufgerufenen Dienst, ob eine Regelübereinstimmung vorliegt. Wenn eine Übereinstimmung gefunden wird, wird die Anfrage oder der RPC zugelassen oder abgelehnt. Sie können eine Regel definieren, die mit Attributen wie den folgenden abgeglichen wird:

  • Bei Verwendung von mTLS, das Kubernetes-Dienstkonto des aufrufenden Dienstes
  • Der IP-Adresse oder dem Adressbereich des aufrufenden Dienstes
  • Den Ports des Zieldienstes
  • Die HTTP-Attribute der Anfrage, einschließlich Hostnamen, Methoden und benutzerdefinierten HTTP-Headern

Sichere Benennung

Als zusätzlichen Sicherheitsmechanismus können Sie eine sichere Benennung mit Cloud Service Mesh konfigurieren. So können Sie eine Liste zulässiger Namen oder SPIFFE-Identitäten (Secure Production Identity Framework for Everyone) für einen bestimmten Dienst definieren, zu dem ein Client eine Verbindung herstellen möchte. Während des TLS-Austauschs gibt das Back-End des Dienstes ein X.509-Zertifikat an den Client zurück. Der Client prüft dann das Zertifikat, um festzustellen, ob das X.509-Zertifikat mit einer der Namen oder einer der SPIFFE-Identitäten übereinstimmt. Weitere Informationen zu SPIFFE-Identitäten finden Sie unter Secure Production Identity Framework for Everyone.

Traffic an einem Gateway schützen

Zur Konfiguration Ihrer Gateways können Sie Cloud Service Mesh verwenden. Ein Gateway ist ein eigenständiger Envoy-Proxy, der in der Regel als eines der folgenden Dinge fungiert:

  • Als Ingress-Gateway, das Traffic verarbeitet, der in ein Mesh-Netzwerk oder eine andere Domain gelangt
  • Als Egress-Gateway, das Traffic verarbeitet, der ein Mesh-Netzwerk oder eine andere Domain verlässt
  • Als Reverse-Proxy oder mittlerer Proxy, der eingehenden Traffic auf einen oder mehrere Dienste verteilt

Clients, die Traffic in das Mesh-Netzwerk oder aus dem Mesh-Netzwerk senden möchten, senden Traffic an das Gateway. Das Gateway verarbeitet dann Anfragen gemäß den Regeln, die Sie mit Cloud Service Mesh eingerichtet haben. Sie können beispielsweise erzwingen, dass der (durch das Ingress-Gateway) in Ihr Mesh-Netzwerk gelangende Traffic mit TLS verschlüsselt werden muss.

Sicherheitskomponenten

Die Dienstsicherheit von Cloud Service Mesh unterstützt Client-TLS-Richtlinien und Server-TLS und Autorisierungsrichtlinien. Sie erstellen diese Richtlinien, damit Cloud Service Mesh Ihre Datenebene konfigurieren und Sicherheitsfunktionen aktivieren kann. Zum Erstellen oder Aktualisieren dieser Richtlinien müssen Sie keine Änderungen an Ihren Anwendungen vornehmen.

Verschlüsselung und unterstützte Authentifizierungsmodi

Wenn ein Dienst einen anderen Dienst aufruft, besteht der erste Schritt zum Einrichten einer sicheren Kommunikation darin, dass jeder Dienst gegenüber dem anderen Dienst seine Identität nachweist. Wie stark ein Dienst seine Identität nachweisen muss, hängt von dem von Ihnen konfigurierten TLS-Modus ab.

Sie können die folgenden Sicherheitsebenen konfigurieren:

  • Unverschlüsselt/nicht authentifiziert
  • TLS
  • Gegenseitiges TLS (mTLS)
  • Moderat: mTLS oder unverschlüsselt/nicht authentifiziert, je nachdem, wie der Client die Verbindung initiiert

Zertifikate und CAs

Zertifikate und eine vertrauenswürdige Zertifizierungsstelle (CA) bieten die Grundlage für das Vertrauen in ein verteiltes System wie ein Service Mesh. Mit Zertifikaten können Dienste ihre Identität nachweisen und die ihnen präsentierten Identitäten auf folgende Arten prüfen:

  • Ein Dienst, der seine Identität gegenüber einem anderen Dienst nachweisen möchte, zeigt das Zertifikat dem anderen Dienst. Eine Zertifizierungsstelle, die beide Dienste kryptografisch signiert und dieses Zertifikat ausgibt.
  • Der Dienst, der dieses Zertifikat empfängt, kann prüfen, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle stammt.

Cloud Service Mesh ist keine Zertifizierungsstelle. Um eine sichere Kommunikation zu gewährleisten, müssen Sie einen Mechanismus einrichten, der Folgendes ausführt:

  • Identitäten und Zertifikate bereitstellen
  • Stellt die Zertifikate für Cloud Service Mesh-Clients wie Envoy zur Verfügung Proxys, die von Cloud Service Mesh konfiguriert werden

Cloud Service Mesh unterstützt den CA-Dienst von Google. Die Einrichtungsanleitungen für Envoy und proxylose gRPC-Dienste enthalten Anleitungen zur Einrichtung. Weitere Informationen finden Sie unter Nächste Schritte.

Architektur und Ressourcen

Cloud Service Mesh enthält den Namespace der Network Security API, der aus drei Google Cloud API-Ressourcen besteht, mit denen Sie die Sicherheitsrichtlinien angeben können, die auf Ihre Datenebene angewendet werden sollen.

Zwei Google Cloud API-Ressourcen unterstützen die Authentifizierung im Mesh-Netzwerk: Client-TLS-Richtlinien und Server-TLS-Richtlinien. Die Autorisierungsrichtlinie als dritte Ressource unterstützt die Autorisierung.

Der Namespace der Network Services API enthält die Endpunktrichtlinienressource, die ermöglicht Cloud Service Mesh, die Konfiguration bereitzustellen (Server-TLS, Client-TLS und Autorisierungsrichtlinien) auf Endpunkte übertragen. Endpunkte sind das Cloud Service Mesh Clients, die eine eingehende Kommunikation von einem anderen Cloud Service Mesh beenden Client.

Client-TLS-Richtlinie

Mit einer Client-TLS-Richtlinie können Sie den clientseitigen TLS-Modus und die Zertifikatsanbieterinformationen angeben, die auf Ihre Datenebene angewendet werden sollen. Client-TLS-Richtlinien unterstützen TLS- und mTLS-Authentifizierung. Client-TLS-Richtlinien müssen an eine globale Back-End-Dienstressource angehängt werden.

Wenn Sie TLS konfigurieren, müssen Sie mithilfe des API-Felds serverValidationCa einen Mechanismus angeben, mit dem der Client das Zertifikat validiert, das er während des TLS-Austauschs erhält. Der Client ruft mithilfe dieser Informationen ein Validierungszertifikat ab, mit dem das Serverzertifikat validiert werden kann.

Wenn Sie mTLS konfigurieren, müssen Sie auch einen Mechanismus angeben, mit dem der Client sein Zertifikat und seinen privaten Schlüssel über das API-Feld clientCertificate abruft. Der Client verwendet diese Informationen, um dem Server während des TLS-Handshakes ein Zertifikat zu präsentieren.

In diesem Release unterstützt Cloud Service Mesh eine verwaltete Zertifizierungsstelle, CA-Dienst: Die Konfiguration ist unkompliziert: Sie geben den google_cloud_private_spiffe-Plug-in-Namen beim Konfigurieren des Zertifikatsanbieters an. Dadurch können Ihre xDS-Clients Zertifikate und Schlüssel von einem statischen Speicherort laden. Als Voraussetzung müssen Sie CA Service-Pools konfigurieren und Mesh-Zertifikate in Ihrem GKE-Cluster aktivieren.

TLS-Serverrichtlinie

Mit einer Server-TLS-Richtlinie (Ressource ServerTlsPolicy) können Sie den serverseitigen TLS-Modus und die Zertifikatsanbieterinformationen angeben, die auf Ihre Datenebene angewendet werden sollen. Server-TLS-Richtlinien unterstützen TLS, mTLS und nur mit Envoy die Open_or_mTLS-Authentifizierung. Sie hängen Server-TLS-Richtlinien an eine Endpunktrichtlinienressource an.

Subject Alternative Names

Wenn Sie das Feld securitySettings eines globalen Back-End-Dienstes konfigurieren, können Sie im Feld subjectAltNames eine Liste mit SAN SANs (Subject Alternative Names) angeben. Wenn ein Client einen TLS-Handshake mit einem der Back-Ends des Dienstes initiiert, präsentiert der Server sein X.509-Zertifikat. Der Client prüft das Feld subjectAltName des Zertifikats. Wenn das Feld einen der angegebenen Werte enthält, wird die Kommunikation fortgesetzt. Dieser Mechanismus wird weiter oben unter Sichere Benennung beschrieben.

Autorisierungsrichtlinie

Eine Autorisierungsrichtlinie (AuthorizationPolicy-Ressource) gibt an, wie ein Server eingehende Anfragen oder RPCs autorisiert. Sie kann so konfiguriert werden, dass eine eingehende Anfrage oder RPC anhand verschiedener Parameter wie der Identität des Clients, der die Anfrage gesendet hat, des Hosts, der Header und anderer HTTP-Attribute zugelassen oder abgelehnt wird. Sie hängen Autorisierungsrichtlinien für eine Endpunktrichtlinienressource.

Eine Autorisierungsrichtlinienregel besteht aus den folgenden Komponenten:

  • from: gibt die Identität des Clients an, der von der Regel zugelassen wird. Die Identität kann aus einem Clientzertifikat in einer mTLS-Verbindung abgeleitet werden oder es kann sich um die Umgebungsidentität handeln, die der Client-VM zugewiesen ist, z. B. aus einem Dienstkonto oder einem sicheren Tag.
  • to: gibt die von der Regel zulässigen Vorgänge an, z. B. die URLs, die auf die zugegriffen werden kann, oder die HTTP-Methoden zugelassen sind.
  • when: Hier können Sie zusätzliche Einschränkungen definieren, die erfüllt werden müssen. Sie können Common Expression Language (CEL)-Ausdrücke verwenden, um die Einschränkungen zu definieren.
  • action: Gibt die Aktion der Regel an. Mögliche Werte sind ALLOW, DENY oder CUSTOM.

Beschränkungen

Die Sicherheit des Cloud Service Mesh-Dienstes wird nur unterstützt mit GKE Sie können die Dienstsicherheit nicht mit der Compute Engine bereitstellen.

Bei der Auswertung einer Anfrage berücksichtigt eine Autorisierungsrichtlinie eines der folgenden Elemente: Aktionen:

  • ALLOW: Gewährt Zugriff auf die angeforderte Ressource, wenn die Anfrage mit dem Regeln innerhalb der Autorisierungsrichtlinie definiert. Die Autorisierungsrichtlinie blockiert den Zugriff auf die angeforderte Ressource, wenn die Anfrage nicht mit den in der Autorisierungsrichtlinie definierten Regeln übereinstimmt. Eine Anfrage wird abgelehnt, wenn sie entspricht keiner ALLOW-Richtlinie, auch wenn andere Richtlinien dies zulassen.

  • DENY: Blockiert den Zugriff auf die Ressource, wenn eine Anfrage mit einer der Regeln übereinstimmt in einer DENY-Richtlinie angegeben ist. Die Autorisierungsrichtlinie gewährt Zugriff auf die angeforderte Ressource, wenn die Anfrage keiner definierten Regel im die Autorisierungsrichtlinie. Eine Anfrage wird abgelehnt, wenn sie einer DENY-Richtlinie entspricht, auch wenn sie von anderen Richtlinien zulässig ist.

  • CUSTOM (nicht in Cloud Service Mesh unterstützt): Ermöglicht die Integration in externe Autorisierungssysteme für komplexe Autorisierungsentscheidungen. CUSTOM Aktionen werden für Richtlinien verwendet, die Diensterweiterungen verwenden für Autorisierungsentscheidungen.

Auswertungsreihenfolge der Autorisierungsrichtlinie

Wenn einer einzelnen Ressource mehrere Autorisierungsrichtlinien zugewiesen sind, werden sie in der folgenden Reihenfolge ausgewertet, um zu bestimmen, ob eine Anfrage zugelassen oder abgelehnt wird.

  1. Richtlinien mit CUSTOM-Aktionen: Wenn die CUSTOM-Richtlinie die Anfrage ablehnt, wird sie sofort abgelehnt. DENY- oder ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

  2. Richtlinien mit DENY-Aktionen: Wenn eine DENY-Richtlinie mit der Anfrage übereinstimmt, wird die Anfrage abgelehnt. ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

  3. Richtlinien mit ALLOW-Aktionen: Wenn keine ALLOW-Richtlinien vorhanden sind oder eine ALLOW-Richtlinie mit der Anfrage übereinstimmt, wird die Anfrage zugelassen. Wenn jedoch Keine ALLOW-Richtlinie stimmt mit der Anfrage überein, wird die Anfrage abgelehnt.

Einschränkungen bei proxylosen gRPC-Anwendungen

Für die Dienstsicherheit bei proxylosen gRPC-Diensten gelten folgende Einschränkungen:

  • Dieser Release ist auf Java, Python, C++ und Go beschränkt.

AuthzPolicy-Kontingente

  • Sie sind auf insgesamt fünf Autorisierungsrichtlinien pro Gateway beschränkt.
  • Sie sind auf 20 AuthzPolicy-Ressourcen pro Projekt beschränkt.
  • Eine einzelne AuthzPolicy kann auf bis zu 100 Gateways verweisen.

Nächste Schritte