Sichere Bereitstellung in Cloud Run

1. Übersicht

Sie ändern die Standardschritte für die Bereitstellung eines Dienstes in Cloud Run, um die Sicherheit zu verbessern, und sehen sich dann an, wie Sie sicher auf die bereitgestellte App zugreifen. Die App ist ein „Partnerregistrierungsdienst“ der Cymbal Eats-App, der von Unternehmen verwendet wird, die mit Cymbal Eats zusammenarbeiten, um Essensbestellungen zu verarbeiten.

Lerninhalte

Mit einigen kleinen Änderungen an den minimalen Standardschritten für die Bereitstellung einer App in Cloud Run können Sie die Sicherheit deutlich erhöhen. Sie nehmen eine vorhandene App und Bereitstellungsanleitung und ändern die Bereitstellungsschritte, um die Sicherheit der bereitgestellten App zu verbessern.

Anschließend erfahren Sie, wie Sie den Zugriff auf die App autorisieren und autorisierte Anfragen stellen.

Dies ist keine umfassende Betrachtung der Sicherheit bei der Anwendungsbereitstellung, sondern ein Blick auf Änderungen, die Sie an allen zukünftigen App-Bereitstellungen vornehmen können, um die Sicherheit mit sehr geringem Aufwand zu verbessern.

2. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten Lernen einrichten

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

• Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können ihn jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (sie wird in der Regel als PROJECT_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie es mit einem eigenen versuchen und sehen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten

Achtung:Eine Projekt-ID ist global eindeutig und kann nach der Auswahl nicht mehr von anderen verwendet werden. Sie sind der einzige Nutzer dieser ID. Auch wenn ein Projekt gelöscht wird, kann die ID nie wieder verwendet werden.

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie den Standardspeicherort auf Keine Organisation belassen. Wenn Sie ein Google Workspace-Konto verwenden, wählen Sie einen Standort aus, der für Ihre Organisation sinnvoll ist.

2. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs sollte keine oder nur geringe Kosten verursachen. Wenn Sie Ressourcen herunterfahren möchten, damit Ihnen nach Abschluss dieser Anleitung keine Kosten mehr in Rechnung gestellt werden, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neue Nutzer von Google Cloud kommen für das Programm für kostenlose Testversionen mit einem Guthaben von 300$ infrage.

Cloud Shell aktivieren

1. Klicken Sie in der Cloud Console auf Cloud Shell aktivieren .

Wenn Sie die Cloud Shell zuvor noch nicht gestartet haben, wird ein Fenster mit einer Beschreibung eingeblendet. Klicken Sie in diesem Fall einfach auf Weiter. So sieht dieses Fenster aus:

Das Herstellen der Verbindung mit der Cloud Shell sollte nur wenige Augenblicke dauern.

Auf dieser virtuellen Maschine sind alle Entwicklungstools installiert, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Die meisten, wenn nicht sogar alle Aufgaben in diesem Codelab können mit einem Browser oder Ihrem Chromebook erledigt werden.

Sobald die Verbindung mit der Cloud Shell hergestellt ist, sehen Sie, dass Sie bereits authentifiziert sind und für das Projekt schon Ihre Projekt-ID eingestellt ist.

2. Führen Sie in der Cloud Shell den folgenden Befehl aus, um zu prüfen, ob Sie authentifiziert sind:

gcloud auth list

Befehlsausgabe

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

Hinweis:Das gcloud-Befehlszeilentool ist ein leistungsstarkes und vereinheitlichtes Befehlszeilentool in Google Cloud. Das Tool ist in der Cloud Shell vorinstalliert. Sie werden feststellen, dass die Tab-Vervollständigung unterstützt wird. Weitere Informationen finden Sie in der Übersicht über das gcloud-Befehlszeilentool.

3. Führen Sie den folgenden Befehl in Cloud Shell aus, um zu bestätigen, dass der gcloud-Befehl Ihr Projekt kennt:

gcloud config list project

Befehlsausgabe

[core]
project = <PROJECT_ID>

Ist dies nicht der Fall, können Sie die Einstellung mit diesem Befehl vornehmen:

gcloud config set project <PROJECT_ID>

Befehlsausgabe

Updated property [core/project].

Umgebung einrichten

In diesem Lab führen Sie Befehle in der Cloud Shell-Befehlszeile aus. In der Regel können Sie die Befehle kopieren und unverändert einfügen. In einigen Fällen müssen Sie jedoch Platzhalterwerte durch die richtigen Werte ersetzen.

1. Legen Sie eine Umgebungsvariable für die Projekt-ID fest, die in späteren Befehlen verwendet werden soll:

export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export SERVICE_NAME=partner-registration-service

2. Aktivieren Sie die Cloud Run Service API, mit der Ihre App ausgeführt wird, die Firestore API, die NoSQL-Datenspeicher bereitstellt, die Cloud Build API, die vom Bereitstellungsbefehl verwendet wird, und die Artifact Registry, in der der Anwendungscontainer nach der Erstellung gespeichert wird:

gcloud services enable \
  run.googleapis.com \
  firestore.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com

3. Initialisieren Sie die Firestore-Datenbank im nativen Modus. Für diesen Befehl wird die App Engine API verwendet. Sie muss also zuerst aktiviert werden.

Im Befehl muss eine Region für App Engine angegeben werden, die wir nicht verwenden, aber aus historischen Gründen erstellen müssen, sowie eine Region für die Datenbank. Wir verwenden „us-central“ für App Engine und nam5 für die Datenbank. nam5 ist der multiregionale Standort in den USA. Multiregionale Standorte maximieren die Verfügbarkeit und Langlebigkeit der Datenbank.

gcloud services enable appengine.googleapis.com

gcloud app create --region=us-central
gcloud firestore databases create --region=nam5

4. Beispiel-App-Repository klonen und zum Verzeichnis wechseln

git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git

cd cymbal-eats/partner-registration-service

3. README-Datei lesen

Öffnen Sie den Editor und sehen Sie sich die Dateien an, aus denen die App besteht. Sehen Sie sich README.md an. Dort werden die Schritte beschrieben, die zum Bereitstellen dieser App erforderlich sind. Einige dieser Schritte können implizite oder explizite Sicherheitsentscheidungen beinhalten, die berücksichtigt werden müssen. Sie werden einige dieser Einstellungen ändern, um die Sicherheit Ihrer bereitgestellten App zu verbessern. Das wird hier beschrieben:

Schritt 3: npm install ausführen

Es ist wichtig, die Herkunft und Integrität von Drittanbietersoftware zu kennen, die in einer App verwendet wird. Die Verwaltung der Sicherheit der Softwarelieferkette ist für die Entwicklung von Software relevant, nicht nur für Apps, die in Cloud Run bereitgestellt werden. In diesem Lab lag der Fokus auf der Bereitstellung. Daher wird dieser Bereich nicht behandelt. Sie können sich aber gern separat mit dem Thema beschäftigen.

Schritte 4 und 5: deploy.sh bearbeiten und ausführen

Bei diesen Schritten wird die App in Cloud Run bereitgestellt. Die meisten Optionen bleiben auf ihren Standardwerten. Sie werden diesen Schritt ändern, um die Bereitstellung auf zwei wichtige Arten sicherer zu machen:

1. Lassen Sie keinen nicht authentifizierten Zugriff zu. Es kann praktisch sein, dies für das Ausprobieren von Dingen während der Erkundung zuzulassen. Da es sich jedoch um einen Webdienst für die Nutzung durch kommerzielle Partner handelt, sollten Nutzer immer authentifiziert werden.
2. Geben Sie an, dass die Anwendung ein dediziertes Dienstkonto mit nur den erforderlichen Berechtigungen verwenden muss, anstatt eines Standardkontos, das wahrscheinlich mehr API- und Ressourcenzugriff hat als erforderlich. Dies wird auch als Grundsatz der geringsten Berechtigung bezeichnet und ist ein grundlegendes Konzept der Anwendungssicherheit.

Schritte 6 bis 11: Beispielhafte Webanfragen senden, um das korrekte Verhalten zu überprüfen

Da für die Bereitstellung der Anwendung jetzt eine Authentifizierung erforderlich ist, müssen diese Anfragen einen Nachweis der Identität des Antragstellers enthalten. Anstatt diese Dateien zu ändern, stellen Sie Anfragen direkt über die Befehlszeile.

4. Dienst sicher bereitstellen

Im deploy.sh-Script wurden zwei Änderungen als erforderlich identifiziert: kein nicht authentifizierter Zugriff und Verwendung eines dedizierten Dienstkontos mit minimalen Berechtigungen.

Sie erstellen zuerst ein neues Dienstkonto, bearbeiten dann das deploy.sh-Script, um auf dieses Dienstkonto zu verweisen und nicht authentifizierten Zugriff zu verhindern, und stellen den Dienst dann durch Ausführen des geänderten Scripts bereit, bevor wir das geänderte deploy.sh-Script ausführen können.

Dienstkonto erstellen und erforderlichen Zugriff auf Firestore/Datastore gewähren

gcloud iam service-accounts create partner-sa

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:partner-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role=roles/datastore.user

deploy.sh bearbeiten

Ändern Sie die Datei deploy.sh so, dass nicht authentifizierter Zugriff nicht zulässig ist(–no-allow-unauthenticated), und geben Sie das neue Dienstkonto(–service-account) für die bereitgestellte App an. Korrigieren Sie die GOOGLE_PROJECT_ID in die ID Ihres eigenen Projekts.

Sie löschen die ersten beiden Zeilen und ändern drei weitere Zeilen wie unten dargestellt.

gcloud run deploy $SERVICE_NAME \
  --source . \
  --platform managed \
  --region ${REGION} \
  --no-allow-unauthenticated \
  --project=$PROJECT_ID \
  --service-account=partner-sa@${PROJECT_ID}.iam.gserviceaccount.com

Dienst bereitstellen

Führen Sie das deploy.sh-Skript über die Befehlszeile aus:

./deploy.sh

Nach Abschluss der Bereitstellung wird in der letzten Zeile der Befehlsausgabe die Dienst-URL der neuen App angezeigt. Speichern Sie die URL in einer Umgebungsvariablen:

export SERVICE_URL=<URL from last line of command output>

Versuchen Sie nun, eine Bestellung aus der App mit dem curl-Tool abzurufen:

curl -i -X GET $SERVICE_URL/partners

Das Flag -i für den Befehl curl weist ihn an, Antwortheader in die Ausgabe aufzunehmen. Die erste Zeile der Ausgabe sollte so aussehen:

HTTP/2 403

Die App wurde mit der Option zum Verweigern nicht authentifizierter Anfragen bereitgestellt. Dieser curl-Befehl enthält keine Authentifizierungsinformationen und wird daher von Cloud Run abgelehnt. Die tatsächlich bereitgestellte Anwendung wird nicht ausgeführt und empfängt keine Daten aus dieser Anfrage.

5. Authentifizierte Anfragen stellen

Die bereitgestellte App wird durch Webanfragen aufgerufen, die jetzt authentifiziert werden müssen, damit Cloud Run sie zulässt. Webanfragen werden authentifiziert, indem ein Authorization-Header im folgenden Format eingefügt wird:

Authorization: Bearer identity-token

Das Identitätstoken ist ein kurzlebiger, kryptografisch signierter, codierter String, der von einem vertrauenswürdigen Authentifizierungsanbieter ausgestellt wird. In diesem Fall ist ein gültiges, nicht abgelaufenes von Google ausgestelltes Identitätstoken erforderlich.

Anfrage als Nutzerkonto stellen

Das Google Cloud CLI-Tool kann ein Token für den standardmäßig authentifizierten Nutzer bereitstellen. Führen Sie diesen Befehl aus, um ein Identitätstoken für Ihr eigenes Konto abzurufen und in der Umgebungsvariable ID_TOKEN zu speichern:

export ID_TOKEN=$(gcloud auth print-identity-token)

Standardmäßig sind von Google ausgestellte Identitätstokens eine Stunde lang gültig. Führen Sie den folgenden curl-Befehl aus, um die Anfrage zu stellen, die zuvor abgelehnt wurde, weil sie nicht autorisiert war. Dieser Befehl enthält den erforderlichen Header:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

Die Befehlsausgabe sollte mit HTTP/2 200 beginnen. Das bedeutet, dass die Anfrage akzeptabel ist und ausgeführt wird. Wenn Sie eine Stunde warten und diese Anfrage noch einmal senden, schlägt sie fehl, weil das Token abgelaufen ist. Der Antworttext befindet sich am Ende der Ausgabe, nach einer leeren Zeile:

{"status":"success","data":[]}

Es sind noch keine Partner vorhanden.

Registrieren Sie Partner mit den JSON-Beispieldaten im Verzeichnis mit zwei curl-Befehlen:

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner.json" \
  $SERVICE_URL/partner

und

curl -X POST \
  -H "Authorization: Bearer $ID_TOKEN" \
  -H "Content-Type: application/json" \
  -d "@example-partner2.json" \
  $SERVICE_URL/partner

Wiederholen Sie die GET-Anfrage, um alle registrierten Partner aufzurufen:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $ID_TOKEN"

Sie sollten JSON-Daten mit viel mehr Inhalt sehen, die Informationen zu den beiden registrierten Partnern enthalten.

Anfrage als nicht autorisiertes Konto stellen

Die authentifizierte Anfrage im letzten Schritt war nicht nur erfolgreich, weil sie authentifiziert wurde, sondern auch, weil der authentifizierte Nutzer (Ihr Konto) autorisiert war. Das Konto hatte also die Berechtigung, die App aufzurufen. Nicht alle authentifizierten Konten sind dazu autorisiert.

Das im vorherigen Aufruf verwendete Standardkonto wurde autorisiert, da es das Konto ist, mit dem das Projekt mit der App erstellt wurde. Standardmäßig hat es daher die Berechtigung, alle Cloud Run-Anwendungen im Konto aufzurufen. Diese Berechtigung kann bei Bedarf widerrufen werden, was in einer Produktionsanwendung wünschenswert wäre. Stattdessen erstellen Sie ein neues Dienstkonto ohne zugewiesene Berechtigungen oder Rollen und versuchen, damit auf die bereitgestellte App zuzugreifen.

1. Erstellen Sie ein Dienstkonto mit dem Namen tester.

gcloud iam service-accounts create tester

2. Sie erhalten ein Identitätstoken für dieses neue Konto, ähnlich wie Sie zuvor eines für Ihr Standardkonto erhalten haben. Dazu muss Ihr Standardkonto jedoch die Berechtigung haben, die Identität von Dienstkonten zu übernehmen. Erteilen Sie Ihrem Konto diese Berechtigung.

export USER_EMAIL=$(gcloud config list account --format "value(core.account)")

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="user:$USER_EMAIL" \
  --role=roles/iam.serviceAccountTokenCreator

3. Führen Sie nun den folgenden Befehl aus, um ein Identitätstoken für dieses neue Konto in der Umgebungsvariablen TEST_IDENTITY zu speichern. Wenn der Befehl eine Fehlermeldung anzeigt, warten Sie ein oder zwei Minuten und versuchen Sie es noch einmal.

export TEST_TOKEN=$( \
  gcloud auth print-identity-token \
    --impersonate-service-account \
    "tester@$PROJECT_ID.iam.gserviceaccount.com" \
)

4. Stellen Sie die authentifizierte Webanfrage wie zuvor, aber mit diesem Identitätstoken:

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

Die Befehlsausgabe beginnt wieder mit HTTP/2 403, da die Anfrage zwar authentifiziert, aber nicht autorisiert ist. Das neue Dienstkonto ist nicht berechtigt, diese App aufzurufen.

Konto autorisieren

Ein Nutzer oder ein Dienstkonto muss die Rolle „Cloud Run Invoker“ für einen Cloud Run-Dienst haben, um Anfragen an ihn zu senden. Weisen Sie dem Dienstkonto des Testers diese Rolle mit dem folgenden Befehl zu:

export REGION=us-central1
gcloud run services add-iam-policy-binding ${SERVICE_NAME} \
  --member="serviceAccount:tester@$PROJECT_ID.iam.gserviceaccount.com" \
  --role=roles/run.invoker \
  --region=${REGION}

Warten Sie ein bis zwei Minuten, bis die neue Rolle aktualisiert wurde, und wiederholen Sie dann die authentifizierte Anfrage. Speichern Sie ein neues TEST_TOKEN, wenn seit dem ersten Speichern eine Stunde oder mehr vergangen ist.

curl -i -X GET $SERVICE_URL/partners \
  -H "Authorization: Bearer $TEST_TOKEN"

Die Befehlsausgabe beginnt jetzt mit HTTP/1.1 200 OK und die letzte Zeile enthält die JSON-Antwort. Diese Anfrage wurde von Cloud Run akzeptiert und von der App verarbeitet.

6. Programme authentifizieren im Vergleich zu Nutzern authentifizieren

Für die authentifizierten Anfragen, die Sie bisher gestellt haben, wurde das curl-Befehlszeilentool verwendet. Es gibt auch andere Tools und Programmiersprachen, die stattdessen hätten verwendet werden können. Authentifizierte Cloud Run-Anfragen können jedoch nicht über einen Webbrowser mit einfachen Webseiten gestellt werden. Wenn ein Nutzer auf einer Webseite auf einen Link klickt oder ein Formular über eine Schaltfläche sendet, fügt der Browser den Authorization-Header, der für authentifizierte Anfragen an Cloud Run erforderlich ist, nicht hinzu.

Der integrierte Authentifizierungsmechanismus von Cloud Run ist für die Verwendung durch Programme und nicht durch Endnutzer vorgesehen.

Hinweis:

In Cloud Run können nutzerorientierte Webanwendungen gehostet werden. Bei diesen Anwendungen muss jedoch in Cloud Run festgelegt werden, dass nicht authentifizierte Anfragen von Webbrowsern der Nutzer zulässig sind. Wenn für die Anwendungen eine Nutzerauthentifizierung erforderlich ist, muss die Anwendung diese selbst durchführen, anstatt Cloud Run darum zu bitten. Die Anwendung kann dies auf dieselbe Weise tun wie Webanwendungen außerhalb von Cloud Run. Wie das geschieht, geht über den Rahmen dieses Codelabs hinaus.

Sie haben vielleicht bemerkt, dass die Antworten auf die Beispielanfragen bisher JSON-Objekte und keine Webseiten waren. Das liegt daran, dass dieser Partnerregistrierungsdienst für die Verwendung durch Programme vorgesehen ist und JSON ein praktisches Format für die Verarbeitung ist. Als Nächstes schreiben und führen Sie ein Programm aus, um diese Daten zu nutzen.

Authentifizierte Anfragen von einem Python-Programm aus

Ein Programm kann authentifizierte Anfragen an eine gesicherte Cloud Run-Anwendung über standardmäßige HTTP-Webanfragen stellen, muss aber einen Authorization-Header einfügen. Die einzige neue Herausforderung für diese Programme besteht darin, ein gültiges, nicht abgelaufenes Identitätstoken zu erhalten, das in diesen Header eingefügt werden kann. Dieses Token wird von Cloud Run mit Google Cloud Identity and Access Management (IAM) validiert. Das Token muss also von einer von IAM erkannten Autorität ausgestellt und signiert werden. Es gibt Clientbibliotheken in vielen Sprachen, die Programme verwenden können, um die Ausstellung eines solchen Tokens anzufordern. In diesem Beispiel wird die Python-Clientbibliothek google.auth verwendet. Es gibt mehrere Python-Bibliotheken für das Stellen von Webanfragen im Allgemeinen. In diesem Beispiel wird das beliebte requests-Modul verwendet.

Als Erstes müssen Sie die beiden Clientbibliotheken installieren:

pip install google-auth
pip install requests

Der Python-Code zum Anfordern eines Identitätstokens für den Standardnutzer lautet:

credentials, _ = google.auth.default()
credentials.refresh(google.auth.transport.requests.Request())
identity_token = credentials.id_token

Wenn Sie eine Befehlsshell wie Cloud Shell oder die Standard-Terminal-Shell auf Ihrem eigenen Computer verwenden, ist der Standardnutzer derjenige, der sich in dieser Shell authentifiziert hat. In Cloud Shell ist das in der Regel der Nutzer, der bei Google angemeldet ist. In anderen Fällen ist es der Nutzer, der mit gcloud auth login oder einem anderen gcloud-Befehl authentifiziert wurde. Wenn sich der Nutzer noch nie angemeldet hat, gibt es keinen Standardnutzer und dieser Code schlägt fehl.

Wenn ein Programm Anfragen an ein anderes Programm sendet, sollten Sie in der Regel nicht die Identität einer Person, sondern die Identität des anfragenden Programms verwenden. Dafür sind Dienstkonten da. Sie haben den Cloud Run-Dienst mit einem dedizierten Dienstkonto bereitgestellt, das die Identität für API-Anfragen wie an Cloud Firestore bereitstellt. Wenn ein Programm auf einer Google Cloud-Plattform ausgeführt wird, verwenden die Clientbibliotheken automatisch das zugewiesene Dienstkonto als Standardidentität. Daher funktioniert derselbe Programmcode in beiden Situationen.

Python-Code zum Senden einer Anfrage mit einem hinzugefügten Autorisierungsheader:

auth_header = {"Authorization": "Bearer " + identity_token}
response = requests.get(url, headers=auth_header)

Das folgende vollständige Python-Programm sendet eine authentifizierte Anfrage an den Cloud Run-Dienst, um alle registrierten Partner abzurufen, und gibt dann ihre Namen und zugewiesenen IDs aus. Kopieren Sie den folgenden Befehl und führen Sie ihn aus, um diesen Code in der Datei print_partners.py zu speichern.

cat > ./print_partners.py << EOF
def print_partners():
    import google.auth
    import google.auth.transport.requests
    import requests

    credentials, _ = google.auth.default()
    credentials.refresh(google.auth.transport.requests.Request())
    identity_token = credentials.id_token

    auth_header = {"Authorization": "Bearer " + identity_token}
    response = requests.get("${SERVICE_URL}/partners", headers=auth_header)

    parsed_response = response.json()
    partners = parsed_response["data"]

    for partner in partners:
        print(f"{partner['partnerId']}: {partner['name']}")


print_partners()
EOF

Sie führen dieses Programm mit einem Shell-Befehl aus. Sie müssen sich zuerst als Standardnutzer authentifizieren, damit das Programm diese Anmeldedaten verwenden kann. Führen Sie den folgenden gcloud-auth-Befehl aus:

gcloud auth application-default login

Folgen Sie der Anleitung, um die Anmeldung abzuschließen. Führen Sie das Programm dann über die Befehlszeile aus:

python print_partners.py

Die Ausgabe sollte in etwa so aussehen:

10102: Zippy food delivery
67292: Foodful

Die Anfrage des Programms hat den Cloud Run-Dienst erreicht, da sie mit Ihrer Identität authentifiziert wurde. Sie sind der Inhaber dieses Projekts und daher standardmäßig berechtigt, es auszuführen. Es ist üblicher, dass dieses Programm unter der Identität eines Dienstkontos ausgeführt wird. Wenn der Code in den meisten Google Cloud-Produkten wie Cloud Run oder App Engine ausgeführt wird, ist die Standardidentität ein Dienstkonto und wird anstelle eines privaten Kontos verwendet.

7. Glückwunsch!

Herzlichen Glückwunsch! Sie haben das Codelab abgeschlossen.

Nächste Schritte:

Weitere Codelabs zu Cymbal Eats:

• Cloud Workflows mit Eventarc auslösen
• Ereignisverarbeitung über Cloud Storage auslösen
• Verbindung von Cloud Run zu privatem Cloud SQL herstellen
• Verbindung zu vollständig verwalteten Datenbanken über Cloud Run herstellen
• Serverlose Anwendung mit Identity-Aware Proxy (IAP) sichern
• Cloud Run-Jobs mit Cloud Scheduler auslösen
• Cloud Run-Ingress-Traffic sichern
• Verbindung zu privaten AlloyDB-Instanzen von GKE Autopilot herstellen

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten durch Löschen des für die Anleitung erstellten Projekts.