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

Dienstkonto erstellen

Erstellen Sie als Erstes ein neues Dienstkonto.

Erforderliche Berechtigungen gewähren

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 hilfreich in Szenarien, in denen Projekte verschiedene Dienstkontostufen 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 sa-1 die Berechtigung 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 ein Dienstkonto, das als Ressource und nicht als Identität behandelt wird: sa-1 muss die Berechtigung zum Ausstellen von Anmeldedaten für sa-2 erteilt werden. Weitere Informationen dazu, wie Dienstkonten als Identität oder Ressource behandelt werden, finden Sie unter Dienstkontoberechtigungen.

In den folgenden Schritten werden die erforderlichen Berechtigungen mit der REST API gewährt. Sie können jedoch auch die Cloud Console oder das gcloud-Befehlszeilentool verwenden.

API

Lesen Sie als Erstes die IAM-Richtlinie für sa-2:

Die Methode serviceAccounts.getIamPolicy ruft die IAM-Richtlinie eines Dienstkontos ab.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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 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 Richtlinie:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte IAM-Richtlinie für das Dienstkonto fest.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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 Richtlinie 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 Richtlinie.

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 ein Dienstkonto, das als Ressource und nicht als Identität behandelt wird: sa-1 muss die Berechtigung zum Delegieren des Zugriffs für sa-2 erteilt werden. Weitere Informationen dazu, wie Dienstkonten als Identität oder Ressource behandelt werden, finden Sie unter Dienstkontoberechtigungen.

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 erforderlichen Berechtigungen mit der REST API gewährt. Sie können jedoch auch die Cloud Console oder das gcloud-Befehlszeilentool verwenden.

API

Rufen Sie zuerst die IAM-Richtlinie für sa-2 (das Vermittlungsdienstkonto) ab:

Die Methode serviceAccounts.getIamPolicy ruft die IAM-Richtlinie eines Dienstkontos ab.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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 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 Richtlinie für sa-2:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte IAM-Richtlinie für das Dienstkonto fest.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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 Richtlinie 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 Richtlinie.

Rufen Sie jetzt die IAM-Richtlinie für sa-3 ab (das Dienstkonto, für das die Anmeldedaten erstellt werden):

Die Methode serviceAccounts.getIamPolicy ruft die IAM-Richtlinie eines Dienstkontos ab.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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 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 Richtlinie:

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte IAM-Richtlinie für das Dienstkonto fest.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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 Richtlinie 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 Richtlinie.

Kurzlebige Anmeldedaten anfordern

Nachdem Sie die entsprechenden Berechtigungen für jede Identität gewährt 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 Anweisungen:

  • sa-name: Der Name des Dienstkontos, für das Sie ein Token erstellen möchten.
  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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.
  • scopes: Die OAuth 2.0-Bereiche für die Anfrage. Die folgenden Bereiche sind beim Aufrufen der generateAccessToken API gültig:

    • "https://www.googleapis.com/auth/iam"
    • "https://www.googleapis.com/auth/cloud-platform"
  • 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": [
    scopes
  ],
  "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 Anweisungen:

HTTP-Methode und URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/sa-name@project-id.iam.gserviceaccount.com:generateIdToken

JSON-Text anfordern:

{
  "delegates": [
    delegates
  ],
  "audience": "sa-name@project-id.iam.gserviceaccount.com",
  "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 Anweisungen:

  • sa-name: Der Name des Dienstkontos, für das Sie ein Token erstellen möchten.
  • project-id: Ihre Google Cloud-Projekt-ID.
  • 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

  • signJwt
  • erfolgreich war, enthält der Antworttext ein signiertes JWT und die Signierschlüssel-ID, mit der das JWT signiert 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 Anweisungen:

    • sa-name: Der Name des Dienstkontos, für das Sie ein Token erstellen möchten.
    • project-id: Ihre Google Cloud-Projekt-ID.
    • 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/account-email-or-unique-id

    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.