Sichere Bereitstellung in Cloud Run

Sichere Bereitstellung in Cloud Run

Informationen zu diesem Codelab

subjectZuletzt aktualisiert: Jan. 24, 2023
account_circleVerfasst von Charlie Engelke

1. Übersicht

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

Mit einigen kleinen Änderungen an den minimalen Standardschritten zur Bereitstellung einer App in Cloud Run können Sie die Sicherheit erheblich 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 kein vollständiger Überblick über die Sicherheit der Anwendungsbereitstellung, sondern ein Blick auf Änderungen, die Sie an allen zukünftigen App-Bereitstellungen vornehmen können, um die Sicherheit mit sehr wenig Aufwand zu verbessern.

2. Einrichtung und Anforderungen

Einrichten der Umgebung im eigenen Tempo

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

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
  • Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Gerät testen, um zu 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 finden Sie in der Dokumentation.
  1. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Ausführung dieses Codelabs sollte nur wenige Kosten verursachen, wenn überhaupt. Wenn Sie die Ressourcen deaktivieren möchten, damit keine Kosten über diese Anleitung hinaus anfallen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Cloud Shell aktivieren

  1. Klicken Sie in der Cloud Console auf Cloud Shell aktivieren 853e55310c205094.png.

55efc1aaa7a4d3ad.png

Wenn Sie Cloud Shell noch nie gestartet haben, wird ein Zwischenbildschirm (unten) angezeigt, auf dem beschrieben wird, was es ist. Klicken Sie in diesem Fall auf Weiter. Dieser Bildschirm wird dann nicht mehr angezeigt. So sieht dieser einmalige Bildschirm aus:

9c92662c6a846a5c.png

Die Bereitstellung und Verbindung mit Cloud Shell sollte nur wenige Minuten dauern.

9f0e51b578fecce5.png

Auf dieser virtuellen Maschine sind alle erforderlichen Entwicklungstools installiert. 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 alle Aufgaben in diesem Codelab können Sie einfach mit einem Browser oder Ihrem Chromebook erledigen.

Sobald Sie mit Cloud Shell verbunden sind, sollten Sie sehen, dass Sie bereits authentifiziert sind und das Projekt bereits auf Ihre Projekt-ID festgelegt ist.

  1. Führen Sie in 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`
  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um zu prüfen, ob 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 korrekte Werte ersetzen.

  1. Legen Sie eine Umgebungsvariable für die Projekt-ID fest, um sie in späteren Befehlen zu verwenden:
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export SERVICE_NAME=partner-registration-service
  1. 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, die beim Erstellen zum Speichern des Anwendungscontainers verwendet wird:
gcloud services enable \
  run
.googleapis.com \
  firestore
.googleapis.com \
  cloudbuild
.googleapis.com \
  artifactregistry
.googleapis.com
  1. Initialisieren Sie die Firestore-Datenbank im nativen Modus. Für diesen Befehl wird die App Engine API verwendet. Sie muss daher zuerst aktiviert werden.

Der Befehl muss eine Region für die App Engine angeben, 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 die 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
  1. 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 lesen

Öffnen Sie den Editor und sehen Sie sich die Dateien an, aus denen die App besteht. Lesen Sie die README.md, in der die Schritte zur Bereitstellung dieser App beschrieben werden. Einige dieser Schritte können implizite oder explizite Sicherheitsentscheidungen erfordern. Sie ändern einige dieser Optionen, um die Sicherheit Ihrer bereitgestellten App zu verbessern, wie hier beschrieben:

Schritt 3: npm install ausführen

Es ist wichtig, die Herkunft und Integrität der Drittanbietersoftware zu kennen, die in einer App verwendet wird. Die Sicherheit der Softwarelieferkette ist für die Entwicklung von Software relevant, nicht nur für in Cloud Run bereitgestellte Apps. In diesem Lab liegt der Schwerpunkt auf der Bereitstellung. Daher wird dieses Thema nicht behandelt. Sie können sich das Thema aber separat ansehen.

Schritte 4 und 5 – Bearbeiten und ausführen deploy.sh

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

  1. Lassen Sie keinen nicht authentifizierten Zugriff zu. Das kann praktisch sein, um Dinge bei der explorativen Datenanalyse auszuprobieren. Da es sich jedoch um einen Webdienst für kommerzielle Partner handelt, sollten die Nutzer immer authentifiziert werden.
  2. Geben Sie an, dass die Anwendung ein spezielles Dienstkonto mit nur den erforderlichen Berechtigungen verwenden muss, anstatt ein Standarddienstkonto, das wahrscheinlich mehr API- und Ressourcenzugriff hat, als erforderlich. Dies wird als Prinzip der geringsten Berechtigung bezeichnet und ist ein grundlegendes Konzept der Anwendungssicherheit.

Schritte 6 bis 11 – Beispiel-Webanfragen stellen, um das korrekte Verhalten zu überprüfen

Da für die Anwendungsbereitstellung jetzt eine Authentifizierung erforderlich ist, müssen diese Anfragen jetzt 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 Script deploy.sh sind zwei Änderungen erforderlich: Der nicht authentifizierte Zugriff muss nicht zugelassen werden und es muss ein spezielles Dienstkonto mit minimalen Berechtigungen verwendet werden.

Sie erstellen zuerst ein neues Dienstkonto, bearbeiten dann das deploy.sh-Script, um auf dieses Dienstkonto zu verweisen und den nicht authentifizierten Zugriff zu verweigern, 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 ihm den 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 der nicht authentifizierte 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-Script ü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 jetzt, mit dem curl-Tool eine Bestellung aus der App abzurufen:

curl -i -X GET $SERVICE_URL/partners

Das Flag -i für den Befehl curl gibt an, dass Antwortheader in die Ausgabe eingeschlossen werden sollen. Die erste Zeile der Ausgabe sollte so aussehen:

HTTP/2 403

Die App wurde mit der Option bereitgestellt, nicht authentifizierte Anfragen zu verweigern. Da dieser curl-Befehl keine Authentifizierungsinformationen enthält, wird er von Cloud Run abgelehnt. Die tatsächlich bereitgestellte Anwendung wird nicht einmal ausgeführt und empfängt keine Daten von dieser Anfrage.

5. Authentifizierte Anfragen stellen

Die bereitgestellte Anwendung 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 mit Ihrem 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 Umgebungsvariablen ID_TOKEN zu speichern:

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

Von Google ausgestellte ID-Tokens sind standardmäßig eine Stunde lang gültig. Führen Sie den folgenden curl-Befehl aus, um die Anfrage zu senden, 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, was bedeutet, dass die Anfrage zulässig ist und berücksichtigt wird. Wenn Sie eine Stunde warten und diese Anfrage noch einmal versuchen, schlägt sie fehl, da das Token abgelaufen ist. Der Antworttext befindet sich am Ende der Ausgabe nach einer leeren Zeile:

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

Es gibt noch keine Partner.

Registrieren Sie Partner mit den Beispiel-JSON-Daten 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 vorherige GET-Anfrage, um jetzt alle registrierten Partner zu sehen:

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

Sie sollten JSON-Daten mit wesentlich 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 berechtigt.

Das in der vorherigen Anfrage verwendete Standardkonto wurde autorisiert, da es das Konto ist, mit dem das Projekt mit der App erstellt wurde. Dadurch erhielt es standardmäßig die Berechtigung, alle Cloud Run-Anwendungen im Konto aufzurufen. Diese Berechtigung kann bei Bedarf widerrufen werden, was in einer Produktionsanwendung wünschenswert wäre. Anstatt dies jetzt zu tun, erstellen Sie ein neues Dienstkonto, dem keine Berechtigungen oder Rollen zugewiesen sind, und versuchen, damit auf die bereitgestellte App zuzugreifen.

  1. Erstellen Sie ein Dienstkonto mit dem Namen tester.
gcloud iam service-accounts create tester
  1. 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. Gewähren 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
  1. 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 beim Ausführen des Befehls eine Fehlermeldung angezeigt wird, 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" \
)
  1. Stelle 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 Tester-Dienstkonto diese Rolle mit dem 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 die authentifizierte Anfrage. Speichere ein neues TEST_TOKEN, wenn seit der ersten Speicherung mindestens eine Stunde 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. Authentifizierung von Programmen und Authentifizierung von Nutzern

Für die bisherigen authentifizierten Anfragen wurde das curl-Befehlszeilentool verwendet. Es gibt 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 gesendet werden. Wenn ein Nutzer auf einen Link oder eine Schaltfläche klickt, um ein Formular auf einer Webseite einzureichen, fügt der Browser nicht den Authorization-Header hinzu, der von Cloud Run für authentifizierte Anfragen benötigt wird.

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

Hinweis:

Cloud Run kann nutzerorientierte Webanwendungen hosten. Bei diesen Arten von Anwendungen muss Cloud Run jedoch so konfiguriert sein, dass nicht authentifizierte Anfragen von den 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 die gleiche Weise tun wie Webanwendungen außerhalb von Cloud Run. Wie das geht, 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 Partnerregistrierungsservice für Programme gedacht ist und JSON eine praktische Form für sie ist. Als Nächstes schreiben und führen Sie ein Programm aus, um diese Daten zu verarbeiten und zu verwenden.

Authentifizierte Anfragen von einem Python-Programm

Ein Programm kann über standardmäßige HTTP-Webanfragen authentifizierte Anfragen an eine gesicherte Cloud Run-Anwendung senden, muss aber einen Authorization-Header enthalten. 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. Es muss also von einer von IAM anerkannten Zertifizierungsstelle ausgestellt und signiert werden. Es gibt Clientbibliotheken in vielen Sprachen, mit denen Programme die Ausstellung eines solchen Tokens anfordern können. In diesem Beispiel wird die Python-Clientbibliothek google.auth verwendet. Es gibt mehrere Python-Bibliotheken für das Senden von Webanfragen. In diesem Beispiel wird das beliebte requests-Modul verwendet.

Als Erstes müssen die beiden Clientbibliotheken installiert werden:

pip install google-auth
pip install requests

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

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 sich mit gcloud auth login oder einem anderen gcloud-Befehl authentifiziert hat. Wenn sich der Nutzer noch nie angemeldet hat, gibt es keinen Standardnutzer und dieser Code schlägt fehl.

Für ein Programm, das Anfragen an ein anderes Programm sendet, sollten Sie im Allgemeinen 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 speziellen Dienstkonto bereitgestellt, das die Identität bereitstellt, die bei API-Anfragen verwendet wird, z. B. an Cloud Firestore. Wenn ein Programm auf einer Google Cloud-Plattform ausgeführt wird, verwenden die Clientbibliotheken automatisch das zugewiesene Dienstkonto als Standardidentität. Derselbe Programmcode funktioniert also in beiden Fällen.

Python-Code für eine 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 druckt 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 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. Normalerweise wird dieses Programm unter der Identität eines Dienstkontos ausgeführt. Bei der Ausführung in den meisten Google Cloud-Produkten wie Cloud Run oder App Engine ist die Standardidentität ein Dienstkonto, das anstelle eines privaten Kontos verwendet wird.

7. Glückwunsch!

Herzlichen Glückwunsch, Sie haben das Codelab abgeschlossen.

Nächste Schritte:

Weitere Cymbal Eats-Codelabs:

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.