Gateway-Sicherheit

Auf dieser Seite werden verschiedene Methoden zum Sichern von Gateways in Google Kubernetes Engine (GKE) beschrieben. Weitere Informationen finden Sie unter Gateway sichern.

Funktionsweise der Gateway-Sicherheit

Ein Gateway stellt das Frontend eines Load-Balancers dar. Es gibt zwei Pfade, die Sie mit Authentifizierung und Verschlüsselung für Gateways sichern können:

  • Client zum Gateway: Traffic stammt vom Client und wird am Gateway beendet.
  • Gateway zu Pod: Traffic stammt vom Gateway und wird bei den Backend-Pods beendet.

Das folgende Diagramm zeigt beide Pfade zur Authentifizierung und Verschlüsselung von Gateways:

Auf dieser Seite wird beschrieben, wie Sie den Pfad vom Client zum Gateway mit Zertifikaten sichern, die auf der Gateway-Ebene hochgeladen und verwaltet werden. Informationen zum Schützen des Traffics zwischen Gateway und Pod finden Sie unter Load Balancer zu Anwendungstraffic mit TLS sichern.

Vorteile

Mit der Gateway API können Sie eine Anwendung auf verschiedene Arten sichern, wodurch Sie verschiedene Rollen für die Interaktion mit dem Gateway nutzen können.

Wer besitzt die Domain- und TLS-Konfiguration?

Das Gateway API-Modell führt zwei Rollen ein, die Gateways verwenden oder bereitstellen:

  • Platform Admin: Der Clusteroperator ist der Administrator für ganze Cluster. Sie verwalten Richtlinien, Netzwerkzugriff und Anwendungsberechtigungen.
  • Anwendungsentwickler: Der Anwendungsentwickler definiert die Anwendungs- und Dienstkonfiguration.

Das folgende Diagramm zeigt die Felder in den Gateway- und HTTPRoute-Ressourcen, die die TLS- und Domaininhaberschaft für die zwei Anwendungen store-v1 und store-v2 beeinflussen.

Im Diagramm steuert der Cluster-Operator:

  • Welche Domains Anwendungsentwickler für ihre Anwendungen in den einzelnen Namespaces verwenden können.
  • Die spezifischen Zertifikate, die unterschiedliche Domains beenden
  • Vom Gateway-Inhaber bereitgestellte Zertifikate
  • Gibt an, ob HTTPRoute-Inhaber eigene Hostnamen für die Zertifikatgenerierung angeben können

Anwendungsentwickler steuern den Hostnamen, der ein Zertifikat generiert, wenn die Gateway-Definition dies zulässt.

Durch diese Trennung von operativen Aufgaben können Anwendungsentwickler ihre eigene HTTPRoute für eine besser verteilte Kontrolle bereitstellen und verwalten. Außerdem können Plattformadministratoren Gateways für die zentrale Steuerung von TLS bereitstellen und verwalten.

Gateway-Zertifikatsverwaltung

Sie können Gateways mit folgenden Methoden sichern:

Wenn Sie Kubernetes Secrets oder SslCertificate-Ressourcen der Compute Engine API verwenden, können Sie maximal 15 Zertifikate an ein einzelnes Gateway anhängen.

Mit Certificate Manager können Sie bis zu 10.000.000 Zertifikate pro Load-Balancer anhängen, wenn Sie eine Kontingenterhöhung anfordern.

Weitere Informationen zu Google Cloud-SSL-Zertifikaten finden Sie unter Überblick über SSL-Zertifikate.

Kubernetes-Secrets

Die Gateway API-Spezifikation unterstützt Kubernetes-Secrets zum Speichern und Anhängen von Zertifikaten an Gateways. Mithilfe des Felds Gateway.spec.tls.certificateRef können Sie ein oder mehrere Kubernetes-Secrets mit einem Gateway verknüpfen.

Durch Kubernetes-Secrets gesicherte Gateway-Ressourcen haben folgende Anforderungen:

  • Sie müssen den Gateway-Listener port und protocol auf 443 und HTTPS festlegen.
  • Sie müssen das Feld listener.tls.mode auf Terminate setzen.
  • Sie müssen auf die TLS-Anmeldedaten im Block listeners.tls verweisen.

Für Gateway-Ressourcen, die mit Kubernetes-Secrets gesichert werden, gelten die folgenden Einschränkungen:

  • Nur HTTPS-Listener beenden Traffic mit den angegebenen Secrets. Sie können jedoch mehrere Listener mit einer Mischung aus HTTP und HTTPS angeben.
  • Wenn Sie mehrere Listener auf einem Gateway haben, die HTTPS verwenden, muss jeder Listener einen eindeutigen Hostnamen haben.
  • Sie können nur einen einzelnen Hostnamen weglassen oder für jedes Port/Protokoll-Paar * zuweisen.
  • Sie können nur ein Standardzertifikat für jedes Gateway zuweisen.

Informationen zum Sichern eines Gateways mit einem Kubernetes-Secret finden Sie unter Gateway mit einem Kubernetes-Secret sichern.

SSL-Zertifikate

SSL-Zertifikate speichern und senden Zertifikate an Load-Balancer.

Ein SSL-Zertifikat kann entweder selbstverwaltet oder von Google verwaltet sein.

Weitere Informationen zu den Unterschieden zwischen diesen beiden Zertifikatstypen finden Sie unter SSL-Zertifikate-Übersicht.

Der Umfang und der Speicherort des SSL-Zertifikats müssen mit dem Umfang und Speicherort des Gateways übereinstimmen, das es verwendet.

Ein globales SSL-Zertifikat kann beispielsweise nicht von einem regionalen Gateway verwendet werden.

In der folgenden Tabelle sind die Bereichs- und Standortanforderungen der SSL-Zertifikate für jede GatewayClass aufgeführt:

GatewayClass SSL-Zertifikatsbereich Standort des SSL-Zertifikats
gke-l7-global-external-managed Globales SSL-Zertifikat Global
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed Regionales SSL-Zertifikat Muss dieselbe Region sein wie das Gateway
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc
Von Google verwaltete SSL-Zertifikate sind nicht mit regionalen Gateways kompatibel.

Informationen zum Sichern eines Gateways mit einem SSL-Zertifikat finden Sie unter Gateway mit einem SSL-Zertifikat sichern.

Zertifikatmanager

Zertifikatmanager ist ein zentraler Speicherort zum Verwalten Ihrer TLS-Zertifikate.

Wenn Sie ein Gateway mit Zertifikatmanager sichern, können Sie Folgendes tun:

  • Verweisen Sie direkt auf ein CertificateMap von einem Gateway, das Sie in Zertifikatmanager erstellt haben.
  • Verwalten Sie Ihre eigenen Zertifikate.
  • Verbessern Sie die Weitergabezeiten von Zertifikaten.
  • Verwenden Sie Cloud Monitoring für abgelaufene Zertifikate und die Weitergabe von Zertifikaten.

Zertifikatmanager unterstützt sowohl selbstverwaltete als auch von Google verwaltete SSL-Zertifikate.

Informationen zum Sichern eines Gateways mithilfe des Zertifikatsmanagers finden Sie unter Gateway mit Zertifikatsmanager sichern.

GatewayClass TLS-Support

In der folgenden Tabelle werden die TLS-Beendigungsmethoden beschrieben, die von GKE für jede GatewayClass unterstützt werden:

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc
Client-zu-Gateway-TLS Unterstützt Unterstützt
Gateway zu Backend-TLS Unterstützt Unterstützt
Google Cloud-Zertifikatsressource Globales SSL-Zertifikat
CertificateMap		 Regionales SSL-Zertifikat
Selbstverwaltete Zertifikate mit Kubernetes-Secrets Unterstützt Unterstützt
Selbstverwaltete Compute Engine-SSL-Zertifikate Unterstützt Unterstützt
Von Google verwaltete Compute Engine-SSL-Zertifikate Unterstützt Nicht unterstützt
Selbstverwaltete SSL-Zertifikate mit Certificate Manager Unterstützt Unterstützt
Von Google verwaltete SSL-Zertifikate mit Zertifikatmanager Unterstützt Unterstützt

Nächste Schritte