Dienstsicherheit (Legacy)

Dieses Dokument bietet eine Übersicht über die Dienstsicherheit mit Cloud Service Mesh unter Verwendung der Load Balancing APIs. Es ist für Cloud Service Mesh-Nutzer gedacht, die Authentifizierung, Verschlüsselung und Autorisierung zu ihren Bereitstellungen hinzufügen. In diesem Dokument wird davon ausgegangen, dass Sie mit Cloud Service Mesh mit Envoy und mit proxylosen gRPC-Anwendungen vertraut sind.

Dieses Dokument gilt für Konfigurationen, die die Load Balancing APIs verwenden. Wenn Sie die Dienstrouting-APIs verwenden, lesen Sie den Hilfeartikel Dienstsicherheit. Dies ist ein älteres Dokument.

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 mit Transport Layer Security (TLS) und Gegenseitige TLS (mTLS) für Cloud Service Mesh mit Envoy und Cloud Service Mesh mit proxylosen gRPC-Anwendungen. 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. Cloud Service Mesh-Dienst ist Sicherheit 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 und verschlüsseln sich proxylose gRPC- oder Envoy-Sidecars sicher Kommunikation durch den Abruf von Konfigurationsinformationen vom Cloud Service Mesh und Zertifikate von einem CA Service-Pool.

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 sowie Dienst-zu-Dienst-Sicherheit mit Verschlüsselung und Authentifizierung unter Verwendung von 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.

Um dieses potenzielle Problem zu beheben, können Sie HTTP, HTTP/2 oder gRPC über TLS verwenden. mit dem Cloud Service Mesh. 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 für den Server konfiguriert (beispielsweise durch Konfigurieren eines Envoy-Proxys auf der Clientseite und eines anderen Envoy-Proxys auf Serverseite), können Sie die Vorteile erweiterter Authentifizierungsmuster wie der gegenseitigen Authentifizierung nutzen.

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 Regeln zum Zulassen und Ablehnen definieren, um den Zugriff anhand von Anfrageparametern zu autorisieren. 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, Ihrer Datenebene, um den Dienstzugriff auf der Grundlage von Regeln, die Sie definieren, zuzulassen oder zu verweigern. Diese Richtlinien bestehen aus zwei Komponenten:

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

Wenn eine Anfrage oder ein RPC gesendet wird, hat der Cloud Service Mesh-Client auf dem aufgerufenen ermittelt, 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 Sicherheit von Cloud Service Mesh-Diensten unterstützt Client-TLS-Richtlinien, Server-TLS-Richtlinien 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-Proxys zur Verfügung, 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.

Verwenden Sie den Ziel-HTTPS-Proxy oder den Ziel-gRPC-Proxy in Ihrer Bereitstellung, um den Sicherheitsdienst zu aktivieren. Den Ziel-HTTP-Proxy und den Ziel-TCP-Proxy können Sie nicht verwenden.

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 die verwaltete Zertifizierungsstelle CA Service. 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. Server-TLS-Richtlinien können an die Ziel-HTTPS-Proxy-Ressource oder eine Endpunktrichtlinien-Ressource angehängt werden.

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. Eine Autorisierungsrichtlinie kann an die Ziel-HTTPS-Proxy-Ressource oder eine Endpunktrichtlinien-Ressource angehängt werden.

Beschränkungen

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

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.

Nächste Schritte