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 dann, wie Sie sicher auf die bereitgestellte Anwendung zugreifen können. Die App ist ein „Partnerregistrierungsdienst“ der Cymbal Eats-Anwendung, die von Unternehmen genutzt wird, die mit Cymbal Eats zusammenarbeiten, um Essensbestellungen abzuwickeln.

Lerninhalte

Mit nur wenigen Änderungen an den minimalen Standardschritten für die Bereitstellung einer Anwendung in Cloud Run können Sie deren Sicherheit erheblich erhöhen. Sie ändern die Bereitstellungsschritte für eine vorhandene Anwendung und eine Bereitstellungsanleitung, um die Sicherheit der bereitgestellten Anwendung zu verbessern.

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

Dies ist kein vollständiger Überblick über die Sicherheit bei der Anwendungsbereitstellung, sondern soll sich auf Änderungen beziehen, die Sie an allen zukünftigen Bereitstellungen vornehmen können, um deren 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 Projektteilnehmer. Es handelt sich um eine Zeichenfolge, die von Google APIs nicht verwendet wird. Sie können sie jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich. Sie kann nach dem Festlegen nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. ist Ihnen meist egal, was es ist. In den meisten Codelabs musst du auf die Projekt-ID verweisen, die üblicherweise als PROJECT_ID gekennzeichnet ist. Wenn Ihnen die generierte ID nicht gefällt, können Sie eine weitere zufällige ID erstellen. Alternativ können Sie einen eigenen verwenden und nachsehen, ob er verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information gibt es noch einen dritten Wert, die Projektnummer, die von manchen APIs verwendet wird. Weitere Informationen zu allen drei Werten finden Sie in der Dokumentation.

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

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie die Standardeinstellung Keine Organisation beibehalten. 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 in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/APIs verwenden zu können. Dieses Codelab sollte möglichst wenig kosten. Wenn Sie Ressourcen herunterfahren möchten, um über diese Anleitung hinaus keine Kosten zu verursachen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion mit 300$Guthaben.

Cloud Shell aktivieren

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

Wenn Sie Cloud Shell noch nie gestartet haben, wird ein Zwischenbildschirm (below the fold) angezeigt, in dem beschrieben wird, worum es sich dabei handelt. Klicken Sie in diesem Fall auf Weiter. Der Chat wird nie wieder angezeigt. So sieht dieser einmalige Bildschirm aus:

Die Bereitstellung und Verbindung mit Cloud Shell dauert nur einen Moment.

Diese virtuelle Maschine verfügt über alle Entwicklungstools, die Sie benötigen. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und wird in Google Cloud ausgeführt. Dadurch werden die Netzwerkleistung und die Authentifizierung erheblich verbessert. Viele, wenn nicht sogar alle Arbeiten in diesem Codelab können Sie ganz einfach mit einem Browser oder Ihrem Chromebook erledigen.

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

2. 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`

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

3. 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 über die Cloud Shell-Befehlszeile aus. In der Regel können Sie die Befehle unverändert kopieren und einfügen. In einigen Fällen müssen Sie die Platzhalterwerte jedoch in korrekte Werte ändern.

1. Legen Sie eine Umgebungsvariable auf 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

2. Aktivieren Sie die Cloud Run-Dienst-API, mit der Ihre Anwendung ausgeführt wird, die Firestore API, die NoSQL-Datenspeicher bereitstellt, die vom Bereitstellungsbefehl verwendete Cloud Build API sowie 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

3. Firestore-Datenbank im nativen Modus initialisieren Da dieser Befehl die App Engine API verwendet, muss er zuerst aktiviert werden.

Der Befehl muss eine Region für App Engine angeben, die nicht verwendet wird, aber aus historischen Gründen erstellt werden muss, 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. Standorte mit mehreren Regionen 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. Klonen Sie das Repository der Beispielanwendung und rufen Sie das Verzeichnis auf

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, die die App enthalten. In der Datei README.md werden die Schritte zum Bereitstellen dieser Anwendung beschrieben. Einige dieser Schritte können implizite oder explizite Sicherheitsentscheidungen beinhalten, die zu berücksichtigen sind. Sie werden einige dieser Optionen ändern, um die Sicherheit Ihrer bereitgestellten Anwendung zu verbessern, wie hier beschrieben:

Schritt 3 – npm install ausführen

Es ist wichtig, die Herkunft und Integrität jeglicher Drittanbieter-Software zu kennen, die in einer App verwendet wird. Das Verwalten der Sicherheit der Softwarelieferkette ist für das Erstellen jeder Software relevant, nicht nur für die Bereitstellung von Anwendungen in Cloud Run. Dieses Lab konzentrierte sich auf die Bereitstellung, daher wird dieser Bereich nicht behandelt. Sie können das Thema jedoch gesondert untersuchen.

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

Mit diesen Schritten wird die Anwendung in Cloud Run bereitgestellt. Für die meisten Optionen werden die Standardeinstellungen beibehalten. Sie ändern diesen Schritt, um die Bereitstellung auf zwei wichtige Arten sicherer zu machen:

1. Lassen Sie keinen nicht authentifizierten Zugriff zu. Es kann praktisch sein, dies zu ermöglichen, während der Erkundung Dinge auszuprobieren. Es handelt sich jedoch um einen Webdienst für kommerzielle Partner, der immer seine Nutzer authentifizieren sollte.
2. Geben Sie an, dass die Anwendung ein dediziertes Dienstkonto verwenden muss, das nur mit den erforderlichen Berechtigungen zugeschnitten ist, anstelle eines Standardkontos, 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 erstellen, um das korrekte Verhalten zu überprüfen

Da die Anwendungsbereitstellung nun eine Authentifizierung erfordert, müssen diese Anfragen nun einen Nachweis der Identität des Anforderers enthalten. Anstatt diese Dateien zu ändern, stellen Sie Anfragen direkt über die Befehlszeile.

4. Dienst sicher bereitstellen

Im Skript deploy.sh wurden zwei erforderliche Änderungen identifiziert: kein nicht authentifizierter Zugriff möglich und Verwendung eines dedizierten Dienstkontos mit minimalen Berechtigungen.

Sie erstellen zuerst ein neues Dienstkonto und bearbeiten dann das deploy.sh-Skript, um auf dieses Dienstkonto zu verweisen und den nicht authentifizierten Zugriff zu unterbinden.Stellen Sie dann den Dienst bereit, indem Sie das geänderte Skript ausführen, bevor wir das geänderte deploy.sh-Skript ausführen können.

Dienstkonto erstellen und ihm den erforderlichen Zugriff auf Firestore/Datenspeicher 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, um nicht authentifizierten Zugriff(–no-allow-unauthenticated) zu verbieten und das neue Dienstkonto(–service-account) für die bereitgestellte Anwendung anzugeben. Korrigieren Sie die GOOGLE_PROJECT_ID mit der ID Ihres eigenen Projekts.

Sie löschen die ersten beiden Zeilen und ändern drei andere 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 über die Befehlszeile das Skript deploy.sh aus:

./deploy.sh

Wenn die Bereitstellung abgeschlossen ist, wird in der letzten Zeile der Befehlsausgabe die Dienst-URL der neuen Anwendung angezeigt. Speichern Sie die URL in einer Umgebungsvariablen:

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

Versuchen Sie nun, 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 weist ihn an, Antwortheader in die Ausgabe aufzunehmen. Die erste Zeile der Ausgabe sollte so aussehen:

HTTP/2 403

Die Anwendung wurde mit der Option bereitgestellt, nicht authentifizierte Anfragen nicht zuzulassen. Dieser curl-Befehl enthält keine Authentifizierungsinformationen und wird daher von Cloud Run abgelehnt. Die tatsächlich bereitgestellte Anwendung wird von dieser Anfrage nicht einmal ausgeführt oder empfangen.

5. Authentifizierte Anfragen stellen

Die bereitgestellte Anwendung wird über Webanfragen aufgerufen. Diese müssen jetzt authentifiziert werden, damit Cloud Run sie zulassen kann. Webanfragen werden durch Einfügen eines Authorization-Headers im folgenden Format authentifiziert:

Authorization: Bearer identity-token

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

Anfrage im Namen Ihres Nutzerkontos stellen

Das Google Cloud CLI-Tool kann ein Token für den standardmäßig authentifizierten Nutzer bereitstellen. Führen Sie den folgenden Befehl aus, um ein Identitätstoken für Ihr 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. Dies zeigt an, dass die Anfrage akzeptabel ist und berücksichtigt wird. Wenn Sie eine Stunde warten und die Anfrage noch einmal senden, schlägt die Anfrage fehl, da das Token abgelaufen ist. Der Text der Antwort befindet sich am Ende der Ausgabe nach einer Leerzeile:

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

Es sind noch keine Partner vorhanden.

Registrieren Sie Partner mithilfe der 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 vorherige GET-Anfrage, um jetzt alle registrierten Partner anzuzeigen:

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

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

Anfrage als nicht autorisiertes Konto senden

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

Das in der vorherigen Anfrage verwendete Standardkonto wurde autorisiert, da mit diesem Konto das Projekt erstellt wurde, das die App enthält. Außerdem wurde es standardmäßig zum Aufrufen von Cloud Run-Anwendungen im Konto berechtigt. 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 ohne zugewiesene Berechtigungen oder Rollen und verwenden dieses, um auf die bereitgestellte Anwendung 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 auf ähnliche Weise wie zuvor für Ihr Standardkonto. Dazu muss Ihr Standardkonto jedoch die Berechtigung haben, die Identität von Dienstkonten zu übernehmen. Erteile deinem 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 Umgebungsvariable TEST_IDENTITY zu speichern. Wenn der Befehl eine Fehlermeldung anzeigt, warten Sie ein bis zwei Minuten und versuchen Sie es dann noch einmal.

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

4. Führen Sie die authentifizierte Webanfrage wie zuvor aus, verwenden Sie dazu jedoch dieses 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 authentifizierte, 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 senden zu können. Weisen Sie dem Tester-Dienstkonto mit dem folgenden Befehl diese Rolle 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. Speichern Sie ein neues TEST_TOKEN, wenn seit dem ersten Speichern eine Stunde oder länger 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 Anwendung verarbeitet.

6. Programme authentifizieren und Nutzer authentifizieren

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

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

Hinweis:

Mit Cloud Run können an Nutzer gerichtete Webanwendungen gehostet werden. Für diese Arten von Anwendungen muss Cloud Run jedoch so eingerichtet werden, dass nicht authentifizierte Anfragen von Nutzern zugelassen werden. Webbrowser. Wenn für die Anwendungen eine Nutzerauthentifizierung erforderlich ist, muss sie diese verarbeiten, anstatt sie von Cloud Run zu verlangen. Die Anwendung kann dies auf die gleiche Weise tun, wie Webanwendungen außerhalb von Cloud Run tun. Wie das funktioniert, wird in diesem Codelab nicht behandelt.

Sie haben vielleicht bemerkt, dass es sich bei den Antworten auf die Beispielanfragen bisher um JSON-Objekte und nicht um Webseiten handelte. Das liegt daran, dass dieser Partnerregistrierungsdienst für Programme gedacht ist und JSON eine bequeme Form dafür darstellt. Als Nächstes schreiben Sie ein Programm und führen es aus, um diese Daten zu verarbeiten und zu verwenden.

Authentifizierte Anfragen von einem Python-Programm

Ein Programm kann authentifizierte Anfragen an eine sichere Cloud Run-Anwendung über Standard-HTTP-Webanfragen senden, jedoch mit einem Authorization-Header. Die einzige neue Herausforderung für diese Programme besteht darin, ein gültiges, noch nicht abgelaufenes Identitätstoken zu erhalten, das in diesen Header eingefügt werden muss. Dieses Token wird von Cloud Run mit Google Cloud Identity and Access Management (IAM) validiert. Daher muss es von einer von IAM anerkannten Zertifizierungsstelle ausgestellt und signiert werden. Es sind Clientbibliotheken in vielen Sprachen verfügbar, mit denen Programme die Ausgabe eines solchen Tokens anfordern können. In diesem Beispiel wird die Python-Bibliothek google.auth verwendet. Es gibt verschiedene Python-Bibliotheken für allgemeine Webanfragen: In diesem Beispiel wird das beliebte Modul requests verwendet.

Der erste Schritt besteht darin, die beiden Clientbibliotheken zu installieren:

pip install google-auth
pip install requests

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 Befehls-Shell wie Cloud Shell oder die Standard-Terminal-Shell auf Ihrem eigenen Computer verwenden, ist der Standardnutzer der Nutzer, der in dieser Shell authentifiziert wurde. In Cloud Shell ist das in der Regel der Nutzer, der in 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 der Code schlägt fehl.

Bei einem Programm, das Anfragen eines anderen Programms stellt, möchten Sie im Allgemeinen nicht die Identität einer Person verwenden, sondern die Identität des anfragenden Programms. Dafür sind Dienstkonten vorgesehen. Sie haben den Cloud Run-Dienst mit einem dedizierten Dienstkonto bereitgestellt, das die Identität bereitstellt, die er beim Senden von API-Anfragen verwendet, z. B. an Cloud Firestore. Wenn ein Programm auf einer Google Cloud Platform ausgeführt wird, verwenden die Clientbibliotheken automatisch das ihm zugewiesene Dienstkonto als Standardidentität, sodass in beiden Situationen derselbe Programmcode funktioniert.

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

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

Im folgenden vollständigen Python-Programm wird eine authentifizierte Anfrage an den Cloud Run-Dienst gestellt, um alle registrierten Partner abzurufen und dann ihre Namen und zugewiesenen IDs auszudrucken. 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 sich anzumelden. Führen Sie dann das Programm über die Befehlszeile aus:

python print_partners.py

Die Ausgabe sieht in etwa so aus:

10102: Zippy food delivery
67292: Foodful

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

7. Glückwunsch!

Glückwunsch, du hast das Codelab abgeschlossen.

Nächste Schritte:

Weitere Codelabs von Cymbal Eats:

• Cloud Workflows mit Eventarc auslösen
• Ereignisverarbeitung aus Cloud Storage auslösen
• Verbindung zu Private CloudSQL über Cloud Run herstellen
• Verbindung zu vollständig verwalteten Datenbanken über Cloud Run herstellen
• Sichere serverlose Anwendung mit Identity-Aware Proxy (IAP)
• Cloud Run-Jobs mit Cloud Scheduler auslösen
• Eingehenden Cloud Run-Traffic sichern
• Verbindung zu privater AlloyDB über 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.