Empfehlungen für die Infrastruktur als Code verwenden

Überblick

Mit Google Cloud Policy Intelligence können Unternehmen ihre Richtlinien nachvollziehen und verwalten und so Risiken reduzieren. Durch bessere Sichtbarkeit und Automatisierung erhöhen Kunden ihre Sicherheit ohne zusätzliche Arbeitslast.

Mit Recommender können Sie Empfehlungen für Google Cloud-Ressourcen abrufen und so die Sicherheit der Cloud verbessern, Kosten sparen und vieles mehr. Eine Liste der unterstützten Empfehlungen finden Sie in der Recommender-Dokumentation. In dieser Anleitung wird die Verwendung von Größenempfehlungen für VM-Instanzen und Empfehlungen zur Identitäts- und Zugriffsverwaltung (IAM) beschrieben. Recommender verwendet maschinelles Lernen, um Administratoren Empfehlungen zum Beenden unnötigen Zugriffs auf Google Cloud-Ressourcen und zum Anpassen der Größe von Compute Engine-Instanzen für eine effizientere Ressourcennutzung zu geben.

Jede Empfehlung enthält eine vorgeschlagene Aktion und deren Auswirkungen. Nachdem Sie die Empfehlungen für die ermittelten Auswirkungen sowie andere für Ihre Umgebung spezifische Aspekte gelesen haben, können Sie die Empfehlungen auswählen, die Sie anwenden möchten. Sie können Empfehlungen manuell über die Google Cloud Console anwenden oder sie programmatisch anwenden, indem Sie sie in Ihre Infrastruktur als Code-Pipeline integrieren.

Mit Infrastructure as Code (IaC) können Sie die Erstellung Ihrer Google Cloud-Ressourcen automatisieren. Sie müssen dafür Ihr IaC-Repository auf dem neuesten Stand halten und Änderungen der Google Cloud-Organisation dort vornehmen. IaC-Strategien in Organisationen sind im Allgemeinen nützlich, wenn sie umfassend implementiert sind und als einzige Version der Wahrheit für Ihre Cloud-Infrastruktur dienen. Es ist äußerst wichtig, Ihr IaC-Repository auf dem neuesten Stand zu halten, um Ablenkungen zwischen der Version Ihrer Infrastruktur, die Ihr IaC-Repository widerspiegelt, und dem, was Sie in der Organisation haben, zu vermeiden.

IAM-Empfehlungen

Bei einem der führenden Best Practices handelt es sich um ein gängiges Sicherheitsprinzip der geringsten Berechtigung und gründliche Überlegungen, wie Änderungen an Ihrer Organisation in Ihr IaC-Repository übernommen und synchronisiert werden.

Größenempfehlung für VMs

Mit Größenempfehlungen können Sie Ihre Kosten senken, indem Sie Vorschläge zur Größenanpassung der Maschinentypen Ihrer Instanzen erhalten, damit Sie Instanzressourcen effizienter nutzen können.

In dieser Anleitung wird beschrieben, wie Sie eine Automatisierungspipeline entwerfen und erstellen, um eine Policy Intelligence-Empfehlung programmatisch anzuwenden. Im Rahmen dieser Automatisierungspipeline erfahren Sie, wie Sie Ihr IaC-Repository (Infrastructure-as-Code) mit den Änderungen aktualisieren, die Sie basierend auf der VM-Größenanpassung und der Binding-Empfehlung der IAM-Richtlinie, die Recommender zur Verfügung stellt, an Ihrer Google Cloud-Organisation vornehmen.

In dieser Anleitung wird Hashicorp Terraform als IaC-Tool verwendet, wobei die in der beschriebenen Automatisierungspipeline verwendeten Architekturmuster und -komponenten auch dann verwendet werden können, wenn Sie ein anderes IaC-Verwaltungstool wie Deployment Manager verwenden. Sie müssen die mit dieser Anleitung verfügbare Open-Source-Codebasis an Ihre spezifische IaC-Implementierung anpassen.

Dieser Leitfaden richtet sich an Architekten, Produkteigentümer und Entwickler, die für die Verwaltung, Sicherheit und Infrastrukturplanung ihrer Google Cloud verantwortlich sind.

Architektur der Automatisierungspipeline

Das folgende Diagramm zeigt die Komponenten, die Sie in dieser Automatisierungspipeline verwenden.

Komponenten der Automatisierungspipeline

Ein geplanter Cloud Scheduler-Job führt den Recommender-Parser-Dienst aus. Der Dienst ruft die Recommender API auf, um Recommender-Empfehlungen für die von Ihnen angegebenen Projekte abzurufen. Anschließend parst diese VM-Größenanpassung- und IAM-Empfehlungen, um sie der Konfiguration in Ihren Terraform-Manifesten zuzuordnen. Der Dienst aktualisiert Ihre IaC-Manifeste entsprechend diesen Empfehlungen. Er generiert eine Pull-Anfrage mit den Änderungen, damit Sie die Aktualisierungen prüfen können. Nachdem Sie die Pull-Anfrage geprüft und zusammengeführt haben, führt ein Cloud Build-Job die Änderungen an Ihrer Infrastruktur in Ihrer Google Cloud-Organisation aus.

In der Pipeline werden mehrere zusätzliche Google Cloud-Dienste verwendet, um verarbeitete Empfehlungen zu verfolgen, Benachrichtigungen zum Abschluss des Builds zu generieren und den Terraform-Status zu speichern. Weitere Informationen zu diesen Diensten erhalten Sie im weiteren Verlauf dieser Anleitung.

In der folgenden Liste werden die Komponentenrollen und die Anforderungen der Zugriffssteuerung beschrieben:

Platform Intelligence Recommender
Rolle: Sicherheits- und VM-Größenempfehlungen generieren

Zugriffssteuerung: Das Google Cloud-Dienstkonto muss die erforderlichen IAM-Berechtigungen haben, um Empfehlungen mit der Recommender API abrufen zu können.

Sehen Sie sich die Recommender-Rollen und -Berechtigungen an, um die am besten geeignete Rolle für das Dienstkonto auszuwählen, mit dem Sie den Recommender-Parser ausführen.

Cloud Scheduler

Rolle: Cloud Scheduler führt den Recommender-Dienst aus. Mit Cloud Scheduler können Sie mehrere Jobs einrichten, die so viele Instanzen des Parser-Dienstes aufrufen, wie Sie benötigen. Jeder Aufruf muss die folgenden Eingaben übergeben.

  • Liste der Projekte, für die Empfehlungen verarbeitet werden sollen
  • Empfehlungstyp
  • Name des IaC-Repositorys

Zugriffssteuerung: Sie können Ihre Cloud Scheduler-Jobs mithilfe bestimmter Dienstkonten ausführen, die zum Aufrufen des Parser-Dienstes erstellt wurden.

Erstellen oder bestimmen Sie ein Google Cloud-Dienstkonto, das für Aufrufe von Cloud Scheduler an Ihren Recommender-Dienst verwendet werden soll.

Weisen Sie dem Dienstkonto die Rolle "Cloud Scheduler-Dienst-Agent" zu, damit es Cloud Scheduler-Jobs ausführen kann. Zusätzlich erteilen Sie dem Dienstkonto die Rolle "Cloud Run Invoker", da dieses Konto einen Cloud Run-Dienst aufruft.

Weitere Informationen finden Sie in der Dokumentation zum Konfigurieren des authentifizierten Zugriffs für Planerjobs.

Cloud Run-Dienst

Rolle: Der Recommender-Parser-Dienst ist der Ort, an dem sich die gesamte Verarbeitungslogik befindet. Sie hat mehrere Routen, die jeweils einen bestimmten Zweck erfüllen:

  • Parsing-Empfehlungen für jeden Empfehlungstyp.
  • Status der verarbeiteten Empfehlungen aktualisieren

Zugriffssteuerung: Verwenden Sie IAM, um den Zugriff auf diesen Dienst zu verwalten

Weisen Sie den Dienst außerdem einem dedizierten Dienstkonto zu. Dadurch wird sichergestellt, dass nur der Dienst andere Dienste wie Firestore aufrufen kann.

Hashicorp Terraform

Rolle: Terraform 0.12 ist die Infrastruktur als Code-Tool.

Ein Cloud Build-Builder für Terraform dient zum Aufrufen von Terraform-Befehlen. Dazu wird das Cloud Build-Dienstkonto verwendet.

Cloud Build

Rolle: Google Cloud Build automatisiert die Bereitstellung der Infrastruktur basierend auf den Änderungen, die an den IaC-Manifesten pro Richtlinien Intelligence-Empfehlungen vorgenommen wurden.

Zugriffssteuerung: Das Cloud Build-Dienstkonto muss die erforderlichen Berechtigungen für die Interaktion mit Ressourcen in Ihrem Testprojekt haben.

Weitere Informationen finden Sie in der Dokumentation zum Konfigurieren eines Cloud Build-Dienstkontos.

GitHub

Rolle: Das IaC-Repository verwendet GitHub zur Versionsverwaltung. Das IaC-Repository in GitHub ist in Cloud Build eingebunden. Wenn Commits an den Master-Branch gesendet werden, wird ein Cloud Build-Job ausgelöst, um eine Reihe vorkonfigurierter Aufgaben auszuführen.

Zugriffssteuerung: Sie müssen SSH-Schlüssel generieren, um den Zugriff auf Ihr IaC-Repository zu ermöglichen.

Außerdem müssen Sie ein persönliches Zugriffstoken generieren, um Commits an GitHub zu senden.

Firestore

Firestore ist eine vollständig verwaltete, skalierbare NoSQL-Dokumentdatenbank, die in dieser Architektur zum Speichern von Informationen zu den Empfehlungs-IDs verwendet wird, die vom Recommender-Dienst zusammen mit den entsprechenden Details für Git-Commits geparst werden.

Die in Firestore gespeicherten Details spielen eine wichtige Rolle in der Feedbackschleife, die Teil der End-to-End-Pipeline ist. Nachdem Sie eine von der Recommender API generierte Empfehlung erhalten und bevor die Empfehlung verarbeitet wurde, markiert der Dienst den Status der Empfehlung als CLAIMED. Nachdem die Empfehlung erfolgreich angewendet wurde, fragt der Dienst die Datenbank ab, um die Empfehlungs-IDs abzurufen, die vom Cloud Build-Job erfolgreich angewendet und der Empfehlungsstatus in SUCCEEDED geändert wurde. Wenn der Cloud Build-Job fehlschlägt, wird der Empfehlungsstatus in FAILED geändert.

Zugriffssteuerung: Weitere Informationen finden Sie unter Firestore-Rollen. Der Recommender-Parser-Dienst liest Daten aus Firestore und benötigt dazu die Rolle "datastore/datastore.user".

Pub/Sub

Rolle: Wenn sich der Build-Status ändert, veröffentlicht Cloud Build Nachrichten zu einem Pub/Sub-Thema. Dies ist beispielsweise bei der Erstellung Ihres Builds der Fall, wenn der Build in einen funktionsfähigen Zustand umgewandelt wird und wenn der Build abgeschlossen ist.

Das Pub/Sub-Thema, an das Cloud Build Nachrichten veröffentlicht, wird "cloud-builds" genannt. Es wird automatisch für Sie erstellt, wenn Sie die Cloud Build API in Ihrem Projekt aktivieren.

Zugriffssteuerung: Push-Abos können so konfiguriert werden, dass sie einen Authentifizierungsheader enthalten, über den sie die Anfrage autorisieren können. Weitere Informationen finden Sie unter Push-Abos verwenden.

Ziele

  • Automatisierungspipeline erstellen, um
    • Empfehlungen für Platform Policy Intelligence proaktiv zu beobachten
    • Empfehlungen zu parsen und Aktualisierungen auf ein vorhandenes IaC-Repository anzuwenden
  • Erfahren Sie mehr darüber, wie Sie diese Pipeline mit einer Suite von Google Cloud-Diensten, Hashicorp Terraform und GitHub erstellen.
  • Machen Sie sich mit den Annahmen und Best Practices vertraut, die Sie beim Erstellen dieser Pipeline berücksichtigen müssen
  • Pipeline testen

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloud verwendet, darunter:

  • Cloud Run
  • Cloud Build
  • Compute Engine
  • Cloud Storage
  • Firestore
  • Pub/Sub
  • Cloud Scheduler
  • Recommender

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweis

In dieser Anleitung wird davon ausgegangen, dass Sie ein GitHub-Konto haben und mit Git, Node.js, Terraform und Docker vertraut sind.

Versionshinweise und Annahmen

Die IaC-Tools und -Manifeste sind sehr unterschiedlich.

In den folgenden Abschnitten erfahren Sie, wie sich diese Anleitung an Ihre IaC-Pipeline anpassen lässt und welche Änderungen erforderlich sind.

  • Diese Pipeline verwendet Terraform ver. 0.12. Erhebliche Änderungen an der Konfiguration der HCL-Konfiguration oder Änderungen an der Struktur der Terraform-Statusdatei können zu Problemen führen.
  • Diese Pipeline geht davon aus, dass die IaC-Verzeichnisstrukturen nicht verschachtelt sind und dass ein IaC-Repository Ressourcen in einem oder mehreren Google Cloud-Projekten verwaltet.
  • Als Umgebungsvariablen übergebene Terraform-Variablen werden nicht unterstützt. Der Prototyp geht von einer deklarativen Konfiguration von Terraform-Variablen in einer tfvars-Datei aus.
  • Recommender generiert IAM-Empfehlungen, wenn eine Teilmenge von Berechtigungen für eine Rolle 60 Tage lang nicht verwendet wurde und VM-Größenempfehlungen einem ähnlichen Muster folgen. Für die Zwecke dieser Anleitung wurden Beispiele für Empfehlungsnutzlasten bereitgestellt, die zum Testen der Pipeline verwendet werden können.
  • Schleifen innerhalb von Terraform werden in dieser Version nicht unterstützt.
  • Terraform-Module werden nicht unterstützt. Bei der Codebasis handelt es sich um eine Open Source-Anwendung. Es wird davon ausgegangen, dass Sie alle erforderlichen Verbesserungen am Vergleichsablauf vornehmen, um an Ihre Verzeichnisstruktur und Nutzung von Modulen anzupassen.

Die aktuelle Version des Open-Source-Parser-Dienstes für Empfehlungen ist auf die folgenden bekannten Einschränkungen von IAM-Empfehlungen ausgerichtet:

Vorbereitung

  1. Wählen Sie zwei Google Cloud-Projekte aus oder erstellen Sie eines.

    Zur Projektauswahl

    • Ein Build-Projekt, das die Automatisierungspipeline hostet und ausführt.
    • Ein Test-Projekt, das Google Cloud-Ressourcen hostet, die zum Testen der Automatisierungspipeline verwendet werden
  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.

  3. Aktivieren Sie im Test-Projekt die Compute Engine API.

    Aktivieren Sie die APIs

  4. Aktivieren Sie im Build-Projekt die Cloud Run-, Firestore-, Pub/Sub and Cloud Scheduler-, IAM- und CloudResourceManager-APIs.

    Aktivieren Sie die APIs

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie im Abschnitt Bereinigen.

Umgebung einrichten

  1. Wählen Sie in der Cloud Console Ihr build-Projekt aus.
  2. Rufen Sie Cloud Shell in der Cloud Console auf.

    Zu Cloud Shell

    Unten in der Cloud Console wird eine Cloud Shell-Sitzung mit einer Eingabeaufforderung geöffnet. Cloud Shell ist eine Shell-Umgebung, in der das Cloud SDK einschließlich des gcloud-Befehlszeilentools vorinstalliert ist. Die Werte sind bereits für Ihr aktuelles Projekt festgelegt. Das Initialisieren der Sitzung kann einige Sekunden dauern.

    Verwenden Sie Cloud Shell für alle Terminalbefehle in dieser Anleitung.

  3. Erstellen Sie mit folgendem Befehl eine Umgebungsvariable, die die Projektnummer für Ihr build-Projekt enthält:

    export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
    
  4. Erstellen Sie eine Umgebungsvariable für die Projektnummer Ihres test-Projekts . Kopieren Sie die Testprojekt-ID manuell und ersetzen Sie PROJECT-ID durch sie.

    export TEST_PROJECT_ID=PROJECT-ID
    
  5. Sie weisen Standardeinstellungen für Werte zu, die in der gesamten Anleitung verwendet werden, z. B. Region und Zone. In dieser Anleitung wird us-central1 als Standardregion und us-central1-b als Standardzone verwendet.

  6. Legen Sie mit dem folgenden Befehl die Standardregion und -zone für diese Anleitung fest:

    gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
    gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
    
  7. Legen Sie Ihr build-Projekt als Standardprojekt fest:

    gcloud config set project $BUILD_PROJECT_ID
    
  8. Erstellen Sie eine Umgebungsvariable namens BUILD_PROJECT_NUMBER für Ihrebuild-Projektnummer

    export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
    
  9. Klonen Sie das GitHub-Repository für diese Anleitung:

Bucket für Terraform-Status erstellen

Erstellen Sie einen Cloud Storage-Bucket in Ihrem Build-Projekt, um die Terraform-Statusdatei zu speichern.

gsutil mb -p ${BUILD_PROJECT_ID} -l us-central1 \
 gs://recommender-tf-state-$BUILD_PROJECT_ID

GitHub-Repository erstellen

GitHub-Repository als Beispiel-IaC-Repository erstellen

  1. Erstellen Sie ein neues privates GitHub-Repository. Dieses IAC-REPO-NAME-Repository dient in dieser Anleitung als IaC-Repository

  2. In den folgenden Setups übertragen Sie die Dateien im Unterverzeichnis sample-iac des geklonten Repositorys an Ihr GitHub-Konto.

    1. Kopieren Sie in Cloud Shell das sample-iac-Verzeichnis in Ihr Basisverzeichnis. Sie verwenden dieses Verzeichnis, um ein neues lokales Repository zu erstellen und es an GitHub zu übertragen.

      cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
      
    2. Gehen Sie zum neuen Verzeichnis

      cd $HOME/sample-iac
      
    3. Initialisieren Sie das Repository auf Ihrem lokalen Computer.

      git init
      
    4. Fügen Sie IAC-REPO-NAME als Remote-Repository hinzu. Ersetzen Sie dabei IAC-REPO-NAME und GITHUB-ACCOUNT durch die entsprechenden Werte:

      git remote add origin
      https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME
      
    5. Ersetzen Sie die Platzhalter in den Dateien in diesem Repository durch Ihre Projekt-ID test und den Namen des Terraform Cloud Storage-Buckets.

      sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars
      
      sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
      
    6. Fügen Sie GitHub hinzu, führen Sie einen Commit durch und laden Sie es in GitHub hoch.

      git add .
      git commit -m "First Commit"
      git push origin master
      
    7. Melden Sie sich bei Aufforderung in Ihrem GitHub-Konto an.

SSH-Schlüssel für Ihr Repository generieren

Richten Sie die SSH-Schlüsselauthentifizierung mit Ihrem IaC-Repository in GitHub ein und laden Sie die Schlüssel in Cloud Storage hoch.

  1. Generieren Sie SSH-Schlüssel für Ihr GitHub-Repository.

    1. Generieren Sie ein SSH-Schlüsselpaar. Ersetzen Sie *your_email@example.com* durch Ihre GitHub-E-Mail-Adresse. In Cloud Shell:

      ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
      
    2. Wenn Sie die Aufforderung "Geben Sie eine Datei an, in der der Schlüssel gespeichert werden soll" angezeigt werden, drücken Sie die Eingabetaste. Dies akzeptiert den Standardspeicherort der Datei.

    3. Drücken Sie die , um eine Passphrase einzugeben.

  2. Notieren Sie sich das SSH-KEYS-DIR-Verzeichnis, in dem Sie die heruntergeladenen SSH-Schlüssel speichern. Standardmäßig ist der Standort $HOME/.ssh/.

  3. Kopieren Sie den öffentlichen SSH-Schlüssel, den Sie generiert haben, als Deploy Key in Ihr GitHub-Repository.

    1. Kopieren Sie den öffentlichen SSH-Schlüssel, den Sie in Cloud Shell generiert haben. Ersetzen Sie SSH-KEYS-DIR durch Ihren Verzeichnispfad.

      cat SSH-KEYS-DIR/id_rsa.pub
      
    2. Rufen Sie in Ihrem GitHub-Konto das IAC-REPO-NAME-Repository auf.

    3. Klicken Sie auf Settings > Deploy Keys.

    4. Klicken Sie auf Add Deploy Key und fügen Sie den öffentlichen SSH-Schlüssel ein, den Sie kopiert haben. Wählen Sie einen Namen für den Schlüssel aus.

    5. Klicken Sie auf das Kästchen Schreibzugriff zulassen.

    6. Klicken Sie auf Speichern.

  4. Kehren Sie zur Cloud Shell-Sitzung zurück.

  5. Erstellen Sie die Datei known_hosts für GitHub. Führen Sie in der Cloud Shell-Sitzung den folgenden Befehl aus:

    ssh-keyscan github.com >> ~/.ssh/known_hosts
    
  6. Erstellen Sie einen Cloud Storage-Bucket in Ihrem build-Projekt und laden Sie Ihre SSH-Schlüssel und Ihre known_hosts-Datei hoch. Ersetzen Sie SSH-KEYS-DIR durch den Pfad zu dem Verzeichnis, in dem Sie die SSH-Schlüssel generiert haben.

    gsutil mb -p ${BUILD_PROJECT_ID} -l us-central1 gs://github-keys-$BUILD_PROJECT_ID
    
    gsutil cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
    gsutil cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID
    
  7. Generieren Sie ein persönliches Zugriffstoken für GitHub. Dieses Token wird verwendet, wenn Git-Vorgänge mit API-Aufrufen ausgeführt werden, die der Recommender-Parser-Dienst zum Generieren von Pull-Anfragen ausführt.

    1. Klicken Sie in Ihrem GitHub-Konto rechts oben auf einer beliebigen Seite auf Ihr Profilbild und dann auf Einstellungen.

    2. Klicken Sie in der linken Seitenleiste auf Entwicklereinstellungen.

    3. Klicken Sie auf der linken Seitenleiste auf Persönliche Zugriffstokens.

    4. Klicken Sie auf "Neues Token erstellen".

    5. Geben Sie Ihrem Token einen aussagekräftigen Namen.

    6. Wählen Sie die Bereiche als Repository aus.

    7. Klicken Sie auf Token generieren.

    8. Kopieren Sie das Token in die Zwischenablage.

    9. Erstellen Sie in Ihrer Cloud Shell-Sitzung eine Umgebungsvariable.

      export GITHUB_PAT=<personal-access-token-you-copied>
      

Cloud Build einrichten

  1. Stellen Sie eine Verbindung Ihres Git-Repositories IAC-REPO-NAME zur Integration in Cloud Build her.

    1. Rufen Sie im GitHub Marketplace die Seite Cloud Build App auf.
    2. Scrollen Sie zum Ende der Seite und klicken Sie auf Mit Google Cloud Build einrichten.
    3. Wenn Sie dazu aufgefordert werden, melden Sie sich bei GitHub an.
    4. Wählen Sie Nur Repositories auswählen aus. Verwenden Sie die Drop-down-Liste Repositories auswählen, um nur den Zugriff auf Ihre IAC-REPO-NAME in der Cloud Build-App zu aktivieren.
    5. Klicken Sie auf Installieren.
    6. Melden Sie sich in Google Cloud an.

      Auf der Autorisierungsseite werden Sie aufgefordert, die Google Cloud-Build-App für die Verbindung mit Google Cloud zu autorisieren.

    7. Klicken Sie auf Google Cloud Build durch GoogleCloudBuild autorisieren. Sie werden zur Cloud Console weitergeleitet.

    8. Wählen Sie Ihr Google Cloud-Projekt aus.

    9. Klicken Sie auf das Kästchen für die Zustimmung und dann auf Weiter.

    10. Wählen Sie auf der Seite Repository auswählen das GitHub-Repository IAC-REPO-NAME aus.

    11. Klicken Sie auf Repository verbinden.

    Weitere Informationen finden Sie unter Builds auf GitHub ausführen.

  2. Klicken Sie auf Push-Trigger erstellen. Dadurch wird ein Trigger für Sie erstellt.

  3. Das kopierte Verzeichnis enthält eine cloudbuild.yaml-Datei. In dieser Konfigurationsdatei werden die Schritte beschrieben, die ein Cloud Build-Job beim Auslösen ausführt.

    steps:
    - name: hashicorp/terraform:0.12.0
      args: ['init']
    - name: hashicorp/terraform:0.12.0
      args: ['apply', '-auto-approve']
    
  4. Fügen Sie Ihrem Cloud Build-Dienstkonto Berechtigungen hinzu, damit es Dienstkonten erstellen, Rollen und virtuelle Maschinen (Compute Engine-Instanzen) im Testprojekt erstellen kann

    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
      --role roles/compute.admin \
      --project $TEST_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
      --role roles/iam.serviceAccountAdmin \
      --project $TEST_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
    --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role roles/iam.securityAdmin \
    --project $TEST_PROJECT_ID
    
  5. Rufen Sie die Seite "Build-Trigger" in der Cloud Console auf.

  6. Wählen Sie build-Projekt aus und klicken Sie auf Öffnen.

  7. Aktualisieren Sie die Definition des Triggers:

    1. Klicken Sie rechts neben Trigger ausführen auf Bearbeiten.
    2. Geben Sie im Textfeld Branch (regulärer Ausdruck) master ein.
    3. Wählen Sie für Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus und geben Sie cloudbuild.yaml in das Textfeld ein.
    4. Klicken Sie auf Speichern.
  8. Klicken Sie in der Triggerliste neben dem Triggereintrag auf Trigger ausführen, um den Build-Trigger manuell zu testen.

  9. Prüfen Sie, ob eine Compute Engine-Instanz mit dem Namen tf-compute-1 und ein Dienstkonto mit dem Namen Terraform Recommender Test im Testprojekt von Cloud Build erstellt wurden, das Sie im vorherigen Schritt ausgeführt haben.

Recommender-Parser für Cloud Run-Dienst bereitstellen

  1. Wechseln Sie in Cloud Shell zum Verzeichnis, das durch Klonen des Repositorys erstellt wurde

    cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
    
  2. Konfigurieren Sie Google Cloud so, dass es eine Standardregion für Cloud Run-Dienste verwendet. In dieser Anleitung verwenden Sie die Region us-central1. Sie können jedoch auch eine andere unterstützte Region auswählen.

    gcloud config set run/region us-central1
    
  3. Das Verzeichnis parser-service hat ein Stub-Unterverzeichnis mit einigen JSON-Beispielnutzdaten, damit Sie den Recommender-Parser-Dienst testen können. Führen Sie die folgenden sed-Befehle aus, um die PROJECT_ID-Platzhalter in diesen JSON-Dateien durch Ihre Testprojekt-ID zu ersetzen.

    sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
    sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
    
  4. Führen Sie den folgenden Befehl aus, um eine Umgebungsvariable für das Docker-Image zu erstellen.

    export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
    
  5. Erstellen Sie das Image und laden Sie es in Container Registry hoch

    gcloud builds submit --tag $IMAGE .
    
  6. Erstellen Sie ein Dienstkonto für den Recommender-Parser-Dienst, um mit anderen Google Cloud-Diensten in der Pipeline zu interagieren. Es empfiehlt sich, detaillierte Berechtigungen für Cloud Run-Dienste zu gewähren. Weitere Informationen finden Sie unter Cloud Run-Dienstidentität.

    gcloud beta iam service-accounts create recommender-parser-sa \
      --description "Service account that the recommender-parser service uses to invoke other GCP services" \
      --display-name "recommender-parser-sa" \
      --project $BUILD_PROJECT_ID
    
  7. Der Recommender-Parser-Dienst muss auf die GitHub-SSH-Schlüssel und den Terraform-Status zugreifen, den Sie zuvor in Cloud Storage-Buckets hochgeladen haben. Fügen Sie dem Cloud Storage-Bucket das Dienstkonto als Mitglied hinzu.

    gsutil iam ch serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com:objectCreator,objectViewer \
    gs://github-keys-$BUILD_PROJECT_ID
    
    gsutil iam ch serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com:objectCreator,objectViewer \
    gs://recommender-tf-state-$BUILD_PROJECT_ID
    
  8. Gewähren Sie dem Dienstkonto des Recommender-Parsers Zugriff auf Firestore und die Recommender API.

    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/datastore.user
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/recommender.iamAdmin
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/recommender.iamViewer
    
    gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
      --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/recommender.computeAdmin
    
  9. Stellen Sie den Cloud Run-Dienst mit dem Namen recommender-parser mit dem Befehl bereit. Nehmen Sie alle Systemaufforderungen an.

    gcloud beta run deploy \
     --image=${IMAGE} \
     --no-allow-unauthenticated \
     --region us-central1 \
     --platform managed \
     --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
     --project $BUILD_PROJECT_ID \
     recommender-parser
    

Firestore einrichten

  1. Rufen Sie in der Google Cloud Console in Ihrem build-Projekt die Firestore-Seite auf.
  2. Wenn Sie zur Auswahl des Modus aufgefordert werden, klicken Sie auf Nativen Modus auswählen.
  3. Wählen Sie us-east1 als Standardstandort aus.
  4. Klicken Sie auf Datenbank erstellen.
  5. Klicken Sie auf Start Collection (Sammlung starten).
  6. Geben Sie bei Sammlungs-ID die Option applied-recommendations ein.
  7. Klicken Sie auf Speichern.

Der recommender-parser-Dienst schreibt Dokumente zu folgenden Zwecken in diese Sammlung:

  • Um die von der Recommender API abgerufenen Empfehlungen zu verfolgen
  • Rufen Sie die Recommender API auf, sobald die Empfehlungen verarbeitet wurden, um den Status jeder verarbeiteten Empfehlung auf SUCCEEDED oder FAILED zu aktualisieren. Dies ist ein wichtiger Schritt, der die Pipeline idempotent macht, indem sichergestellt wird, dass Empfehlungen nicht unvollständig oder mehrmals verarbeitet werden.

Cloud Scheduler-Job einrichten

  1. Erstellen Sie ein Dienstkonto, mit dem Cloud Scheduler-Jobs den Recommender-Parser-Dienst ausführen.

    gcloud beta iam service-accounts create recommender-scheduler-sa \
      --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
      --display-name "recommender-scheduler-sa" \
      --project $BUILD_PROJECT_ID
    
  2. Weisen Sie dem Dienstkonto die Rolle "run/invoker" zu, um den Cloud Run-Dienst aufrufen zu können.

    gcloud beta run services add-iam-policy-binding recommender-parser \
    --member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/run.invoker \
    --region=us-central1
    
  3. Rufen Sie die URL des Recommender-Dienstes ab:

    gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
    

    Der Cloud Scheduler-Job ruft die /recommendation/iam-Route des Recommender-Parsers auf, um IAM-Empfehlungen zu parsen, und die /recommender/vm-Route, um die Größenempfehlungen für VM zu parsen.

  4. Erstellen Sie eine Variable für den Endpunkt, den Cloud Scheduler-Jobs aufrufen. Ersetzen Sie RECOMMENDER-SERVICE-URL durch die Recommender-URL, die Sie im vorherigen Schritt kopiert haben.

    export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam
    

    Die URL sollte nach dem Anhängen der Routeninformationen so aussehen:

    https://RECOMMENDER-SERVICE-URL/recommendation/iam
    
  5. Erstellen Sie einen Cloud Scheduler-Job mit dem Namen recommender-iam-scheduler.

    • Ändern Sie die ausgewählte Zeitzone basierend auf Ihrem Standort.
    • Ersetzen Sie <you-iac-repo> durch den Namen des von Ihnen erstellten GitHub-Repositorys.

    Der Nachrichtentext erfordert drei Eingaben und muss so aufgebaut werden:

  6. repo: Dies ist der Name Ihres GitHub-Repositorys IAC-REPO-NAME, den Sie unter GitHub-Repository erstellen erstellt haben.

  7. projects: Eine Liste/ein Array der Google Cloud-Projekt-IDs, denen dieses IaC GitHub-Repository zugeordnet ist. In dieser Anleitung ist es Ihr test-Projekt.

  8. stub: Recommender generiert IAM-Empfehlungen, wenn eine Teilmenge der Berechtigungen für eine Rolle 60 Tage lang nicht verwendet wurde und VM-Größenempfehlungen einem ähnlichen Muster folgen. Zum Testen dieser Pipeline on demand kann stub als true übergeben werden, sodass die Pipeline mit den Beispiel-Nutzlasten in dem Repository getestet wird, die Sie geklont haben.

    gcloud beta scheduler jobs create http recommender-iam-scheduler \
      --project $BUILD_PROJECT_ID \
      --time-zone "America/Los_Angeles" \
      --schedule="0 */3 * * *" \
      --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
      --description="Scheduler job to invoke recommendation pipeline" \
    --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
      --headers="Content-Type=application/json" \
      --http-method="POST" \
      --message-body="{ \"repo\": \"<var>IAC-REPO-NAME</var>\", \"projects\": [\"$TEST_PROJECT_ID\"], \"stub\": true }"
    

Weitere Schritte:

Cloud Build veröffentlicht Build-Informationen in einem Pub/Sub-Thema namens "cloud-builds", das automatisch erstellt wurde, als Sie die Cloud Build API in Ihrem Build-Projekt aktiviert haben.

  1. Erstellen Sie ein Dienstkonto, mit dem Pub/Sub den Dienstendpunkt für den Recommender-Parser aufruft.

    gcloud beta iam service-accounts create recommender-ci-subscription-sa \
      --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
      --display-name "recommender-ci-subscription-sa"
      --project $BUILD_PROJECT_ID
    
  2. Das Pub/Sub-Dienstkonto sollte mit den Rollen verknüpft sein, die zum Veröffentlichen von Nachrichten und zum Aufrufen des Recommender-Parser-Dienstes erforderlich sind.

    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/pubsub.publisher \
      --project $BUILD_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/pubsub.subscriber \
      --project $BUILD_PROJECT_ID
    
    gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
      --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
      --role roles/run.invoker \
      --project $BUILD_PROJECT_ID
    
  3. Fügen Sie das von Ihnen erstellte recommender-ci-subscription-sa-Dienstkonto dem Recommender-Parser-Dienst als Mitglied mit der Rolle invoker hinzu.

    gcloud beta run services add-iam-policy-binding recommender-parser \
    --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/run.invoker --region=us-central1
    
  4. Rufen Sie in der Google Cloud Console Pub/Sub auf.

  5. Klicken Sie auf das Thema "cloud-builds".

  6. Klicken Sie auf Abo erstellen.

  7. Geben Sie als Abo-ID recommender-service-build-events ein.

  8. Wählen Sie als Zustellungstyp Push aus.

  9. Klicken Sie das Kästchen Authentifizierung aktivieren an.

    1. Wählen Sie das Dienstkonto recommender-ci-subscription-sa aus, das Sie erstellt haben.
    2. Klicken Sie als Antwort auf die Eingabeaufforderung auf Erteilen.
  10. Für Endpunkt geben Sie die URL Ihres Recommender-Dienstes mit der Endung /ci ein.

  11. Wählen Sie Bestätigungsfrist als 60 Sekunden aus.

  12. Behalten Sie die restlichen Standardeinstellungen bei.

  13. Klicken Sie auf Erstellen.

Pipeline testen

Recommender generiert IAM-Empfehlungen, wenn eine Teilmenge von Berechtigungen für eine Rolle 60 Tage lang nicht verwendet wurde. Die Empfehlungen zur VM-Größe folgen einem ähnlichen Muster. Zum on demand-Testen dieser Pipeline verwenden Sie die JSON-Nutzlasten der Beispielempfehlungen, die im Unterverzeichnis stub des Repositorys enthalten sind, das Sie für diese Anleitung geklont haben. So können Sie die Pipeline testen und die API-Aufrufe, die der Recommender-Parser an den Recommender API-Endpunkt sendet, aktualisieren, um den Status der empfohlenen Empfehlungen zu aktualisieren.

Wenn Sie in Ihren Google Cloud-Projekten aktive Empfehlungen haben, können Sie die Pipeline End-to-End-Funktion testen, ohne Stubs zu verwenden. Das unten aufgeführte Ergebnis gilt für die Verwendung der Beispielnutzlasten zum Testen der Pipeline. Die Schritte zum Testen dieser Pipeline ohne Beispiele bleiben jedoch unverändert.

  1. Gehen Sie in der Cloud Console zu Ihrem Testprojekt und prüfen Sie die erstellte Ressource. Sie sollten Folgendes haben:

    1. Eine Compute Engine-Instanz namens tf-compute-1 mit dem Maschinentyp g1-small.
    2. Ein Dienstkonto mit dem Namen Terraform Recommender Test und der Rolle editor für Ihr Testprojekt.
  2. Klicken Sie auf der Seite Cloud Scheduler in der Konsole im Projekt build auf Jetzt ausführen für den Job recommender-iam-scheduler.

  3. Klicken Sie auf den Job, um die Logs anzuzeigen. Sie können auch die Recommender-Dienstlogs ansehen, um eine detaillierte Ansicht der vom Dienst ausgeführten Schritte zu erhalten.

  4. Rufen Sie nach Abschluss der Ausführung des Dienstes Ihr GitHub-Repository IAC-REPO-NAME auf. Der recommender-parser-Dienst sollte eine Pull-Anfrage für Sie generiert haben. Prüfen Sie die geänderten IaC-Manifeste, die diese Pull-Anfrage enthalten, und klicken Sie auf Pull-Anfrage zusammenführen, wenn Sie mit den Änderungen an Ihren IaC-Manifesten zufrieden sind.

  5. Wenn Sie die Pull-Anfrage zusammenführen, wird ein neuer Commit für den Master-Branch erstellt. Dadurch wird ein Cloud Build-Job ausgelöst, der die Änderungen an den Google Cloud-Ressourcen in Ihrem test-Projekt ausführt. Warten Sie kurz, bis der Cloud Build-Job abgeschlossen ist. Sie können den Status in der Cloud Console prüfen.

  6. Gehen Sie nach Abschluss des Jobs zu Ihrem Testprojekt. Mit den angegebenen Beispielnutzlasten werden die folgenden Änderungen an den Ressourcen in Ihrem Testprojekt vorgenommen.

    • Das Terraform-Dienstkonto, das zuvor die Rolle editor hat, wird bei der Bereitstellung in viewer geändert.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie beide Projekte, die Sie erstellt haben.

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

  1. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite "Ressourcen verwalten"

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen .
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Nächste Schritte

  • Probieren Sie andere Google Cloud-Funktionen selbst aus. Anleitungen
  • Weitere Informationen zu Google Cloud Policy Intelligence finden Sie in der Dokumentation.