Kurzlebige Anmeldedaten für das Dienstkonto erstellen

Auf dieser Seite wird erläutert, wie Sie kurzlebige Anmeldedaten für Dienstkonten erstellen, um deren Identität zu übernehmen.

Dienstkonten können kurzlebige Anmeldedaten verwenden, um Aufrufe an Google Cloud APIs und andere Nicht-Google-APIs zu authentifizieren. Kurzlebige Anmeldedaten für Dienstkonten haben eine beschränkte Lebensdauer, die in der Regel bei wenigen Stunden liegt. 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.

Unterstützte Typen für Anmeldedaten sind OAuth 2.0-Zugriffstoken, OpenID Connect-ID-Token, selbstsignierte JSON Web Tokens (JWTs) und selbstsignierte binäre Objekte (Blobs). Die am häufigsten verwendeten Anmeldedatentypen sind OAuth 2.0-Zugriffstokens und OIDC-ID-Tokens (OpenID Connect). Im Folgenden sind einige Beispielszenarien aufgeführt:

  • OAuth 2.0-Zugriffstoken: Ein OAuth 2.0-Zugriffstoken dient dazu, den Zugriff von einem Dienstkonto auf Google Cloud APIs zu authentifizieren. Betrachten Sie den folgenden Anwendungsfall: Um erhöhte Berechtigungen für ein Projekt zu erhalten, kann ein Dienstadministrator ein Dienstkonto zum Aufrufen von Google Cloud APIs imitieren. Dazu wird ein OAuth 2.0-Zugriffstoken erstellt, das zu diesem Dienstkonto gehört. Das Token hat eine kurze Lebensdauer, sodass die erhöhten Berechtigungen nur temporär gelten. Mit kurzlebigen Tokens können Sie das Prinzip der geringsten Berechtigung für Ihre Identitäten und Ressourcen implementieren. Tokens können auch nützlich sein, wenn in einer Produktionsumgebung ein Notfall auftritt und ein Dienstadministrator eine kurzfristig erhöhte Autorisierung für das Debugging benötigt.

  • OIDC-ID-Token: Ein OIDC-ID-Token eignet sich zur Authentifizierung der Identität eines Dienstkontos bei Diensten, die OpenID Connect akzeptieren. Betrachten Sie den folgenden Anwendungsfall: Durch die Erstellung eines OIDC-ID-Tokens, das zu einem Dienstkonto gehört, kann sich ein in Google Cloud ausgeführter Dienst bei einem anderen Dienst eines dritten Cloud-Anbieters authentifizieren, z. B. bei einem Datenpipeline-Job. Wenn der Zieldienst mit OIDC konfiguriert ist, ist die Authentifizierung erfolgreich.

Hinweis

  • IAM and Service Account Credentials APIs aktivieren.

    Aktivieren Sie die 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.

Dienstkonto erstellen

Erstellen Sie als Erstes ein neues Dienstkonto.

Erforderliche Berechtigungen bereitstellen

Es gibt zwei verschiedene Abläufe, nach denen ein Aufrufer kurzlebige Anmeldedaten für ein Dienstkonto erstellen kann. Für jeden Ablauf werden entsprechende Berechtigungen benötigt:

  • Direkte Anfrage: Der Aufrufer wird als Google-Konto oder Dienstkonto authentifiziert und sendet eine direkte Anfrage zum Erstellen kurzlebiger Anmeldedaten. An diesem Ablauf sind zwei Identitäten beteiligt: der Aufrufer und das Dienstkonto, für das die Anmeldedaten erstellt werden.

  • Delegierte Anfrage: Wie bei der direkten Anfrage wird der Aufrufer als Google-Konto oder Dienstkonto authentifiziert. Die Anfrage wird jedoch an ein oder mehrere Dienstkonten in einer Delegationskette delegiert. In diesem Ablauf dienen mehrere Dienstkonten als Vermittler zwischen dem ursprünglichen Aufrufer und dem Dienstkonto, für das die Anmeldedaten erstellt werden. Jedes Dienstkonto in der Delegationskette muss die erforderlichen Berechtigungen zur Weitergabe der Anfrage haben.

    Dieser Ablauf ist nützlich in Szenarien, in denen Projekte Dienstkontoebenen mit eingeschränkten Berechtigungen enthalten, die jeweils für die Ausführung einer spezifischen oder eingeschränkten Funktion für bestimmte Ressourcen konfiguriert wurden. So hat ein Dienstkonto beispielsweise nur Berechtigungen für Cloud Storage-Ressourcen, ein anderes nur für Compute Engine-Ressourcen und so weiter. Damit Anfragen erfolgreich an Dienstkonten delegiert werden können, müssen die Konten jeweils in der Delegationskette aufgeführt sein.

Direkte Anfrageberechtigungen

Wie auf dieser Seite unter Erforderliche Berechtigungen gewähren beschrieben, umfasst eine direkte Anfrage nur zwei Identitäten: den Aufrufer und das Dienstkonto, für das die Anmeldedaten erstellt werden. Betrachten 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), das Konto mit eingeschränkten Berechtigungen, für das die Anmeldedaten erstellt werden

Wenn Sie die Berechtigung SA_1 zum Erstellen kurzlebiger Anmeldedaten erteilen möchten, weisen Sie ihm die Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) für SA_2 zu. 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 genauso, wie Sie jede andere Ressource aktualisieren würden.

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

API

Lesen Sie als Erstes die "allow"-Richtlinie für SA_2:

Die Methode serviceAccounts.getIamPolicy ruft die "allow"-Richtlinie 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:admin@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" (roles/iam.serviceAccountTokenCreator) zuzuweisen.

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:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Schreiben Sie anschließend die aktualisierte "allow"-Richtlinie:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte "allow"-Richtlinie 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:admin@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:

Delegierte Anfrageberechtigungen

Wie auf dieser Seite unter Erforderliche Berechtigungen gewähren beschrieben, umfasst eine delegierte Anfrage mehr als zwei Identitäten: den Aufrufer, ein oder mehrere Dienstkonten in einer Delegierungskette und schließlich das Dienstkonto. 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
  • 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 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 "allow"-Richtlinie 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:admin@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" (roles/iam.serviceAccountTokenCreator) zuzuweisen.

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:admin@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 "allow"-Richtlinie 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:admin@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 "allow"-Richtlinie 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:admin@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" (roles/iam.serviceAccountTokenCreator) zuzuweisen.

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:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Schreiben Sie anschließend die aktualisierte "allow"-Richtlinie:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte "allow"-Richtlinie 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:admin@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 Account Credentials API generiert ein OpenID Connect-ID-Token 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.
  • AUDIENCE_NAME: Die Zielgruppe für das Token, in der Regel die URL der Anwendung oder des Dienstes, auf die das Token zugreift.

HTTP-Methode und URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com: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.