Kurzlebige Anmeldedaten für mehrere Dienstkonten erstellen

Auf dieser Seite wird erläutert, wie Sie kurzlebige Anmeldedaten für ein Dienstkonto basierend auf einer Delegierungskette von Dienstkonten erstellen. Sie können diesen Ansatz verwenden, wenn Sie eine Reihe von Tokengenerierungsaufrufen ausführen müssen, um ein Token mit den Berechtigungen zu erhalten, die Sie für Ihre Aufgabe benötigen.

Nachdem Sie kurzlebige Anmeldedaten erhalten haben, können Sie damit die Identität des Dienstkontos übernehmen.

Wenn Sie ein Token mit den erforderlichen Berechtigungen mit einem einzigen Aufruf zur Generierung des Tokens erstellen können, sollten Sie kurzlebige Anmeldedaten für dieses Dienstkonto direkt erstellen.

Kurzlebige Anmeldedaten erstellen

Je nach Tokentyp, den Sie erstellen, können Sie kurzlebige Anmeldedaten verwenden, um Aufrufe an Google APIs, APIs von Drittanbietern oder Anwendungen zu authentifizieren, für die ID-Tokens erforderlich sind. Kurzlebige Anmeldedaten für Dienstkonten haben eine beschränkte Lebensdauer, die in der Regel bei wenigen Stunden liegt, und werden nicht automatisch aktualisiert. Kurzlebige Anmeldedaten für Dienstkonten sind nützlich, wenn Sie vertrauenswürdigen Dienstkonten eingeschränkten Zugriff auf Ressourcen gewähren müssen. Sie stellen außerdem ein geringeres Risiko dar als langlebige Anmeldedaten wie Dienstkontoschlüssel.

Sie können die folgenden Arten von kurzlebigen Anmeldedaten für ein Dienstkonto erstellen:

  • OAuth 2.0-Zugriffstoken

    Zugriffstokens werden von den meisten Google APIs zur Authentifizierung akzeptiert. Wenn Sie ein Zugriffstoken für ein Dienstkonto generieren, verfügt das Zugriffstoken über kein Aktualisierungstoken. Wenn das Token abläuft, müssen Sie also den Vorgang zum Erstellen des Tokens wiederholen, um ein neues zu generieren.

    Weitere Informationen finden Sie unter Zugriffstokens.

  • OIDC-ID-Tokens (OpenID Connect)

    ID-Tokens folgen der OpenID Connect-Spezifikation (OIDC). ID-Tokens werden von einer begrenzten Anzahl von Diensten und Anwendungen akzeptiert.

    Weitere Informationen finden Sie unter ID-Tokens und Authentifizierung für Anwendungen, die in Cloud Run oder Cloud Run Functions gehostet werden.

  • Selbstsignierte JSON Web Tokens (JWTs)

    Sie können selbst signierte JWTs verwenden, um sich bei einigen Google APIs zu authentifizieren, ohne ein Zugriffstoken vom Autorisierungsserver abzurufen. Für APIs, die mit API Gateway bereitgestellt werden, sind diese erforderlich.

  • Selbstsignierte binäre Blobs

    Selbstsignierte Blobs sind hilfreich in Szenarien, in denen beliebige binäre Daten sicher übertragen werden müssen. Sie werden in der Regel zu Authentifizierungszwecken verwendet.

Delegierter Anfrageablauf

Mit dem delegierten Anfrageablauf können Sie direkte Anfragen mit einer einzigen Anfrage verketten, statt mehrere direkte Anfragen nacheinander ausführen zu müssen. In diesem Ablauf wird die Anfrage für Dienstkonto-Anmeldedaten an ein oder mehrere Dienstkonten in einer Delegationskette delegiert, bevor Anmeldedaten für das endgültige Dienstkonto generiert werden. Die resultierenden Anmeldedaten repräsentieren nur das endgültige Dienstkonto und nicht die Vermittlungsdienstkonten in der Delegierungskette.

Jedes Dienstkonto in der Delegationskette muss die erforderlichen Berechtigungen für das nächste Dienstkonto in der Kette haben, damit es die Anfrage weiterleiten kann.

Wenn ein Dienstkonto alle benötigten Berechtigungen bietet, sollten Sie den einfacheren Ablauf verwenden, der unter Kurzlebige Anmeldedaten aus einem Dienstkonto erstellen beschrieben wird.

Vorbereitung

  • Enable the IAM and Service Account Credentials APIs.

    Enable the APIs

  • Sie müssen die Informationen zu IAM-Dienstkonten verstehen

  • Aktivieren Sie die Abrechnung und die IAM API, falls Sie dies noch nicht getan haben. Führen Sie dazu die Schritte aus, die in der Kurzanleitung beschrieben werden.

  • Identifizieren Sie die Dienstkonten, die Sie in Ihrer Delegationskette verwenden werden.

    Sie können ein neues Dienstkonto erstellen und es bei Bedarf in die Delegationskette aufnehmen.

Erforderliche Berechtigungen bereitstellen

Eine delegierte Anfrage umfasst mehr als zwei Identitäten: den Aufrufer, ein oder mehrere Dienstkonten in einer Delegationskette und das Dienstkonto, für das Anmeldedaten erstellt werden. Beachten Sie bei diesem Ablauf die folgenden Identitäten:

  • Dienstkonto 1 (SA_1), der Aufrufer, der eine Anfrage für die kurzlebigen Anmeldedaten ausgibt
  • Dienstkonto 2 (SA_2), ein Vermittlungsdienstkonto, das die ursprüngliche Anfrage an SA_3 delegiert. Dieses Konto leitet nur die Anfrage weiter. Es gewährt SA_1 oder SA_3 keinen zusätzlichen Zugriff.
  • Dienstkonto 3 (SA_3), das Konto mit eingeschränkten Berechtigungen, für das die Anmeldedaten erstellt werden

Damit das Delegieren möglich ist, muss jedes Konto dem vorherigen Konto in der Kette die Rolle "Ersteller von Dienstkonto-Tokens" (roles/iam.serviceAccountTokenCreator) zuweisen.

In diesem Beispiel muss SA_1 die Rolle "Ersteller von Dienstkonto-Tokens" (roles/iam.serviceAccountTokenCreator) für SA_2 zugewiesen werden. Dies ist ein Beispiel für das Dienstkonto SA_2, das als Ressource behandelt wird: Wenn Sie die Rolle SA_2 zuweisen, aktualisieren Sie die "allow"-Richtlinie auf dieselbe Art, wie Sie jede andere Ressource aktualisieren würden.

In diesem Beispiel gibt es nur ein Vermittlungsdienstkonto. Wenn Sie den Zugriff über mehr als ein Dienstkonto delegieren möchten, müssen Sie diese Rolle auch jedem anderen Dienstkonto in der Kette zuweisen.

Als Nächstes muss SA_2 auch die Rolle "Ersteller von Dienstkonto-Tokens" (roles/iam.serviceAccountTokenCreator) für SA_3 zugewiesen werden. Dadurch kann SA_2 kurzlebige Anmeldedaten für SA_3 erstellen.

In den folgenden Schritten werden die Rollen mithilfe der REST API zugewiesen. Sie können aber auch die Google Cloud Console oder die gcloud CLI verwenden.

API

Rufen Sie zuerst die "allow"-Richtlinie für SA_2 (das Vermittlungsdienstkonto) ab:

Die Methode serviceAccounts.getIamPolicy ruft die Zulassungsrichtlinie eines Dienstkontos ab.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • SA_2: Der Name des Dienstkontos 2.
  • POLICY_VERSION: Die Richtlinienversion, die zurückgegeben werden soll. Anfragen sollten die neueste Richtlinienversion angeben. Diese ist Richtlinienversion 3. Weitere Informationen finden Sie unter Richtlinienversion beim Abrufen einer Richtlinie festlegen.

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

JSON-Text anfordern:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie müssten in etwa folgende JSON-Antwort erhalten:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    }
  ]
}

Wenn Sie dem Dienstkonto keine Rolle zugewiesen haben, enthält die Antwort nur einen etag-Wert. Geben Sie diesen etag-Wert im nächsten Schritt an.

Ändern Sie als Nächstes die "allow"-Richtlinie, um SA_1 die Rolle "Ersteller von Dienstkonto-Tokens" zuzuweisen (roles/iam.serviceAccountTokenCreator).

Fügen Sie beispielsweise Folgendes hinzu, um die Beispielantwort aus dem vorherigen Schritt zu ändern:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Schreiben Sie dann die aktualisierte "allow"-Richtlinie für SA_2:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte Zulassungsrichtlinie für das Dienstkonto fest.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • SA_2: Der Name des Dienstkontos 2.

  • POLICY: Eine JSON-Darstellung der Richtlinie, die Sie festlegen möchten. Weitere Informationen zum Format einer Richtlinie finden Sie in der Richtlinienreferenz.

    Zum Festlegen der im vorherigen Schritt angezeigten Zulassungsrichtlinie ersetzen Sie beispielsweise POLICY durch Folgendes:

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

JSON-Text anfordern:

{
  "policy": POLICY
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Die Antwort enthält die aktualisierte Zulassungsrichtlinie:

Rufen Sie jetzt die "allow"-Richtlinie für SA_3 ab (das Dienstkonto, für das die Anmeldedaten erstellt werden):

Die Methode serviceAccounts.getIamPolicy ruft die Zulassungsrichtlinie eines Dienstkontos ab.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • SA_3: Der Name des Dienstkontos 3.
  • POLICY_VERSION: Die Richtlinienversion, die zurückgegeben werden soll. Anfragen sollten die neueste Richtlinienversion angeben. Diese ist Richtlinienversion 3. Weitere Informationen finden Sie unter Richtlinienversion beim Abrufen einer Richtlinie festlegen.

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

JSON-Text anfordern:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie müssten in etwa folgende JSON-Antwort erhalten:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    }
  ]
}

Wenn Sie dem Dienstkonto keine Rolle zugewiesen haben, enthält die Antwort nur einen etag-Wert. Geben Sie diesen etag-Wert im nächsten Schritt an.

Ändern Sie als Nächstes die "allow"-Richtlinie, um SA_2 die Rolle "Ersteller von Dienstkonto-Tokens" zuzuweisen (roles/iam.serviceAccountTokenCreator).

Fügen Sie beispielsweise Folgendes hinzu, um die Beispielantwort aus dem vorherigen Schritt zu ändern:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Schreiben Sie anschließend die aktualisierte Zulassungsrichtlinie:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte Zulassungsrichtlinie für das Dienstkonto fest.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • SA_3: Der Name des Dienstkontos 3.

  • POLICY: Eine JSON-Darstellung der Richtlinie, die Sie festlegen möchten. Weitere Informationen zum Format einer Richtlinie finden Sie in der Richtlinienreferenz.

    Zum Festlegen der im vorherigen Schritt angezeigten Zulassungsrichtlinie ersetzen Sie beispielsweise POLICY durch Folgendes:

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

JSON-Text anfordern:

{
  "policy": POLICY
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Die Antwort enthält die aktualisierte Zulassungsrichtlinie:

Kurzlebige Anmeldedaten anfordern

Nachdem Sie der jeweiligen Identität die entsprechenden Rollen zugewiesen haben, können Sie kurzlebige Anmeldedaten für das gewünschte Dienstkonto anfordern. Es werden die folgenden Typen von Anmeldedaten unterstützt:

Informationen zum Angeben einer Delegierungskette für diese Anfragen finden Sie auf dieser Seite im Abschnitt Delegationskette angeben.

OAuth 2.0-Zugriffstoken generieren

Standardmäßig sind OAuth 2.0-Zugriffstokens maximal eine Stunde (3.600 Sekunden) lang gültig. Sie können die maximale Lebensdauer dieser Tokens jedoch auf 12 Stunden (43.200 Sekunden) verlängern. Identifizieren Sie dazu zuerst die Dienstkonten, bei denen eine verlängerte Lebensdauer für Tokens festgelegt werden soll. Fügen Sie diese Dienstkonten danach einer Organisationsrichtlinie hinzu, in der die Listeneinschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension enthalten ist. Sie können dann beim Erstellen eines Tokens für diese Dienstkonten eine Lebensdauer von bis zu 43.200 Sekunden festlegen.

So generieren Sie ein OAuth 2.0-Zugriffstoken für ein Dienstkonto:

API

Die Methode serviceAccounts.generateAccessToken der Service Credentials API generiert ein OAuth 2.0-Zugriffstoken für ein Dienstkonto.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • SA_NAME: Der Name des Dienstkontos, für das Sie ein Token erstellen möchten.
  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • DELEGATES: Wenn Sie einen Ablauf mit delegierter Anfrage verwenden, lesen Sie den Abschnitt Delegationskette angeben auf dieser Seite. Wenn Sie einen Ablauf mit direkter Anfrage ohne Delegation verwenden, lassen Sie das Feld delegates im Anfragetext weg.

  • LIFETIME: Die Zeit in Sekunden, bis das Zugriffstoken abläuft. Beispiel: 300s

    Standardmäßig beträgt die maximale Tokenlebensdauer 1 Stunde (3.600 Sekunden). Zur Erhöhung der maximalen Lebensdauer dieser Tokens auf 12 Stunden (43.200 Sekunden) fügen Sie das Dienstkonto einer Organisationsrichtlinie hinzu, in der die Listeneinschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension enthalten ist.

HTTP-Methode und URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken

JSON-Text anfordern:

{
  "delegates": [
    DELEGATES
  ],
  "scope": [
    "https://www.googleapis.com/auth/cloud-platform"
  ],
  "lifetime": "LIFETIME"
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Wenn die Anfrage generateAccessToken erfolgreich war, enthält der Antworttext ein OAuth 2.0-Zugriffstoken und eine Ablaufzeit. Das accessToken kann dann verwendet werden, um eine Anfrage im Namen des Dienstkontos zu authentifizieren, bis die expireTime erreicht wurde: 

{
  "accessToken": "eyJ0eXAi...NiJ9",
  "expireTime": "2020-04-07T15:01:23.045123456Z"
}

OpenID Connect-ID-Token generieren

OpenID Connect-ID-Tokens sind 1 Stunde (3.600 Sekunden) lang gültig. So generieren Sie ein ID-Token für ein Dienstkonto:

API

Die Methode serviceAccounts.generateIdToken der Service Credentials API generiert ein OIDC-ID-Token für ein Dienstkonto.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PRIV_SA: Die E-Mail-Adresse des Dienstkontos mit den Berechtigungen, für das das kurzlebige Token erstellt wird.
  • AUDIENCE_NAME: Die Zielgruppe für das Token, in der Regel die URL der Anwendung oder des Dienstes, auf den mit dem Token zugegriffen wird.

HTTP-Methode und URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/PRIV_SA:generateIdToken

JSON-Text anfordern:

{
  "audience": "AUDIENCE_NAME",
  "includeEmail": "true"
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Wenn die Anfrage generateId erfolgreich war, enthält der Antworttext ein ID-Token, das eine Stunde lang gültig ist. Mit token kann dann eine Anfrage im Namen des Dienstkontos authentifiziert werden: 

{
  "token": "eyJ0eXAi...NiJ9"
}

Selbstsigniertes JSON Web Token (JWT) erstellen

Selbstsignierte JSON Web Tokens (JWTs) sind in verschiedenen Szenarien hilfreich. Beispiele:

  • Authentifizierung des Aufrufs einer Google API, wie in der Google-Authentifizierungsanleitung beschrieben.
  • Sicheres Kommunizieren zwischen Google Cloud- oder Nicht-Google-Diensten wie App Engine-Anwendungen. In diesem Szenario kann eine Anwendung ein Token signieren, das sich von einer anderen Anwendung zu Authentifizierungszwecken bestätigen lässt.
  • Behandlung eines Dienstkontos als Identitätsanbieter. JWT wird dabei mit beliebigen Anforderungen zu einem Nutzer, Konto oder Gerät signiert.

So generieren Sie ein selbstsigniertes JWT für ein Dienstkonto:

API

Die Methode serviceAccounts.signJwt der Service Account Credentials API signiert ein JWT mit einem vom System verwalteten privaten Schlüssel des Dienstkontos.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • SA_NAME: Der Name des Dienstkontos, für das Sie ein Token erstellen möchten.
  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • DELEGATES: Wenn Sie einen Ablauf mit delegierter Anfrage verwenden, lesen Sie den Abschnitt Delegationskette angeben auf dieser Seite. Wenn Sie einen Ablauf mit direkter Anfrage ohne Delegation verwenden, lassen Sie das Feld delegates im Anfragetext weg.

  • JWT_PAYLOAD: Die zu signierende JWT-Nutzlast, bei der es sich um ein JSON-Objekt mit einem JWT-Anforderungssatz handelt. Schließen Sie die Anforderungen ein, die für den gewünschten Anwendungsfall erforderlich sind und benötigt werden, um die Validierungsanforderungen des aufzurufenden Dienstes zu erfüllen. Wenn Sie eine Google API aufrufen, lesen Sie die Informationen zu den Anforderungsbedingungen im Google-Authentifizierungsleitfaden.

    Die Anforderung exp (Ablaufzeit) darf höchstens 12 Stunden in der Zukunft liegen. Wenn Sie eine Google API aufrufen, darf die exp-Anforderung nicht mehr als eine Stunde in der Zukunft liegen.

    Die folgende Beispielnutzlast enthält Anforderungen zum Aufrufen einer Google API, wobei EXP ein ganzzahliger Zeitstempel ist, der die Ablaufzeit darstellt:

    { \"iss\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": EXP }

HTTP-Methode und URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signJwt

JSON-Text anfordern:

{
  "delegates": [
    DELEGATES
  ],
  "payload": "JWT_PAYLOAD"
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Wenn die signJwt-Anfrage erfolgreich war, enthält der Antworttextkörper ein signiertes JWT und die ID des Signaturschlüssels, der zum Signieren des JWT verwendet wurde. Sie können den Wert signedJwt als Inhabertoken verwenden, um eine Anfrage im Namen des Dienstkontos direkt zu authentifizieren. Das Token ist bis zu der in der Anfrage angegebenen Ablaufzeit gültig: 

{
  "keyId": "42ba1e...fc0a",
  "signedJwt": "eyJ0eXAi...NiJ9"
}

Selbstsigniertes Blob erstellen

Selbstsignierte Blobs sind hilfreich in Szenarien, in denen beliebige binäre Daten sicher übertragen werden müssen. Sie werden in der Regel zu Authentifizierungszwecken verwendet. Wenn Sie beispielsweise einen benutzerdefinierten Protokoll-/Tokentyp (nicht JWT) nutzen möchten, können Sie diese Daten zur Verwendung durch einen nachgeschalteten Dienst in ein signiertes Blob einfügen.

So generieren Sie ein selbstsigniertes Blob für ein Dienstkonto:

API

Die Methode serviceAccounts.signBlob der Service Account Credentials API signiert ein Blob mit einem vom System verwalteten privaten Schlüssel des Dienstkontos.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • SA_NAME: Der Name des Dienstkontos, für das Sie ein Token erstellen möchten.
  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • DELEGATES: Wenn Sie einen Ablauf mit delegierter Anfrage verwenden, lesen Sie den Abschnitt Delegationskette angeben auf dieser Seite. Wenn Sie einen Ablauf mit direkter Anfrage ohne Delegation verwenden, lassen Sie das Feld delegates im Anfragetext weg.
  • BLOB_PAYLOAD Ein base64-codierter String aus Byte. Beispiel: VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu.

HTTP-Methode und URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signBlob

JSON-Text anfordern:

{
  "delegates": [
    DELEGATES
  ],
  "payload": "BLOB_PAYLOAD"
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Wenn die signBlob-Anfrage erfolgreich war, enthält der Antworttext ein signiertes Blob und die Signierschlüssel-ID, mit der das Blob signiert wurde. Sie können den Wert signedBlob als Inhabertoken verwenden, um eine Anfrage im Namen des Dienstkontos direkt zu authentifizieren. Das Token ist gültig, bis der vom System verwaltete private Schlüssel des Dienstkontos abläuft. Die ID dieses Schlüssels ist der Wert des Feldes keyId in der Antwort. 

{
  "keyId": "42ba1e...fc0a",
  "signedBlob": "eyJ0eXAi...NiJ9"
}

Delegationskette angeben

Wenn Sie einen Ablauf mit delegierter Anfrage verwenden, um kurzlebige Anmeldedaten für Dienstkonten zu erstellen, muss im Anfragetext für jede API die Delegationskette von Dienstkonten in der richtigen Reihenfolge und im richtigen Format angegeben werden:

projects/-/serviceAccounts/SA_ID

Ersetzen Sie SA_ID durch die eindeutige numerische ID des Dienstkontos oder die E-Mail-Adresse des Dienstkontos.

In einer Delegationskette von SA_1 (Aufrufer) über SA_2 (delegiert) und SA_3 (delegiert) zu SA_4 enthält beispielsweise das delegates[]-Feld SA_2 und SA_3 in der folgenden Reihenfolge:

{
  "delegates": [
    "projects/-/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com",
    "projects/-/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com"
  ]
}

Der Aufrufer und das Dienstkonto, für das die Anmeldedaten erstellt werden, sind nicht in der Delegierungskette enthalten.