Connect-Gateway mit Drittanbieteridentitäten einrichten

Dieser Leitfaden richtet sich an Plattformadministratoren, die das Connect-Gateway in einem Projekt einrichten müssen, das Nutzer enthält, die keine Google-Identitäten haben und nicht zu Google Workspace gehören. In diesem Leitfaden werden diese Identitäten als "Drittanbieteridentitäten" bezeichnet. Bevor Sie diesen Leitfaden lesen, sollten Sie mit den Konzepten unter Connect-Gateway – Übersicht vertraut sein. Informationen zum Autorisieren einzelner Google-Konten finden Sie unter Connect-Gateway einrichten. Informationen zum Google Groups-Support finden Sie unter Connect-Gateway mit Google Groups einrichten.

Mit der Konfiguration in diesem Leitfaden können sich Nutzer über die Google Cloud CLI, das Connect-Gateway und die Google Cloud Console in Flottenclustern anmelden.

Unterstützte Clustertypen

Sie können die Zugriffssteuerung mit Identitäten von Drittanbietern über das Connect-Gateway für die folgenden registrierten Clustertypen einrichten:

• GKE-Cluster
• Google Distributed Cloud (nur Software) auf VMware und Bare Metal aus Anthos (GKE Enterprise) 1.13 und höher
• GKE on AWS und GKE on Azure ab Kubernetes Version 1.25.
• Angehängte Cluster ab Anthos (GKE Enterprise) 1.16 und höher.

Wenn Sie lokale Cluster aktualisieren müssen, um diese Funktion zu verwenden, lesen Sie die Artikel GKE Enterprise-Cluster für VMware aktualisieren und GKE Enterprise-Cluster auf Bare-Metal aktualisieren.

Wenn Sie einen anderen Anwendungsfall für GKE-Clusterumgebungen haben als die oben aufgeführten, wenden Sie sich an Cloud Customer Care oder das Connect-Gateway-Team.

Funktionsweise

Wie in der Übersicht beschrieben, verwenden Nutzer möglicherweise Identitätsanbieter, die nicht Google Workspace oder Cloud Identity sind. Mit der Mitarbeiteridentitätsföderation können Nutzer über ihre Drittanbieter-Identitätsanbieter wie Okta oder Azure Active Directory über das Connect-Gateway auf ihre Cluster zugreifen. Im Gegensatz zu Google-Konten werden Drittanbieternutzer durch ein IAM-Hauptkonto (Identity and Access Management) vertreten, das dem folgenden Format folgt:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

• WORKFORCE_POOL_ID ist der Name des Personalpools, der den entsprechenden Drittpartei-Identitätsanbieter enthält.

• SUBJECT_VALUE ist die Zuordnung der Identität des Drittanbieters zu einem Google-Subjekt.

Bei Drittanbietergruppen hat das IAM-Hauptkonto folgendes Format:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

Das folgende Diagramm zeigt einen typischen Ablauf für einen Drittanbieternutzer, der sich bei einem Cluster authentifiziert und Befehle für den Cluster ausführt, wobei dieser Dienst aktiviert ist. Damit dieser Ablauf erfolgreich ist, muss eine Richtlinie für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) entweder für den Nutzer oder für eine Gruppe auf den Cluster angewendet werden.

Für einzelne Nutzer muss im Cluster eine RBAC-Richtlinie mit dem vollständigen IAM-Hauptkontonamen des Nutzers vorhanden sein.

Wenn Sie die Gruppenfunktion verwenden, muss für eine Gruppe, die

1. Enthält den Nutzer [e-mail] als Mitglied.

2. Ist in einer Zuordnung für einen Identitätsanbieter in einem Mitarbeiterpool enthalten, der sich in der Google Cloud-Organisation von Alice befindet.

Hinweis: GKE Identity Service muss konfiguriert sein, damit Gruppen-Funktionen von Drittanbietern auf Clustern von Flottenmitgliedern außerhalb von Google Cloud funktionieren.

1. Der Nutzer [e-mail] meldet sich mit seiner Drittanbieter-Identität in gcloud an. Dazu nutzt er die Browser-basierte Anmeldung eines Drittanbieters. Wenn der Nutzer den Cluster über die Befehlszeile verwenden möchte, ruft er das Gateway kubeconfig des Clusters ab, wie unter Connect-Gateway verwenden beschrieben.
2. Der Nutzer sendet eine Anfrage, indem er einen kubectl-Befehl ausführt oder die Google Kubernetes Engine-Seiten Arbeitslasten oder Objektbrowser in der Google Cloud Console öffnet.
3. Die Anfrage wird vom Connect-Gateway empfangen, das die Drittanbieter-Authentifizierung mithilfe der Workforce Identity-Föderation verarbeitet.
4. Das Connect-Gateway führt eine Autorisierungsprüfung mit IAM durch.
5. Der Connect-Dienst leitet die Anfrage an den auf dem Cluster ausgeführten Connect Agent weiter. Die Anfrage wird zusammen mit den Anmeldedaten des Nutzers zur Authentifizierung und Autorisierung im Cluster bereitgestellt.
6. Der Connect Agent leitet die Anfrage an den Kubernetes API-Server weiter.
7. Der Kubernetes API-Server leitet die Anfrage an GKE Identity Service weiter, der die Anfrage validiert.
8. GKE Identity Service gibt die Nutzer- und Gruppeninformationen des Drittanbieters an den Kubernetes API-Server zurück. Der Kubernetes API-Server kann diese Informationen dann dazu verwenden, die Anfrage basierend auf den konfigurierten RBAC-Richtlinien des Clusters zu autorisieren.

Hinweis

• Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:

  • Die neueste Version von Google Cloud CLI, dem Befehlszeilentool für die Interaktion mit Google Cloud.
  • Das Kubernetes-Befehlszeilentool kubectl zur Interaktion mit Ihren Clustern.

  Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mit Google Cloud verwenden, sind diese Tools für Sie installiert.

• Achten Sie darauf, dass die gcloud CLI für die Verwendung mit Ihrem Projekt initialisiert wurde.

• In dieser Anleitung wird davon ausgegangen, dass sich roles/owner in Ihrem Projekt befindet. Wenn Sie kein Projektinhaber sind, benötigen Sie möglicherweise zusätzliche Berechtigungen, um einige Einrichtungsschritte auszuführen.

• Für Cluster außerhalb von Google Cloud muss GKE Identity Service Google APIs aus Ihrem Cluster aufrufen, um die Authentifizierung abzuschließen. Prüfen Sie, ob Ihre Netzwerkrichtlinie ausgehenden Traffic über einen Proxy erfordert.

Drittanbieter-Identitätsattributzuordnungen mit Workforce Identity einrichten

Achten Sie darauf, dass für Ihre Google Cloud-Organisation ein Personalpool und ein Identitätsanbieter eingerichtet sind. Folgen Sie dazu der Anleitung für Ihren Identitätsanbieter:

• Azure AD
• Okta
• Anderes OIDC oder SAML 2.0

Hinweis: Für jeden Identitätsanbieter gilt ein Limit von 4 Kilobyte für die Attributzuordnung, einschließlich Gruppen.

APIs aktivieren

Aktivieren Sie die Connect Gateway API und die erforderlichen Abhängigkeits-APIs, um das Gateway Ihrem Projekt hinzuzufügen. Wenn sich Ihre Nutzer nur über die Google Cloud Console bei Clustern authentifizieren möchten, müssen Sie connectgateway.googleapis.com nicht aktivieren. Die verbleibenden APIs müssen jedoch aktiviert werden.

gcloud services enable --project=PROJECT_ID  \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

Hinweis:

Wenn Sie kein Projektinhaber sind, müssen Sie die Berechtigung serviceusage.services.enable erhalten, bevor Sie APIs für Ihr Projekt aktivieren können.

GKE Identity Service einrichten

Die Funktion zur Unterstützung von Drittanbieteridentitäten des Connect-Gateways verwendet GKE Identity Service, um Gruppenmitgliedschaftsinformationen von Google abzurufen. Weitere Informationen zu GKE Identity Service finden Sie unter Einführung in GKE Identity Service.

Wenn Sie GKE-Cluster mit dem Gateway verwenden, müssen Sie GKE Identity Service nicht einrichten, um die Identitätsunterstützung von Drittanbietern zu verwenden. Folgen Sie stattdessen der Anleitung unter Google Groups for RBAC konfigurieren und fahren Sie mit IAM-Rollen zuweisen fort, um Zugriff auf Cluster über das Gateway zu gewähren.

Wenn Sie in GKE angehängte Cluster mit dem Gateway verwenden, ist GKE Identity Service für die Drittanbieter-Identitätsunterstützung nicht erforderlich. Folgen Sie der Anleitung für den ausgewählten Clustertyp, um die Unterstützung von Drittanbieteridentitäten einzurichten:

• Verbindung zum mit EKS angehängten Cluster herstellen
• Mit Ihrem mit AKS angehängten Cluster verbinden
• Verbindung zu anderen Clustertypen herstellen

Installation von GKE Identity Service prüfen

GKE Identity Service ist standardmäßig ab Version 1.7 auf GKE-Clustern installiert. Der Support für Drittanbieteridentitäten erfordert jedoch Version 1.13 oder höher. Mit dem folgenden Befehl können Sie prüfen, ob der Dienst korrekt auf Ihrem Cluster installiert ist:

kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service

Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Clusters.

Unterstützung von Drittanbieteridentitäten für Gruppen konfigurieren

Wenn Ihr Cluster oder Ihre Flotte bereits für die Unterstützung von Google Groups konfiguriert ist, sind keine weiteren Schritte erforderlich. Sie können mit Drittanbieter-Nutzern und ‑gruppen IAM-Rollen zuweisen fortfahren.

Wenn Sie Google Distributed Cloud auf VMware oder Bare-Metal verwenden, bestimmt die Art und Weise, wie Sie GKE Identity Service einrichten, wie Sie die Funktion für Drittanbietergruppen konfigurieren müssen.

Wenn Sie GKE Identity Service zum ersten Mal verwenden, können Sie die Unterstützung für Drittanbietergruppen mit Fleet APIs (empfohlen) oder mit kubectl konfigurieren.

Wenn Sie GKE Identity Service nicht zum ersten Mal verwenden, beachten Sie einen der folgenden Punkte:

• Wenn Sie bereits GKE Identity Service für einen anderen Identitätsanbieter auf Flottenebene eingerichtet haben, ist die Funktion für Drittanbietergruppen standardmäßig aktiviert. Weitere Informationen und ggf. erforderliche zusätzliche Einstellungen finden Sie unten im Abschnitt Flotte.

• Wenn Sie bereits GKE Identity Service für einen anderen Identitätsanbieter für jeden Cluster eingerichtet haben, finden Sie im Abschnitt Kubectl unten eine Anleitung zum Aktualisieren Ihrer Konfiguration für die Drittanbieter-Gruppenfunktion.

Flotte

Sie können den Zugriff auf Drittanbietergruppen mithilfe von Fleet Feature APIs über die Google Cloud Console oder die Befehlszeile konfigurieren.

Console

Wenn Sie GKE Identity Service noch nicht für eine Flotte eingerichtet haben, folgen Sie der Anleitung unter Cluster für GKE Identity Service konfigurieren.

Cluster auswählen und Konfiguration aktualisieren

1. Rufen Sie in der Google Cloud Console die Seite Feature Manager auf.

   Zu Feature Manager

2. Klicken Sie im Bereich Identity Service auf Details. Die Clusterdetails Ihres Projekts werden angezeigt.

3. Klicken Sie auf Identitätsdienst aktualisieren, um den Einrichtungsbereich zu öffnen.

4. Wählen Sie die Cluster aus, die Sie konfigurieren möchten. Sie können einzelne Cluster auswählen oder festlegen, dass alle Cluster mit derselben Identitätskonfiguration konfiguriert werden sollen.

5. Im Abschnitt Identitätsanbieter konfigurieren können Sie einen Identitätsanbieter beibehalten, hinzufügen, aktualisieren oder entfernen.

6. Klicken Sie auf Weiter, um mit dem nächsten Konfigurationsschritt fortzufahren. Wenn Sie mindestens einen geeigneten Cluster für diese Einrichtung ausgewählt haben, wird der Bereich Google-Authentifizierung angezeigt.

7. Wählen Sie Aktivieren aus, um die Google-Authentifizierung für die ausgewählten Cluster zu aktivieren. Wenn Sie über einen Proxy auf den Google-Identitätsanbieter zugreifen müssen, geben Sie die Proxydetails ein.

8. Klicken Sie auf Konfiguration aktualisieren. Dadurch wird die Identitätskonfiguration auf die ausgewählten Cluster angewendet.

gcloud

Wenn Sie GKE Identity Service noch nicht für eine Flotte eingerichtet haben, folgen Sie der Anleitung unter Cluster für GKE Identity Service konfigurieren. Geben Sie in der Datei auth-config.yaml nur die folgende Konfiguration an:

spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

Zugriff von Drittanbietergruppen über einen Proxy konfigurieren

Wenn Sie über einen Proxy auf den Identitätsanbieter zugreifen müssen, verwenden Sie das Feld proxy in Ihrer auth-config.yaml-Datei. Diese Angabe ist möglicherweise erforderlich, wenn sich der Cluster beispielsweise in einem privaten Netzwerk befindet und eine Verbindung zu einem öffentlichen Identitätsanbieter hergestellt werden muss. Sie müssen diese Konfiguration auch hinzufügen, wenn Sie GKE Identity Service bereits für einen anderen Anbieter konfiguriert haben.

Zum Konfigurieren von proxy können Sie den Abschnitt authentication der vorhandenen Konfigurationsdatei auth-config.yaml aktualisieren.

  spec:
    authentication:
    - name: authentication-method
      google:
        disable: false
      proxy: PROXY_URL

Dabei gilt:

• disable (optional) gibt an, ob Sie die Drittanbietergruppen-Funktion für Cluster aktivieren oder deaktivieren möchten. Dieser Wert ist standardmäßig auf false festgelegt. Wenn Sie diese Funktion deaktivieren möchten, können Sie sie auf true setzen.

• PROXY_URL (optional): Proxyserver-Adresse für die Verbindung mit der Google-Identität. Beispiel: http://user:password@10.10.10.10:8888

Wenden Sie die Konfiguration an

Führen Sie folgenden Befehl aus, um die Konfiguration auf einen Cluster anzuwenden:

gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

Dabei gilt:

CLUSTER_NAME ist der eindeutige Mitgliedschaftsname Ihres Clusters innerhalb der Flotte.

Nach der Anwendung wird diese Konfiguration vom GKE Identity Service-Controller verwaltet. Alle lokalen Änderungen, die an der Clientkonfiguration von GKE Identity Service vorgenommen werden, werden vom Controller wieder auf die Konfiguration umgestellt, die in dieser Einrichtung festgelegt wurde.

Kubectl

Wenn Sie Ihren Cluster so konfigurieren möchten, dass er GKE Identity Service mit der Funktion für Drittanbietergruppen verwendet, müssen Sie den GKE Identity Service ClientConfig des Clusters aktualisieren. Dies ist ein benutzerdefinierter Kubernetes-Ressourcentyp (CRD), der für die Clusterkonfiguration verwendet wird. Jeder GKE Enterprise-Cluster hat eine ClientConfig-Ressource namens default im Namespace kube-public, die Sie mit Ihren Konfigurationsdetails aktualisieren.

Führen Sie den folgenden Befehl aus, um die Konfiguration zu bearbeiten:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Wenn die kubeconfig mehrere Kontexte enthält, wird der aktuelle Kontext verwendet. Möglicherweise müssen Sie den aktuellen Kontext auf den richtigen Cluster zurücksetzen, bevor Sie den Befehl ausführen.

Hier sehen Sie ein Beispiel dafür, wie Sie die ClientConfig mit einer neuen Authentifizierungsmethode mit einer Konfiguration vom Typ google aktualisieren, um die Funktion für Drittanbietergruppen zu aktivieren. Wenn das Feld internalServer leer ist, muss es auf https://kubernetes.default.svc gesetzt sein, wie unten gezeigt.

spec:
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL
  internalServer: https://kubernetes.default.svc

Dabei gilt:

CLUSTER_IDENTIFIER (erforderlich) gibt die Mitgliedschaftsdetails Ihres Clusters an. Sie können die Mitgliedschaftsdetails Ihres Clusters mit dem folgenden Befehl abrufen:

kubectl --kubeconfig CLUSTER_KUBECONFIG get memberships membership -o yaml

Dabei gilt:

Dabei ist CLUSTER_KUBECONFIG der Pfad der kubeconfig-Datei für den Cluster. Rufen Sie in der Antwort die Mitgliedschaftsdetails des Clusters im Feld spec.owner.id ab.

Hier sehen Sie eine Beispielantwort mit den Mitgliedschaftsdetails eines Clusters:

id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

Das entspricht dem folgenden Format: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP

IAM-Rollen für Drittanbieternutzer und -gruppen zuweisen

Identitäten von Drittanbietern benötigen die folgenden zusätzlichen Google Cloud-Rollen, um über das Gateway mit verbundenen Clustern zu interagieren:

• roles/gkehub.gatewayAdmin Mit dieser Rolle können Nutzer auf die Connect Gateway API zugreifen.
  • Wenn Nutzer nur Lesezugriff auf verbundene Cluster benötigen, kann stattdessen roles/gkehub.gatewayReader verwendet werden.
  • Wenn Nutzer Lese-/Schreibzugriff auf verbundenen Clustern benötigen, kann stattdessen roles/gkehub.gatewayEditor verwendet werden.
• roles/gkehub.viewer Mit dieser Rolle können Nutzer registrierte Clustermitgliedschaften aufrufen.

Im Folgenden wird gezeigt, wie Sie einzelnen Identitäten und zugeordneten Gruppen die erforderlichen Rollen hinzufügen:

Einzelne Identitäten

Führen Sie den folgenden Befehl aus, um einer einzelnen Identität für das Projekt PROJECT_ID die erforderlichen Rollen zuzuweisen:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

Dabei gilt:

• PROJECT_ID ist die ID des Projekts.
• GATEWAY_ROLE ist wahlweise roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader oder gkehub.gatewayEditor.
• WORKFORCE_POOL_ID ist die ID des Mitarbeiteridentitätspools.
• SUBJECT_VALUE: die Nutzeridentität

Gruppen

Führen Sie den folgenden Befehl aus, um allen Identitäten innerhalb einer bestimmten Gruppe für das Projekt PROJECT_ID die erforderlichen Rollen zuzuweisen:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

Dabei gilt:

• PROJECT_ID ist die ID des Projekts.
• GATEWAY_ROLE ist wahlweise roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader oder gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: die ID des Workforce-Pools.
• GROUP_ID: eine Gruppe im zugeordneten google.groups-Anspruch.

Weitere Anpassungen, z. B. die Angabe von Abteilungsattributen, beim Anwenden der RBAC-Richtlinien, finden Sie in der Einrichtung Ihres Identitätsanbieters unter Drittanbieterzuordnungen mit Workforce Identity einrichten.

Weitere Informationen zum Erteilen von IAM-Berechtigungen und -Rollen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Richtlinien für die rollenbasierte Zugriffssteuerung (RBAC) konfigurieren

Schließlich muss der Kubernetes API-Server jedes Clusters in der Lage sein, kubectl-Befehle zu autorisieren, die über das Gateway von Ihren angegebenen Nutzern und Gruppen von Drittanbietern eingehen. Für jeden Cluster müssen Sie eine RBAC-Berechtigungsrichtlinie hinzufügen, die angibt, welche Berechtigungen die Person für den Cluster hat.

Hinweis: Der Ressourcenpfad für einen Drittanbieternutzer enthält nicht den Namen des Identitätsanbieters. Achten Sie darauf, dass Sie nicht dieselben Nutzer- oder Gruppennamen bei verschiedenen Identitätsanbietern für den gleichen Personalpool verwenden, um unerwartete Berechtigungen zu vermeiden.

Die Subjekte in RBAC-Richtlinien müssen dasselbe Format wie die IAM-Bindungen haben, wobei Drittanbieternutzer mit principal://iam.googleapis.com/ und Drittanbietergruppen mit principalSet://iam.googleapis.com/ beginnen. Wenn GKE Identity Service nicht für den Cluster konfiguriert ist, benötigen Sie zusätzlich zu Rollen/Clusterrollen für einen Drittanbieternutzer Richtlinien zur Identitätsübertragung. Folgen Sie in diesem Fall dieser Anleitung zur RBAC-Einrichtung und fügen Sie das Hauptkonto des Drittanbieters, das mit principal://iam.googleapis.com/ beginnt, als Nutzer hinzu.

Im folgenden Beispiel wird gezeigt, wie Sie Mitgliedern einer Drittanbietergruppe cluster-admin-Berechtigungen für einen Cluster gewähren, in dem der GKE Identity Service konfiguriert ist. Sie können die Richtliniendatei dann unter /tmp/admin-permission.yaml speichern und auf den Cluster anwenden, der dem aktuellen Kontext zugeordnet ist.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

Weitere Informationen zum Angeben von RBAC-Berechtigungen finden Sie unter RBAC-Autorisierung verwenden.

Hinweise Während unsere Beispiele zeigen, wie Richtlinienaktualisierungen direkt mit kubectl durchgeführt werden, empfehlen wir für den praktischen Einsatz dringend die Verwendung von Policy Controller zum Erstellen und Verwalten von Richtlinien und Config Sync zum Synchronisieren dieser Richtlinien und anderer Konfigurationen in Ihren Clustern.

Nächste Schritte

• Verbindung über Cluster über die Befehlszeile herstellen
• Ein Beispiel für die Verwendung des Connect-Gateways als Teil Ihrer DevOps-Automatisierung finden Sie in unserer Anleitung In Cloud Build einbinden