Gesicherte Anwendungen erstellen und bereitstellen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Das Anwendungsbeispiel "gesicherte Bank of Anthos" 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 Anthos erforderlich ist, sowie der Bank of Anthos-Anwendungscode.

Das gesicherte Bank of Anthos-Anwendungsbeispiel wird über Pipelines (Basispipeline, Infrastrukturpipeline, Anwendungspipeline) bereitgestellt, die unter Ressourcenbereitstellung beschrieben werden. Weiter wird das Anthos Config Management verwendet.

Die Beispielarchitektur basiert auf Designmustern, die in der Anleitung zur Härtung der Clustersicherheit, dem Sicherer GKE-Cluster-Repository, dem Anthos-Multi-Cloud-Workshop-Repository, imAnthos-Sicherheits-Blueprint und der Bank of Anthos-Anwendung definiert werden. Der vollständige Code für das gesicherte Bank of Anthos-Anwendungsbeispiel finden Sie im GitHub-Repository terraform-example-foundation-app.

Architektur der gesicherten Bank of Anthos-Plattform

Abbildung 2.12.1 zeigt, wie das Beispiel für eine gesicherte Anwendung der Bank of Anthos auf der gesicherten Grundlage für ihre Bereitstellung aufbaut. In diesem Beispiel wird die Bank of Anthos 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.

Abbildung 2.12.1 Bank of Anthos-Projektstruktur auf der gesicherten Basis

Abbildung 2.12.1 Bank of Anthos-Projektstruktur auf der gesicherten Basis

Die Bank of Anthos-Anwendung fügt Projekten, die bereits für die Basis definiert sind, mehrere Projekte hinzu. Die zusätzlichen Projekte dienen der Bereitstellung von Ressourcen, Konfigurationen und Anwendungen, die zur Unterstützung der Bank of Anthos erforderlich sind, wie in Tabelle 2.12.1 gezeigt.

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 Anthos 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 Anthos-Cluster und den GKE-Cluster mit Multi-Cluster-Ingress. Wird auch als environ-Hostprojekt für Anthos verwendet.
boa-sql Enthält die Cloud SQL for PostgreSQL-Datenbanken, die von der Bank of Anthos-Anwendung verwendet werden.
secret Enthält Secret Manager- und KMS-Instanzen für Secrets, die für die Bank of Anthos-Anwendung spezifisch sind.
monitoring Wird zum Speichern von Umgebungslogs und zum Monitoring der Umgebungsinstanz der Bank of Anthos-Anwendung verwendet.

Tabelle 2.12.1 Zusätzliche Bank of Anthos-Projekte

Wie in Abbildung 2.12.2 gezeigt, werden in jeder Umgebung drei GKE-Cluster (Google Kubernetes Engine) erstellt, um die Bank of Anthos 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.

Abbildung 2.12.2 Detaillierte Architektur der Bank of Anthos

Abbildung 2.12.2 Detaillierte Architektur der Bank of Anthos

Bank of Anthos-Anwendungskomponenten

Mit dem Beispiel der Bank of Anthos-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 Tabelle 2.12.2 beschrieben sind. 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.

Tabelle 2.12.2 Bank of Anthos-Softwarekomponenten

Die Anwendung wird auf Anthos ausgeführt, der verwalteten Multi-Cloud-Anwendungsplattform von Google. Mit dieser Plattform können Sie den Lebenszyklus Ihrer Anwendungen erstellen, bereitstellen und verwalten. In Tabelle 2.12.3 werden die Anthos-Komponenten beschrieben, die bei der Bereitstellung der Bank of Anthos-Anwendung verwendet werden.

Anthos-Komponente Nutzung
Anthos-Cluster Containerverwaltung
Anthos 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 Anthos-Cluster

Tabelle 2.12.3 Anthos-Komponenten, die in der Bank of Anthos-Anwendung bereitgestellt werden

Verteilte Dienste und Anthos Service Mesh

In der Bank of Anthos-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 Anthos ein Istio-Ingress-Gateway (istio-ingressgateway).

Die Bank von Anthos-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 Anthos-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-Front-End der Bank of Anthos-Anwendung ist mithilfe von Multi-Cluster-Ingress dem Internet zugänglich. Multi-Cluster-Ingress erstellt einen Load-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 Anthos-Front-End eine Anycast-IP-Adresse bereitzustellen, die einen Zugriff mit geringer Latenz mit der Bank of Anthos-Anwendung ermöglicht und das Anwendungs-Front-End vor DDoS-Angriffen schützt. Die Weboberfläche der Bank of Anthos-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 Anthos-Namespaces

Die GKE-Cluster, die von der Bank of Anthos-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 mit dem Front-End-Dienst der Bank of Anthos.
  • accounts, das die Nutzerdienste der Bank of Anthos enthält.
  • transactions, das die Bank of Anthos-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 Anthos

Die Dienste der Bank of Anthos-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 Anthos

Die Bank of Anthos-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 Anthos-Mikrodienste mit Cloud SQL for PostgreSQL zu verbinden.

Bereitstellungsrollen für die gesicherte Bank of Anthos-Anwendung

Das vollständige Anwendungspaket der Bank of Anthos-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 in Abbildung 2.5.3 dargestellt. In Tabelle 2.12.4 sind die Gruppen, ihre Rollen, der von ihnen verwendete Bereitstellungsmechanismus und die Ressourcen aufgeführt, für die sie verantwortlich sind.

Operatorteam Rolle Bereitstellungssysteme Bereitgestellte Ressourcen
Plattformteam Verantwortlich für die zentrale Erstellung und Verwaltung der Ressourcen, die mit der Sicherheitsbasis verbunden sind. Fundament-Pipeline Tabelle 2.12.6
Infrastrukturdienstteam Verantwortlich für die Bereitstellung verwalteter Dienste und die Konfiguration der Anwendungsplattform, auf der Anwendungen bereitgestellt werden. Infrastrukturpipeline, Anthos Config Management Tabelle 2.12.7, Tabelle 2.12.8, Tabelle 2.12.9
Anwendungsteam Verantwortlich für die Entwicklung des Anwendungscode. Anwendungspipeline Tabelle 2.12.2

Tabelle 2.12.4 Operatorteams, Rollen und die entsprechenden Bereitstellungssysteme

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.

Anthos Config Management

Die gesicherte Anwendung verwendet Anthos Config Management, um GKE-Arbeitslastrichtlinien und -ressourcen zu verwalten. Anthos 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.

Anthos 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.

Anthos 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

Cloud Operations for GKE wird zum Bereitstellen von Cloud Logging- und Cloud Monitoring-Diensten für die Bank of Anthos-Anwendung verwendet. Cloud Operations for GKE bietet vordefinierte Monitoring-Dashboards für GKE. Mit Cloud Operations for GKE können Sie System- und Anwendungslogs auch 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 Anthos-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 Sicherheitsgrundsätze, die, wie in der Tabelle 2.12.5 gezeigt, der Bank of Anthos-Anwendungsarchitektur zugeordnet sind.

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 Anthos Config Management
Policy Controller
Einfacher, automatisierter und standardisierter Rollout von Änderungen Fundament-Pipeline
Infrastrukturpipeline
Anwendungspipeline
Anthos Config Management
Isolation von Arbeitslasten, die dasselbe Betriebssystem verwenden GKE Sandbox
Container-Optimized OS

Tabelle 2.12.5 Zuordnung von BeyondProd-Prinzipien zur gesicherten Anwendung

Pipelines, die zur Bereitstellung von Bank of Anthos-Architekturkomponenten verwendet werden

Wie am Anfang von Sichere Anwendungen erstellen und bereitstellen beschrieben, wird die Bank of Anthos-Anwendung unter Einsatz einer Kombination aus Fundament-Pipeline, Infrastruktur-Pipeline, manuellen Prozessen und Anthos Config Management bereitgestellt. Table 2.12.6, Table 2.12.7, Table 2.12.8 und Tabelle 2.12.9 zeigen, welche Komponenten mit welchen Methoden bereitgestellt werden.

Architekturkomponente Zweck
Projekt Bietet eine logische Grenze für Google Cloud-Ressourcen und -Dienste. Die Grenze wird verwendet, um die Bank of Anthos-Bereitstellung 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 Anthos-Cluster definieren.
VPC-Firewallregeln Definiert Zulassungs- und Ablehnungsregeln, die auf den Netzwerk-Traffic angewendet werden, um den Zugriff auf die Bank of Anthos-Clustern zu steuern.
IAM-Rollen Definiert Berechtigungen, die innerhalb der Bank of Anthos-Projekte verwendet werden.
Cloud APIs Aktiviert APIs zur Unterstützung der Bank of Anthos-Bereitstellung.
Cloud DNS Veröffentlicht den Bank of Anthos-Domainnamen im globalen DNS.

Tabelle 2.12.6 Von der Foundation-Pipeline bereitgestellte Komponenten

Architekturkomponente Zweck
GKE Bietet Hosting für die Mikrodienste der containerisierten Bank of Anthos-Anwendung.
Cloud SQL for PostgreSQL Bietet Hosting für das Daten-Back-End für die Bank of Anthos-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 Anthos 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.

Tabelle 2.12.7 Von der Infrastrukturpipeline bereitgestellte Komponenten

Architekturkomponente Zweck
Anthos Config Management Bietet die Konfigurationsverwaltung für die Bank of Anthos-Anwendung. Anthos 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 Anthos-Anwendung.

Tabelle 2.12.8 Über einen manuellen Bootstrap-Prozess vom Bastion Host bereitgestellte Komponenten

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

Tabelle 2.12.9 Von Anthos Config Management bereitgestellte Komponenten

IP-Adressbereiche der Bank of Anthos-Ressourcen

Das Beispiel für eine von Bank of Anthos gesicherte Anwendung erfordert, dass mehrere IP-Adressbereiche in den Umgebungen development, non-production und production zugewiesen werden. Jeder von der Bank von Anthos 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 Anthos-Anwendung bereitzustellen:

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

Tabelle 2.12.10 IP-Adressbereiche der Bank of Anthos-Ressourcen für die Entwicklungsumgebung

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

Tabelle 2.12.11 IP-Adressbereiche der Bank of Anthos-Ressourcen für die Nicht-Produktionsumgebung

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

Tabelle 2.12.12 IP-Adressbereich der Bank of Anthos-Ressource in der Produktionsumgebung