Dienstsicherheit

Dieses Dokument bietet eine Übersicht über die Dienstsicherheit mit Traffic Director. Es richtet sich an Traffic Director-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 Traffic Director mit Envoy und mit proxylosen gRPC-Anwendungen vertraut sind.

Mit Traffic Director erhalten Sie eine Dienst-zu-Dienst-Kommunikation in Ihrem Mesh-Netzwerk. 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 Traffic Director mit Envoy und Traffic Director 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 Traffic Director 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 Traffic Director 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 Traffic Director und Zertifikate von einer privaten Zertifizierungsstelle abrufen, die von einem CA Service-Pool verwaltet wird.

Diese Sicherheitsfeatures erleichtern die Bereitstellung von Traffic Director, 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 Traffic Director 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

Traffic Director 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.

Zur Vermeidung dieses potenziellen Problems können Sie HTTP, HTTP/2, oder gRPC über TLS für Traffic Director 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 Traffic Director 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 Traffic Director 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 Traffic Director 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 Traffic Director-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 Traffic Director konfigurieren. Auf diese Weise 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 Traffic Director 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 Traffic Director 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 Traffic Director-Diensten unterstützt Client-TLS-Richtlinien, Server-TLS-Richtlinien und Autorisierungsrichtlinien. Sie erstellen diese Richtlinien, damit Traffic Director 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.

Traffic Director 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
  • Zertifikate für Traffic Director-Clients wie Envoy-Proxys verfügbar machen, die von Traffic Director konfiguriert werden

Traffic Director unterstützt CA Service 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

Traffic Director 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 Endpunkt-Richtlinienressource, mit der Traffic Director die Konfiguration (Server-TLS-, Client-TLS- und Autorisierungsrichtlinien) für Endpunkte bereitstellen kann. Endpunkte sind die Traffic Director-Clients, die eine eingehende Kommunikation von einem anderen Traffic Director-Client beenden.

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 Traffic Director 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 werden an eine Endpunktrichtlinienressource angehängt.

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 an eine Endpunktrichtlinienressource an.

Beschränkungen

Die Traffic Director-Dienstsicherheit wird nur von GKE unterstützt. Sie können die Dienstsicherheit nicht mit Compute Engine 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