Das Anwendungsbeispiel gesicherte Bank of KGE Enterprise ist eine containerbasierte Webanwendung, mit der Sie eine Onlinebank simulieren können. In diesem Beispiel wird ein Referenz-Cloud-Technologiestack vorgestellt, der die gesicherte Basis enthält, die Google Cloud-Dienste, die zur Unterstützung der Bank of GKE Enterprise sowie des Anwendungscodes der Bank of GKE Enterprise erforderlich ist.
Das gesicherte Bank of GKE Enterprise-Anwendungsbeispiel wird über Pipelines (Basispipeline, Infrastrukturpipeline, Anwendungspipeline) bereitgestellt, die unter Ressourcenbereitstellung beschrieben werden. Weiter wird das Config Management verwendet.
Die Beispielarchitektur basiert auf Designmustern, die in der Anleitung zur Härtung der Clustersicherheit, dem Sicherer GKE-Cluster-Repository, dem GKE Enterprise-Multi-Cloud-Workshop-Repository, imGKE Enterprise-Sicherheits-Blueprint und der Bank of GKE Enterprise-Anwendung definiert werden. Der vollständige Code für das gesicherte Bank of GKE Enterprise-Anwendungsbeispiel finden Sie im GitHub-Repository terraform-example-foundation-app.
Architektur der gesicherten Bank of GKE Enterprise-Anwendungsplattform
Das folgende Diagramm zeigt, wie das Beispiel der gesicherten Bank of GKE Enterprise-Anwendung auf der gesicherten Grundlage für deren Bereitstellung aufbaut. In diesem Beispiel wird die Bank of GKE Enterprise in den drei grundlegenden Umgebungen bereitgestellt: development, production und non-production. Die Hub-and-Spoke-VPC-Netzwerktopologie, die in Hub-and-Spoke beschrieben ist, wird von der Anwendung für das Netzwerk verwendet. Die Anwendung verwendet Google Cloud-Projekte als logische Sicherheitsgrenze.
Die Bank of GKE Enterprise-Anwendung fügt Projekten, die bereits für die Basis definiert sind, mehrere Projekte hinzu. Die zusätzlichen Projekte dienen zur Bereitstellung von Ressourcen, Konfigurationen und Anwendungen, die zur Unterstützung der Bank of GKE Enterprise benötigt werden (siehe folgende Tabelle).
| Ordner | Projekt | Beschreibung |
|---|---|---|
common
|
infra-cicd
|
Enthält die Infrastrukturpipeline, die in Die Infrastrukturpipeline beschrieben wird. Außerdem enthält dieses Projekt das Repository der Config Management-Richtlinie, das für die Konfiguration des GKE-Clusters verwendet wird. |
app-cicd
|
Enthält die Anwendungspipeline, die in Die Infrastrukturpipeline beschrieben wird. | |
development, non-production,production
|
boa-gke
|
Enthält die Bank of GKE Enterprise-Cluster und den GKE-Cluster mit Multi-Cluster-Ingress. Wird auch als environ-Hostprojekt für GKE Enterprise verwendet. |
boa-sql
|
Enthält die Cloud SQL for PostgreSQL-Datenbanken, die von der Bank of GKE Enterprise-Anwendung verwendet werden. | |
secret
|
Enthält Secret Manager- und KMS-Instanzen für Secrets, die für die Bank of GKE Enterprise-Anwendung spezifisch sind. | |
monitoring
|
Wird zum Speichern von Umgebungslogs und zum Überwachen der Umgebungsinstanz der Bank of GKE Enterprise-Anwendung verwendet. |
Wie im Diagramm unten gezeigt, werden pro Umgebung insgesamt drei Google Kubernetes Engine-Cluster (GKE) erstellt, um die Bank of GKE Enterprise bereitzustellen. Zwei Cluster (gke-boa-region1-01 und gke-boa-region2) fungieren als identische private GKE-Cluster in zwei verschiedenen Regionen, um für multiregionale Ausfallsicherheit zu sorgen. Der dritte Cluster (gke-mci-region1-01) dient als Konfigurationscluster für Multi-Cluster-Ingress.
Bank of GKE Enterprise-Anwendungskomponenten
Mit dem Beispiel der Bank of GKE Enterprise-Anwendung können Nutzer Anmeldekonten erstellen, sich bei ihrem Konto anmelden, ihren Transaktionsverlauf ansehen, Zahlungen vornehmen und Geld an Konten anderer Nutzer übertragen. Die Anwendung besteht aus sechs Diensten, die in der folgenden Tabelle beschrieben werden. Die Dienste werden als Container ausgeführt, die über REST APIs und gRPC APIs miteinander verbunden sind.
| Dienst | Sprache | Beschreibung |
|---|---|---|
frontend |
Python | Stellt einen HTTP-Server zur Bereitstellung der Website bereit. Enthält eine Log-in-Seite, eine Anmeldeseite und eine Startseite. |
ledger-writer |
Java | Akzeptiert und validiert eingehende Transaktionen, bevor sie in das Verzeichnis geschrieben werden. |
balance-reader |
Java | Stellt einen effizienten lesbaren Cache von Nutzerausgleichen bereit, wie aus ledger-db gelesen. |
transaction-history |
Java | Bietet einen effizienten lesbaren Cache früherer Transaktionen, wie aus ledger-db gelesen. |
user-service |
Python | Verwaltet Nutzerkonten und Authentifizierung. Der Dienst signiert JWTs, die von anderen Diensten zur Authentifizierung verwendet werden. |
contacts |
Python | Speichert eine Liste zusätzlicher Konten, die einem Nutzer zugeordnet sind. Diese Konten sind in den Formularen Zahlung senden und Zahlungen aufgeführt. |
Die Anwendung wird auf GKE Enterprise ausgeführt, der verwalteten Multi-Cloud-Anwendungsplattform von Google. Mit dieser Plattform können Sie den Lebenszyklus Ihrer Anwendungen erstellen, bereitstellen und verwalten. In der folgenden Tabelle sind die GKE Enterprise-Komponenten aufgeführt, die bei der Bereitstellung der Bank of GKE Enterprise-Anwendung verwendet werden.
| Anthos-Komponente | Mit |
|---|---|
| GKE-Cluster | Containerverwaltung |
| GKE Enterprise Configuration Management | Richtlinienverwaltung und -erzwingung |
| Anthos Service Mesh | Dienstverwaltung |
| Cloud Operations | Beobachtbarkeit und Plattformverwaltung |
| Binärautorisierung | Container-Image-Attestierung |
| Multi-Cluster-Ingress | Multi-Cluster-Ingress-Controller für GKE-Cluster |
Verteilte Dienste und Anthos Service Mesh
In der Bank of GKE Enterprise-Anwendung bietet Anthos Service Mesh zusätzliche Sicherheit, da Verschlüsselung, gegenseitige Authentifizierung und Autorisierung für die gesamte Kommunikation zwischen Arbeitslasten bereitgestellt wird. Für diese Bereitstellung verwendet Anthos Service Mesh eine eigene verwaltete private Zertifizierungsstelle (Mesh CA) zur Ausstellung von TLS-Zertifikaten zur Authentifizierung von Peers und um sicherzustellen, dass nur autorisierte Clients auf Dienste zugreifen können. Durch die Verwendung von mTLS (mutual TLS) für die Authentifizierung wird außerdem sichergestellt, dass alle TCP-Kommunikationen bei der Übertragung verschlüsselt werden. Für eingehenden Diensttraffic in das Mesh verwendet die Bank of GKE Enterprise ein Istio-Ingress-Gateway (istio-ingressgateway).
Die Bank von GKE Enterprise-Anwendung wird als verteilter Dienst ausgeführt, d. h. sie wird als Kubernetes-Dienst auf zwei oder mehr Kubernetes-Cluster ausgeführt. Der Kubernetes-Dienst wird in jedem Cluster im selben Namespace ausgeführt und dient als einzelner logischer Dienst. Ein verteilter Dienst wird auch dann ausgeführt, wenn ein oder mehrere GKE-Cluster ausgefallen sind, solange die fehlerfreien Cluster die Last verarbeiten können. Zum Erstellen eines verteilten Dienstes auf Clustern bietet Anthos Service Mesh die L4/L7-Konnektivität zwischen den Diensten, die auf den einzelnen Clustern ausgeführt werden. Sie können als ein logischer Dienst fungieren.
Bank of GKE-Clusterschutz
Die gesicherte Anwendung verwendet private GKE-Cluster, um ihren Sicherheitsstatus zu erhöhen. Weder die Clusterknoten noch die Steuerungsebene hat einen öffentlichen Endpunkt. Die Cluster in der gesicherten Anwendung sind durch VPC-Firewallregeln und hierarchische Firewallrichtlinien geschützt. Im Rahmen der Bereitstellung der gesicherten Anwendung wird für jede Umgebung eine Cloud NAT-Instanz verwendet, um Pods einen Mechanismus für den Zugriff auf Ressourcen mit öffentlichen IP-Adressen zu geben. Die GKE Sandbox bietet einen weiteren Schutz des Clusters, mit dem der Hostkernel der Knoten geschützt wird. Darüber hinaus verwendet der Cluster Shielded GKE-Knoten. Dadurch wird die Möglichkeit eines Angreifers eingeschränkt, die Identität eines Knotens zu übernehmen. Die Knoten führen Container-Optimized OS aus, um ihre Angriffsfläche begrenzen.
Das Web-Frontend der Bank of GKE Enterprise-Anwendung ist mithilfe von Multi-Cluster-Ingress dem Internet zugänglich. Multi-Cluster-Ingress erstellt einen GKE Enterprise-Balancer für die Bank of Anthos-Anwendung mit Cloud Load Balancing und erstellt und verwaltet auch Netzwerk-Endpunktgruppen (NEG).
Der Load-Balancer hat den Dienst istio-ingressgateway in beiden Clustern als Back-Ends und die NEGs verfolgen die Dienstendpunkte der beiden istio-ingressgateway-Dienste dynamisch, um sicherzustellen, dass der Load-Balancer fehlerfreie Back-Ends hat. Cloud Load Balancing verwendet die Netzwerkinfrastruktur von Google, um dem Bank of GKE Enterprise-Frontend eine Anycast-IP-Adresse bereitzustellen, die einen Zugriff mit geringer Latenz mit der Bank of GKE Enterprise-Anwendung ermöglicht und das Anwendungs-Frontend vor DDoS-Angriffen schützt. Die Weboberfläche der Bank of GKE Enterprise-Anwendung ist mit Google Cloud Armor vor Angriffen geschützt.
Cloud Domains wird zum Registrieren der öffentlichen Domain (boaongcp.cloud) verwendet, auf der das gesicherte Anwendungsbeispiel ausgeführt wird.
Cloud DNS wird verwendet, um eine DNS-Zonenbereitstellung mit niedriger Latenz und Hochverfügbarkeit zu ermöglichen.
Bank of GKE Enterprise-Namespaces
Die GKE-Cluster, die von der Bank of GKE Enterprise-Anwendung verwendet werden, sind in vier Namespaces unterteilt, um die Dienste zu trennen. Der Trafficfluss zwischen Namespaces wird durch Netzwerkrichtlinien eingeschränkt. Die Namespaces sind:
istio-system, das das Ingress-Gateway enthält.frontend, das den Frontend-Dienst der Bank of GKE Enterprise enthält.accounts, das die Nutzerdienste der Bank of GKE Enterprise enthält.transactions, das die Bank of GKE Enterprise-Transaktionsdienste enthält.
Alle Namespaces, die am Service Mesh beteiligt sind, werden mit dem Label istio.io/rev=REVISION eingefügt.
Mit dem Label kann der Ressourcencontroller den Sidecar-Envoy-Proxy automatisch in jeden Pod innerhalb des mit Labels versehenen Namespace einfügen.
Identitäts- und Zugriffssteuerung der Bank of GKE Enterprise
Die Dienste der Bank of GKE Enterprise-Anwendung werden in Pods ausgeführt, die Workload Identity verwenden. Dadurch erhält jeder Pod eine eindeutige Identität, die nur die minimalen, für den Betrieb des Dienstes erforderlichen Berechtigungen umfasst. Mit Workload Identity kann ein Kubernetes-Dienstkonto als Google-Dienstkonto fungieren. Dazu erstellen es eine sichere Zuordnung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto. Pods, die als Kubernetes-Dienstkonto ausgeführt werden, werden beim Zugriff auf Google Cloud APIs automatisch als Google-Dienstkonto authentifiziert, da Workload Identity es der Identitäts- und Zugriffsverwaltung (IAM) erlaubt, den Anmeldedaten des Kubernetes-Dienstkontos zu vertrauen.
Der Zugriff auf jede GKE-Steuerungsebene wird über einen Bastion Host mit einem Host in jeder Umgebung aktiviert. Jeder Bastion Host wird durch Identity-Aware Proxy geschützt. Der Zugriff auf die GKE-Cluster wird durch Google Groups für GKE-basierte,rollenbasierte Zugriffssteuerung (RBAC) in Kubernetes kontrolliert. Mit Gruppen können Sie Identitäten mithilfe eines zentralen Identitätsverwaltungssystems steuern, das von Identitätsadministratoren gesteuert wird. Anstatt die RBAC-Konfiguration zu aktualisieren, wenn eine Änderung für Berechtigungen erforderlich ist, kann ein Administrator die Gruppenmitgliedschaft ändern.
Datenbankstruktur der Bank of GKE Enterprise
Die Bank of GKE Enterprise-Anwendung verwendet zwei PostgreSQL-Datenbanken.
Eine Datenbank (ledger-db) wird für Transaktionen und die andere Datenbank (accounts-db) für Nutzerkonten verwendet. Die Datenbanken werden mit dem verwalteten Datenbankdienst Google bereitgestellt, Cloud SQL for PostgreSQL.
Die Datenbanken sind für die Notfallwiederherstellung mit regionenübergreifenden Replikaten konfiguriert und werden mit vom Kunden verwalteten Verschlüsselungsschlüsseln verschlüsselt.
Der Cloud SQL-Proxy wird verwendet, um mithilfe von Dienstkontoauthentifizierung Bank of GKE Enterprise-Mikrodienste mit Cloud SQL for PostgreSQL zu verbinden.
Bereitstellungsrollen für eine mit Bank of GKE Enterprise gesicherte Anwendung
Das vollständige Anwendungspaket der Bank of GKE Enterprise-gesicherten Anwendung wird von der Grundlage bis zur Softwareanwendung über eine Reihe automatisierter Systeme bereitgestellt, die unter Ressourcenbereitstellung beschrieben werden. Diese Systeme sind für die Verwendung durch verschiedene Gruppen vorgesehen, wie im Modell im Diagramm zu Zugriffsmustern für exmaple.com dargestellt. Die folgende Tabelle listet diese Gruppen, ihre Rollen, die von ihnen verwendeten Bereitstellungsmechanismen und die Ressourcen, für die sie verantwortlich sind, auf.
| Operatorteam | Rolle | Bereitstellungssysteme | Bereitgestellte Ressourcen |
|---|---|---|---|
| Plattformteam | Verantwortlich für die zentrale Erstellung und Verwaltung der Ressourcen, die mit der Sicherheitsbasis verbunden sind. | Fundament-Pipeline | Von der Fundament-Pipeline bereitgestellte Komponenten |
| Infrastrukturdienstteam | Verantwortlich für die Bereitstellung verwalteter Dienste und die Konfiguration der Anwendungsplattform, auf der Anwendungen bereitgestellt werden. | Infrastrukturpipeline, Config Management | |
| Anwendungsteam | Verantwortlich für die Entwicklung des Anwendungscode. | Anwendungspipeline | Softwarekomponenten der Bank of Anthos |
Durch die Verwendung automatisierter Pipelines für die Bereitstellung der gesicherten Anwendungspakete werden im Bereitstellungsprozess Sicherheits-, Prüf- und Rückverfolgbarkeit, Wiederholbarkeit, Kontrollierbarkeit und Compliance ermöglicht. Die Verwendung verschiedener Systeme mit unterschiedlichen Berechtigungen und das Aufteilen verschiedener Personen in verschiedene Betriebsgruppen führt zu einer Trennung der Verantwortlichkeiten. So können Sie dem Grundsatz der geringsten Berechtigung folgen.
Config Management
Die gesicherte Anwendung verwendet Config Management, um GKE-Arbeitslastrichtlinien und -ressourcen zu verwalten.
Config Management verwendet ein Git-Repository, das als Single Source of Truth für deklarierte Richtlinien dient, die in einer Konfiguration gespeichert sind.
Konfigurationen werden mithilfe einer Verzweigungsstrategie auf dem Git-Repository auf die Umgebungen (development, production und non-production) angewendet, in dem die Konfigurationen gespeichert sind.
Config Management verwendet einen deklarativen Ansatz für die Richtlinien- und Ressourcenverwaltung. Der Cluster überprüft kontinuierlich den Clusterstatus und wendet den in der Konfiguration angegebenen Status an, um Richtlinien zu erzwingen.
Config Management funktioniert in Verbindung mit dem Policy Controller. Der Policy Controller ist ein dynamischer Admission-Controller von Kubernetes, der die Compliance Ihrer Cluster mit Richtlinien in Bezug auf Sicherheit, Vorschriften und Geschäftsregeln kontrolliert, auditiert und erzwingt. Der Policy Controller erzwingt die Compliance Ihrer Cluster über Richtlinien, die als Einschränkungen bezeichnet werden. Der Policy Controller basiert auf dem Open-Source-Projekt Gatekeeper.
Logging und Monitoring
Die Logging- und Monitoring-Integration in GKE bietet Cloud Logging- und Cloud Monitoring-Dienste für die Bank of GKE Enterprise-Anwendung. Cloud Monitoring bietet vordefinierte Monitoring-Dashboards für GKE. Mit Cloud Logging können Sie System- und Anwendungslogs in zentralen Log-Buckets erfassen.
Die gesicherte Anwendung hat in jedem Umgebungsordner ein Projekt, das zum Speichern von Logs und für einen Monitoring-Arbeitsbereich verwendet wird. Die Sicherheitsgrundlage hat ein separates Logging-Projekt, in das die aggregierten Cloud-Audit-Logs aus der gesamten Google Cloud-Organisation exportiert werden. Der in diesem Abschnitt beschriebene Logging-Mechanismus bezieht sich auf die gesicherte Anwendung.
Das Security Command Center bietet einen Einblick in den allgemeinen Sicherheitsstatus der gesicherten Anwendung. Security Command Center stellt die gesicherte Anwendung mit Container Threat Detection bereit. Dieser Dienst überwacht kontinuierlich den Zustand von Container-Images und wertet alle Änderungen und Fernzugriffsversuche aus, um Laufzeitangriffe nahezu in Echtzeit zu erkennen. Die Konfiguration von Security Command Center und Container Threat Detection wird in Security Command Center beschrieben.
Die gesicherte Anwendung verwendet den Web Security Scanner, um Sicherheitslücken in der Bank of GKE Enterprise-Anwendung zu erkennen. Dies erfolgt durch Crawling der Anwendung, wobei allen Links ab der Basis-URL (boaongcp.cloud) gefolgt wird. Anschließend wird versucht, so viele Nutzereingaben und Event-Handler wie möglich anzuwenden.
Zuordnung von BeyondProd-Sicherheitsgrundsätzen zur gesicherten Anwendung
Google leistete vor über 15 Jahren Pionierarbeit in Sachen containerbasierte Architekturen, als wir zu Containern und der Containerorchestrierung wechselten, um eine höhere Ressourcennutzung zu erreichen, hochverfügbare Anwendungen zu erstellen und die Arbeit für Google-Entwickler zu vereinfachen. Diese containerbasierte Architektur erforderte einen anderen Sicherheitsmodus. Das relevante Sicherheitsmodell wird BeyondProd genannt und umfasst mehrere wichtige, der Anwendungsarchitektur von Bank of GKE Enterprise zugeordnete Sicherheitsgrundsätze, wie in der folgenden Tabelle dargestellt.
| Sicherheitsgrundsatz | Zuordnung zur gesicherten Anwendungsarchitektur |
|---|---|
| Schutz des Netzwerks am Rand | Cloud Load Balancing |
| Google Cloud Armor | |
| VPC mit privaten GKE-Clustern | |
| Firewallrichtlinie | |
| Kein inhärentes gegenseitiges Vertrauen unter den Diensten | Anthos Service Mesh |
| Workload Identity | |
| Netzwerkrichtlinie | |
| Vertrauenswürdige Maschinen, auf denen Code bekannter Herkunft ausgeführt wird | Binärautorisierung |
| Shielded GKE-Knoten | |
| Nadelöhre für eine konsistente Richtlinienerzwingung bei allen Diensten | Config Management |
| Policy Controller | |
| Einfacher, automatisierter und standardisierter Rollout von Änderungen | Fundament-Pipeline |
| Infrastrukturpipeline | |
| Anwendungspipeline | |
| Config Management | |
| Isolation von Arbeitslasten, die dasselbe Betriebssystem verwenden | GKE Sandbox |
| Container-Optimized OS |
Pipelines, die zur Bereitstellung von Architekturkomponenten der Bank of GKE Enterprise verwendet werden
Wie am Anfang von Sichere Anwendungen erstellen und bereitstellen beschrieben, wird die Bank of GKE Enterprise-Anwendung unter Einsatz einer Kombination aus Fundament-Pipeline, Infrastruktur-Pipeline, manuellen Prozessen und Config Management bereitgestellt. Die folgenden Tabellen zeigen, welche Komponenten mit welchen Methoden bereitgestellt werden.
In dieser Tabelle werden die von der Fundament-Pipeline bereitgestellten Komponenten beschrieben.
| Architekturkomponente | Zweck |
|---|---|
| Projekt | Bietet eine logische Grenze für Google Cloud-Ressourcen und -Dienste. Die Grenze wird verwendet, um die Bereitstellung von Bank of GKE Enterprise zu segmentieren. |
| Virtual Private Cloud-Netzwerk | Stellt Netzwerkdienste für Compute Engine- und GKE-Ressourcen über regionale Subnetze bereit, die die IP-Adressbereiche für Bank of GKE Enterprise-Cluster definieren. |
| VPC-Firewallregeln | Definiert Zulassungs- und Ablehnungsregeln, die auf den Netzwerk-Traffic angewendet werden, um den Zugriff auf die Bank of GKE Enterprise-Clustern zu steuern. |
| IAM-Rollen | Definiert Berechtigungen, die innerhalb der Bank of GKE Enterprise-Projekte verwendet werden. |
| Cloud APIs | Aktiviert APIs zur Unterstützung der Bank of GKE Enterprise-Bereitstellung. |
| Cloud DNS | Veröffentlicht den Bank of GKE Enterprise-Domainnamen im globalen DNS. |
In dieser Tabelle werden die Komponenten beschrieben, die von der Infrastrukturpipeline bereitgestellt werden.
| Architekturkomponente | Zweck |
|---|---|
| GKE | Bietet Hosting für die Mikrodienste der containerisierten Bank of GKE Enterprise-Anwendung. |
| Cloud SQL for PostgreSQL | Bietet Hosting für das Daten-Backend für die Bank of GKE Enterprise-Anwendung. |
| Cloud-Schlüsselverwaltung | Bietet einen Schlüsselverschlüsselungsschlüssel für die Verschlüsselung basierend auf kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) für Cloud SQL for PostgreSQL, GKE und Secret Manager. |
| Secret Manager | Bietet einen Secret-Speicher für das RSA-Schlüsselpaar, das für die JWT-basierte Nutzerauthentifizierung verwendet wird. |
| Compute Engine | Bietet einen Bastion Host für den Zugriff auf die GKE-Steuerungsebene (API-Server), um Config Management und Anthos Service Mesh zu bootstrappen. |
| Statische externe IP-Adresse | Stellt eine reservierte IP-Adresse bereit, die Multi-Cluster-Ingress an einen Load-Balancer bindet. |
| Google Cloud Armor | Bietet eine Firewall für die Webanwendung und DDoS-Schutz. |
In dieser Tabelle werden die Komponenten beschrieben, die über einen manuellen Bootstrap-Prozess vom Bastion Host bereitgestellt werden.
| Architekturkomponente | Zweck |
|---|---|
| Config Management | Bietet die Konfigurationsverwaltung für die Bank of GKE Enterprise-Anwendung. Config Management Version 1.1 und höher enthalten Policy Controller als Komponente. |
| Anthos Service Mesh | Bietet eine Service Mesh-Funktion zur Sicherung der Kommunikation (mit mTLS) zwischen den Mikrodiensten der Bank of GKE Enterprise-Anwendung. |
In dieser Tabelle werden die von Config Management bereitgestellten Komponenten beschrieben.
| Architekturkomponente | Zweck | Konfigurationsbereich |
|---|---|---|
| VirtualService | Stellt eine Konfiguration bereit, die ein namenbasiertes Routing und Canary-Rollouts ermöglicht. | Benutzerdefinierte Istio-Ressource |
| DestinationRule | Definiert Richtlinien, Load-Balancing, mTLS und Schutzschalter. | |
| AuthorizationPolicy | Definiert die Zugriffssteuerung für Arbeitslasten im Service Mesh. | |
| Dienst | Definiert die für den Zugriff auf den logischen Satz von Pods verwendete virtuelle IP-Adresse/den verwendeten DNS-Namen. | Kubernetes-Arbeitslastdefinitionen |
| Deployment | Stellt eine deklarative Vorlage für Pods und Replikatsets bereit. | |
| RBAC (Rollen und Bindungen) | Definiert, welche Autorisierung ein Kubernetes-Dienstkonto auf Cluster- oder Namespace-Ebene hat. | Kubernetes-Identität und -Autorisierung |
| Workload Identity | Definiert das Google Cloud-Dienstkonto, das für den Zugriff auf Google Cloud-Ressourcen verwendet wird. | |
| Kubernetes-Dienstkonto | Definiert eine Identität, die von einem Kubernetes-Dienst verwendet wird. | |
| Namespace | Definiert die logischen Cluster innerhalb des physischen Clusters. | |
| Policy Controller | Definiert Einschränkungen, die zum Erzwingen der Compliance auf Kubernetes-Clustern dienen. | Kubernetes-Härtung |
IP-Adressbereiche der Bank of GKE Enterprise-Ressourcen
Das Beispiel für eine von Bank of GKE Enterprise gesicherte Anwendung erfordert, dass mehrere IP-Adressbereiche in den Umgebungen development, non-production und production zugewiesen werden. Jeder von der Bank von GKE Enterprise verwendete GKE-Cluster benötigt separate IP-Adressbereiche, die den Knoten, Pods, Diensten und der Steuerungsebene zugewiesen sind. Sowohl die Cloud SQL-Instanzen als auch die Bastion Hosts erfordern separate IP-Adressbereiche. Wenn Sie ein eigenes Schema zur Zuweisung von IP-Adressen entwerfen müssen, sollten Sie den GKE-Leitfäden und Empfehlungen folgen.
In folgenden Tabellen sind die Spoke-VPC-Subnetze und IP-Adressbereiche aufgeführt, die in den verschiedenen Umgebungen verwendet werden, um die gesicherte Bank of GKE Enterprise-Anwendung bereitzustellen:
development-Umgebungnon-production-Umgebungproduction-Umgebung
In dieser Tabelle werden die IP-Adressbereiche der Bank of GKE Enterprise-Ressourcen für die Entwicklungsumgebung beschrieben:
| Ressource/Subnetz | Primärer IP-Bereich | Pod-IP-Adressbereich | Dienst-IP-Adressbereich | IP-Bereich der GKE-Steuerungsebene |
|---|---|---|---|---|
GKE-Cluster mit Multi-Cluster-Ingress
subnet-usw1-01 |
10.0.64.0/29
|
100.64.64.0/22
|
100.64.68.0/26
|
100.64.70.0/28
|
subnet-usw1-02
GKE-Clusterregion 1 der Anwendung |
10.0.65.0/29
|
100.64.72.0/22
|
100.64.76.0/26
|
100.64.78.0/28
|
Bastion Host
subnet-usw1-03
|
10.0.66.0/29
|
|||
development GKE-Clusterregion 2 der Anwendung
subnet-use4-01
|
10.1.64.0/29
|
100.65.64.0/22
|
100.65.68.0/26
|
100.65.70.0/28
|
| Cloud SQL |
10.16.64.0/24
|
In dieser Tabelle werden die IP-Adressbereiche der Bank of GKE Enterprise-Ressourcen für die Nicht-Produktionsumgebung beschrieben:
| Ressource/Subnetz | Primärer IP-Bereich | Pod-IP-Adressbereich | Dienst-IP-Adressbereich | IP-Bereich der GKE-Steuerungsebene |
|---|---|---|---|---|
GKE-Cluster mit Multi-Cluster-Ingress
subnet-usw1-01 |
10.0.128.0/29
|
100.64.128.0/22
|
100.64.132.0/26
|
100.64.134.0/28
|
non-production GKE-Clusterregion 1 der Anwendung
subnet-usw1-02
|
10.0.129.0/29
|
100.64.136.0/22
|
100.64.140.0/26
|
100.64.142.0/28
|
non-production bastion host / subnet-usw1-03
|
10.0.130.0/29
|
|||
non-production GKE-Clusterregion 2 der Anwendung
subnet-use4-01
|
10.1.128.0/29
|
100.65.128.0/22
|
100.65.132.0/26
|
100.65.134.0/28
|
non-production Cloud SQL |
10.16.128.0/24
|
In dieser Tabelle werden die IP-Adressbereiche der Bank of GKE Enterprise-Ressourcen für die Produktionsumgebung beschrieben:
| Ressource/Subnetz | Primärer IP-Bereich | Pod-IP-Adressbereich | Dienst-IP-Adressbereich | IP-Bereich der GKE-Steuerungsebene |
|---|---|---|---|---|
production Multi Cluster Ingress GKE cluster / subnet-usw1-01
|
10.0.192.0/29
|
100.64.192.0/22
|
100.64.196.0/26
|
100.64.198.0/28
|
production App-GKE-Clusterregion 1
subnet-usw1-02
|
10.0.193.0/29
|
100.64.200.0/22
|
100.64.204.0/26
|
100.64.206.0/28
|
Bastion Host
subnet-usw1-03
|
10.0.194.0/29
|
|||
App-GKE-Clusterregion 2
subnet-use4-01
|
10.1.192.0/29
|
100.65.192.0/22
|
100.65.196.0/26
|
100.65.198.0/28
|
| Cloud SQL-Instanz |
10.16.192.0/24
|
Nächste Schritte
- Lesen Sie die Zusammenfassung (nächstes Dokument dieser Reihe)