Authentifizierung bei externen Diensten mit der Identität eines KI-Agenten

Mit der Agent Identity-Funktion können Ihre Agenten Google Cloud ihre eigene Identität verwenden, um sich bei externen Diensten und bei Arbeitslasten zu authentifizieren, die in Cloud Run oder Google Kubernetes Engine (GKE) gehostet werden. Mit OpenID Connect (OIDC)-ID-Tokens können Sie Agenten mit Cloud-Plattformen von Drittanbietern wie Amazon Web Services (AWS) und Microsoft Azure, benutzerdefinierten APIs, API-Gateways und lokalen Back-Ends verbinden.

Wenn ein Agent in eigener Verantwortung handelt, gibt Agent Identity ein OIDC-ID-Token aus. Dabei handelt es sich um ein JSON Web Token (JWT), das die SPIFFE-Identität des Agenten bestätigt und mit den Ausstellerschlüsseln für die Trust-Domain des Agenten (verwalteter Workload Identity-Pool) signiert ist. Externe Systeme können diese ID-Tokens ohne Google Cloud Anmeldedaten oder SDKs über öffentliche Endpunkte prüfen, die vom Google Cloud Security Token Service gehostet werden:

  • Ein OpenID Connect Discovery 1.0-Endpunkt (/.well-known/openid-configuration), der die OpenID-Anbieter-Metadaten und den öffentlichen Schlüsselendpunkt (jwks_uri) veröffentlicht.
  • Ein JSON Web Key Set (JWKS)-Endpunkt (/openid/jwks), der die aktiven öffentlichen Schlüssel bereitstellt, die zum Überprüfen von Signaturen auf Agent-ID-Tokens verwendet werden.

Informationen zum Authentifizieren Ihres Agenten bei Google Cloud APIs und Ressourcen mit seiner eigenen Identität finden Sie unter Mit der eigenen Identität eines Agenten authentifizieren Google Cloud . Informationen zum Zugriff auf Dienste im Namen eines Endnutzers finden Sie unter Mit dreibeinigem OAuth und dem Autorisierungsmanager authentifizieren.

Hinweis

  1. Prüfen Sie, ob Sie die richtige Authentifizierungsmethode ausgewählt haben. Informationen zur Funktionsweise von SPIFFE-Identitäten, Trust-Domains, und Agent-Anmeldedaten finden Sie in der Übersicht zu Agent Identity.
  2. Erstellen und stellen Sie einen Agenten bereit, bei dem Agent Identity aktiviert ist.

  3. Prüfen Sie, ob Ihr externer Dienst oder Identitätsanbieter die folgenden Anforderungen erfüllt:

  4. Ermitteln Sie die folgenden Konfigurationswerte für Ihren Agenten und den externen Zieldienst:

    • Aussteller-URL (iss Anforderung): Die Aussteller-URL des Workload Identity-Pools für Ihre Organisation (https://sts.googleapis.com/v1/organizations/ORGANIZATION_ID/locations/global/workloadIdentityPools/TRUST_DOMAIN) oder Ihr Projekt (https://sts.googleapis.com/v1/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/TRUST_DOMAIN).
    • Zulässige Zielgruppe (aud-Anforderung): Der Zielgruppen-URI, den der externe Dienst oder Identitätsanbieter bei der Validierung von ID-Tokens erwartet.

  5. Prüfen Sie, ob Sie die erforderlichen Rollen haben, um diese Aufgabe auszuführen.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Bereitstellen eines Agenten mit Agent Identity benötigen:

  • Agent in der Agent Runtime auf der Gemini Enterprise Agent Platform bereitstellen: Vertex AI-Nutzer (roles/aiplatform.user)
  • Agent-Dienst in Cloud Run bereitstellen: Cloud Run Admin (roles/run.admin)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Bereitstellen eines Agenten mit Agent Identity erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen , um die notwendigen Berechtigungen anzuzeigen, die erforderlich sind:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um einen Agenten mit Agent Identity bereitzustellen:

  • Agent in der Agent Runtime auf der Gemini Enterprise Agent Platform bereitstellen:
    • aiplatform.reasoningEngines.create
    • aiplatform.reasoningEngines.update
  • Agent-Dienst in Cloud Run bereitstellen:
    • run.services.create
    • run.services.update

Sie können diese Berechtigungen gegebenenfalls auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

OIDC-ID-Token für einen Agenten abrufen

Führen Sie die folgenden Schritte aus, um Ihren Agenten so zu konfigurieren, dass er ein OIDC-ID-Token abruft und an einen externen Dienst sendet:

  1. Agenten mit Agent Identity konfigurieren
  2. OIDC-ID-Token im Anwendungscode anfordern

Agenten mit Agent Identity konfigurieren

Aktivieren Sie Agent Identity, wenn Sie Ihren Agenten bereitstellen:

  • Wenn Sie Ihren Agenten in der Agent Runtime auf der Gemini Enterprise Agent Platform bereitstellen, legen Sie identity_type auf AGENT_IDENTITY fest:

    remote_app = client.agent_engines.create(
    agent=app,
    config={
        "identity_type": types.IdentityType.AGENT_IDENTITY,
        "requirements": ["google-cloud-aiplatform[agent_engines,adk]"],
    },
)

  • Wenn Sie einen Container-Agent-Dienst in Cloud Run bereitstellen, übergeben Sie das Flag --identity-type=agent-identity:

    gcloud run deploy SERVICE_NAME \
    --image=IMAGE_URL \
    --identity-type=agent-identity \
    --no-allow-unauthenticated

    Ersetzen Sie Folgendes:

    • SERVICE_NAME: Der Name Ihres Cloud Run-Dienstes.
    • IMAGE_URL: Die Container-Image-URL für Ihren Agenten.

OIDC-ID-Token im Anwendungscode anfordern

Verwenden Sie im Anwendungscode Ihres Agenten die Google Auth-Clientbibliothek, um ein OIDC-ID-Token für Ihre externe Zielgruppe anzufordern. Die Clientbibliothek übernimmt die Tokengenerierung, das lokale Caching und die automatische Erneuerung vom Metadatenserver.

Standardmäßig binden unterstützte Google Auth-Clientbibliotheken OIDC-ID-Tokens kryptografisch an das eindeutige X.509-Zertifikat des Agenten, indem sie den Zertifikatsfingerabdruck in die cnf-Anforderung (x5t#S256) des Tokens einfügen. Empfangende Dienste können diese Anforderung optional mit dem Clientzertifikat vergleichen, das während eines gegenseitigen TLS-Handshakes (mTLS) präsentiert wird, oder die Anforderung ignorieren, wenn sie die Zertifikatsbindung nicht erzwingen.

Cloud Run erzwingt die Zertifikatsbindung automatisch, wenn die cnf-Anforderung in einem ID-Token vorhanden ist. Wenn Ihr Agent einen Cloud Run-Dienst mit einem gebundenen ID-Token aufruft, müssen Sie den mTLS-Endpunkt (*.mtls.run.app) über eine mTLS-Verbindung aufrufen. Wenn Sie stattdessen weiterhin eine Standard-URL *.run.app aufrufen möchten, deaktivieren Sie die Zertifikatsbindung pro Anfrage (z. B. durch Festlegen von bind_id_token=False in Python) oder für die gesamte Laufzeitumgebung mit GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN=false. Unterstützte Bibliotheksversionen und Beispiele finden Sie unter Zertifikatsgebundene Tokens deaktivieren.

Wenn Sie einen Endpunkt aufrufen, der die Zertifikatsbindung über mTLS erzwingt, konfigurieren Sie die Clientsitzung so, dass das X.509-Zertifikat des Agenten während des mTLS-Handshakes präsentiert wird (z. B. durch Aufrufen von authed_session.configure_mtls_channel() in Python).

In den folgenden Beispielen wird die google-auth-Bibliothek verwendet, um ein zertifikatsgebundenes OIDC-ID-Token anzufordern, optional den mTLS-Kanal zu konfigurieren und das Token als Bearer-Token in einer ausgehenden Anfrage anzuhängen:

Python

from google.auth.transport.requests import AuthorizedSession
from google.oauth2 import id_token

# 1. Specify the audience expected by the external receiver
# (for example, AWS Bedrock AgentCore or your external service URL).
target_audience = "https://EXTERNAL_SERVICE_AUDIENCE"

# 2. Create ID token credentials and an AuthorizedSession, which handles
# local token caching, automatic renewal before expiry, and the
# Bearer header.
credentials = id_token.fetch_id_token_credentials(audience=target_audience)
authed_session = AuthorizedSession(credentials)

# 3. Send the authenticated request to the external service.
response = authed_session.post(
    "https://EXTERNAL_SERVICE_ENDPOINT",
    json={"prompt": "Hello from Agent"},
)

Ersetzen Sie Folgendes:

  • EXTERNAL_SERVICE_AUDIENCE: Der Zielgruppen-URI, der von Ihrem empfangenden Dienst erwartet wird (z. B. bedrock.us-east-1.amazonaws.com oder api.example.com).
  • EXTERNAL_SERVICE_ENDPOINT: Die URL des externen API- oder Back-End-Endpunkts, den Ihr Agent aufruft.

Python (mTLS)

from google.auth.transport.requests import AuthorizedSession
from google.oauth2 import id_token

# 1. Specify the audience expected by the receiving service
# (for example, a regional Cloud Run mTLS URL or an on-premises mTLS endpoint).
target_audience = "https://EXTERNAL_SERVICE_AUDIENCE"

# 2. Create certificate-bound ID token credentials and configure the mTLS
# channel to present the agent's X.509 certificate.
credentials = id_token.fetch_id_token_credentials(audience=target_audience)
authed_session = AuthorizedSession(credentials)
authed_session.configure_mtls_channel()

# 3. Send the authenticated request over mTLS.
response = authed_session.post(
    "https://EXTERNAL_SERVICE_ENDPOINT",
    json={"prompt": "Hello from Agent"},
)

Ersetzen Sie Folgendes:

  • EXTERNAL_SERVICE_AUDIENCE: Der Zielgruppen-URI, der von Ihrem empfangenden Dienst erwartet wird (z. B. eine regionale Cloud Run-mTLS-URL oder api.example.com).
  • EXTERNAL_SERVICE_ENDPOINT: Die URL des mTLS-API- oder Back-End-Endpunkts, den Ihr Agent aufruft.

Anleitungen und Beispiele für Clientbibliotheken in anderen Sprachen wie Go, Node.js und Java finden Sie unter ID-Token abrufen. Clientbibliotheken für diese Sprachen unterstützen --identity-type=agent-identity. Bibliotheken, die zertifikatsgebundene ID-Tokens unterstützen, binden Tokens standardmäßig und ermöglichen es Ihnen, die Bindung für einzelne Anfragen zu deaktivieren.

Agent Identity-ID-Tokens prüfen

Wenn ein externer Dienst ein OIDC-ID-Token von Ihrem Agenten erhält, prüfen Sie das Token mit einer der folgenden Methoden, je nach Zieldienst:

Integrierte Workload Identity-Föderation verwenden

Wenn Ihr empfangender Dienst auf einer Cloud-Plattform ausgeführt wird, die die integrierte IAM-Authentifizierung oder die OIDC-Workload Identity-Föderation unterstützt, müssen Sie keinen benutzerdefinierten Code zur Tokenprüfung schreiben:

  • Cloud Run: Wenn Ihr empfangender Dienst in Cloud Run mit authentifiziertem Ingress (--no-allow-unauthenticated) ausgeführt wird, prüft Cloud Run eingehende Agent Identity-Tokens auf der Ingress-Ebene. Wenn das Token die cnf Anforderung enthält, konfigurieren Sie den aufrufenden Agenten so, dass er die regionale mTLS-URL des empfangenden Dienstes (https://SERVICE_NAME-PROJECT_NUMBER.REGION.mtls.run.app) verwendet, damit Cloud Run das Clientzertifikat während des mTLS-Handshakes prüfen kann. Weisen Sie dem aufrufenden Agenten für den empfangenden Dienst die Rolle „Cloud Run Invoker“ (roles/run.invoker) zu. Weitere Informationen finden Sie unter Bei MCP-Servern in Cloud Run authentifizieren.

    Wenn Ihr Dienst nicht authentifizierten Ingress zulässt und Tokens in Anwendungscode prüft, lesen Sie den Abschnitt Tokens programmatisch prüfen.

  • Amazon Bedrock: Konfigurieren Sie die eingehende JWT-Authentifizierung, indem Sie die Google Cloud Security Token Service-Discovery-URL oder die Aussteller-URL und die erwartete Zielgruppe angeben. Eine Anleitung finden Sie in der AWS-Dokumentation unter Configure inbound JWT authorizer.

  • Microsoft Entra ID: Konfigurieren Sie Anmeldedaten für die föderierte Identität mit dem Other issuer-Szenario. Geben Sie die Google Cloud Security Token Service Aussteller-URL, die erwartete Zielgruppe und die Subjekt-ID (sub Anforderung) an. Eine Anleitung finden Sie in der Microsoft Learn-Dokumentation unter Create a trust relationship between an app and an external identity provider.

Tokens programmatisch prüfen

Wenn Ihr Agent Anfragen an eine benutzerdefinierte API, einen Microservice, ein API-Gateway oder eine lokale Arbeitslast sendet, muss der empfangende Dienst das eingehende OIDC-ID-Token prüfen, bevor er Zugriff gewährt. Ihr Agent übergibt dieses Token in der Regel im Authorization: Bearer TOKEN HTTP-Header.

Führen Sie die folgenden Schritte aus, um eingehende ID-Tokens programmatisch zu prüfen:

  1. Aussteller-URL des Tokens extrahieren und prüfen
  2. Öffentliche Signaturschlüssel ermitteln und im Cache speichern
  3. Tokensignatur und -anforderungen prüfen
  4. Optional: Zertifikatsbindung prüfen (cnf-Anforderung)
  5. SPIFFE-Identität des Agenten autorisieren

Aussteller-URL des Tokens extrahieren und prüfen

Wenn eine eingehende Anfrage eingeht, lesen Sie die nicht geprüfte JWT-Nutzlast, um die iss-Anforderung (Aussteller) zu extrahieren. Diese Anforderung enthält die URL des Workload Identity-Pools für die Trust-Domaindes Agenten. Diese URL dient als Basis-URL für das Discovery-Dokument und die öffentlichen Signaturschlüssel.

Prüfen Sie vor dem Senden ausgehender Netzwerkanfragen, ob die iss Anforderung mit der erwarteten Google Cloud Security Token Service-Workload Identity-Pool-URL für Ihre Organisation oder Ihr Projekt übereinstimmt:

  • Trust-Domains auf Organisationsebene:

    https://sts.googleapis.com/v1/organizations/ORGANIZATION_ID/locations/global/workloadIdentityPools/TRUST_DOMAIN

    Beispiel: Für eine Organisation mit der ID 123456789012, TRUST_DOMAIN ist agents.global.org-123456789012.system.id.goog.

  • Trust-Domains auf Projektebene (für Projekte ohne Organisation):

    https://sts.googleapis.com/v1/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/TRUST_DOMAIN

    Beispiel: Für ein Projekt mit der Nummer 9876543210, TRUST_DOMAIN ist agents.global.proj-9876543210.system.id.goog.

Öffentliche Signaturschlüssel ermitteln und im Cache speichern

Nachdem Sie die Aussteller-URL geprüft haben, rufen Sie die öffentlichen Signaturschlüssel vom Google Cloud Security Token Service ab und speichern Sie sie im Cache:

  1. OpenID Connect Discovery-Endpunkt abfragen: Hängen Sie /.well-known/openid-configuration an die Basis-Aussteller-URL an und senden Sie eine nicht authentifizierte HTTP GET Anfrage:

    Ersetzen Sie folgende Werte in den Anfragedaten:

    • ORGANIZATION_ID: Ihre Google Cloud Organisations-ID. Ersetzen Sie für ein Projekt ohne Organisation organizations/ORGANIZATION_ID durch projects/PROJECT_NUMBER.
    • TRUST_DOMAIN: Die Workload Identity-Pool-ID für die Trust-Domain Ihres Agenten (z. B. agents.global.org-123456789012.system.id.goog).

    HTTP-Methode und URL: 

    GET https://sts.googleapis.com/v1/organizations/ORGANIZATION_ID/locations/global/workloadIdentityPools/TRUST_DOMAIN/.well-known/openid-configuration

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

    Bei einer erfolgreichen Anfrage wird der Status HTTP 200 OK und ein JSON Objekt mit den OpenID-Anbieter-Metadaten, einschließlich des Felds jwks_uri zurückgegeben:

    {
  "issuer": "https://sts.googleapis.com/v1/organizations/123456789012/locations/global/workloadIdentityPools/agents.global.org-123456789012.system.id.goog",
  "jwks_uri": "https://sts.googleapis.com/v1/organizations/123456789012/locations/global/workloadIdentityPools/agents.global.org-123456789012.system.id.goog/openid/jwks",
  "authorization_endpoint": "https://sts.googleapis.com/v1/organizations/123456789012/locations/global/workloadIdentityPools/agents.global.org-123456789012.system.id.goog/authorize",
  "token_endpoint": "https://sts.googleapis.com/v1/organizations/123456789012/locations/global/workloadIdentityPools/agents.global.org-123456789012.system.id.goog/token",
  "response_types_supported": [
    "id_token"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ]
}

  2. JSON Web Key Set (JWKS)-Endpunkt abfragen: Senden Sie eine nicht authentifizierte HTTP GET Anfrage an die jwks_uri URL, die in den OpenID-Anbieter-Metadaten zurückgegeben wurde:

    Ersetzen Sie folgende Werte in den Anfragedaten:

    • ORGANIZATION_ID: Ihre Google Cloud Organisations-ID. Ersetzen Sie für ein Projekt ohne Organisation organizations/ORGANIZATION_ID durch projects/PROJECT_NUMBER.
    • TRUST_DOMAIN: Die Workload Identity-Pool-ID für die Trust-Domain Ihres Agenten (z. B. agents.global.org-123456789012.system.id.goog).

    HTTP-Methode und URL: 

    GET https://sts.googleapis.com/v1/organizations/ORGANIZATION_ID/locations/global/workloadIdentityPools/TRUST_DOMAIN/openid/jwks

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

    Bei einer erfolgreichen Anfrage wird der HTTP 200 OK Status und ein JSON Objekt mit einem Array öffentlicher Schlüssel zurückgegeben, die gemäß RFC 7517 formatiert sind:

    {
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "alg": "RS256",
      "kid": "4d1933f8e6c4e0b512c140989f6655c68997...",
      "n": "uQn4zN_1mQ0VpGv82-Wp3w...",
      "e": "AQAB"
    }
  ]
}

  3. Discovery-Dokument und Schlüssel im Cache speichern: Die Antworten von sowohl dem OpenID Connect Discovery-Endpunkt als auch dem JWKS-Endpunkt enthalten den folgenden HTTP-Cache-Header:

    Cache-Control: public, max-age=86400, must-revalidate

    Speichern Sie das Discovery-Dokument und das JWKS bis zu 24 Stunden (86400 Sekunden) im Cache, um die Prüfleistung zu verbessern und Ratenbegrenzungen zu vermeiden.

    Google Cloud rotiert regelmäßig die privaten und öffentlichen Signaturschlüssel für Workload Identity-Pools. Wenn Ihr Prüfer ein eingehendes Token mit einer kid (Schlüssel-ID) erhält, die nicht im lokalen Schlüsselcache enthalten ist, rufen Sie ein neues JWKS vom Endpunkt /openid/jwks ab, bevor Sie das Token ablehnen.

    Wenn beim Abfragen der Discovery- oder JWKS Endpunkte HTTP-Fehler auftreten, lesen Sie den Hilfeartikel Probleme mit der Agent Identity-Authentifizierung beheben.

Tokensignatur und -anforderungen prüfen

Verwenden Sie eine Standardbibliothek zur OIDC- oder JWT-Prüfung (z. B. Google Tink), um die Tokensignatur kryptografisch zu prüfen und die JWT-Anforderungen zu validieren. Gehen Sie dabei so vor:

  1. Signatur: Suchen Sie im im Cache gespeicherten JWKS nach dem öffentlichen Schlüssel, der mit der kid (Schlüssel-ID) im JWT-Header übereinstimmt. Prüfen Sie die Signatur mit dem im Feld alg angegebenen Algorithmus (RS256). Untersuchen Sie zur Vorwärtskompatibilität die Felder alg und kty im JWKS dynamisch, anstatt Algorithmustypen fest zu codieren.
  2. Aussteller (iss): Prüfen Sie, ob die iss Anforderung mit der vertrauenswürdigen Google Cloud Aussteller-URL des Workload Identity-Pools für Ihre Trust-Domain übereinstimmt.
  3. Zielgruppe (aud): Prüfen Sie, ob die aud-Anforderung mit der konfigurierten Zielgruppen-ID Ihres Dienstes übereinstimmt.
  4. Ausstellungszeit (iat) und Ablaufzeit (exp): Prüfen Sie, ob die iat-Anforderung in der Vergangenheit liegt und die aktuelle Zeit vor der exp-Anforderung liegt (mit einer geringen Toleranz für die Uhrzeitabweichung, z. B. 1 bis 2 Minuten).

Im folgenden Beispiel wird Google Tink (tink.jwt) verwendet, um ein Agent Identity-ID-Token mit einer JWKS-JSON-Nutzlast zu prüfen:

Python

import tink
from tink import jwt

# Initialize Tink JWT signature primitives (call once at application startup).
jwt.register_jwt_signature()


def verify_agent_identity_token(
    token: str,
    jwks_json: str,
    expected_issuer: str,
    expected_audience: str,
) -> jwt.VerifiedJwt:
    """Verifies an Agent Identity JWT against a JWKS JSON string using Tink.

    Args:
        token: The compact serialized JWT string.
        jwks_json: The JWKS JSON string fetched from the STS pool endpoint.
        expected_issuer: The expected token issuer ('iss' claim).
        expected_audience: The expected token audience ('aud' claim).

    Returns:
        jwt.VerifiedJwt: The verified JWT claims object.

    Raises:
        tink.TinkError: If the JWKS cannot be parsed, the key is not found,
            or token validation (signature, issuer, audience, expiration) fails.
    """
    # 1. Convert the JWKS JSON into a Tink public KeysetHandle.
    keyset_handle = jwt.jwk_set_to_public_keyset_handle(jwks_json)

    # 2. Instantiate the Tink JwtPublicKeyVerify primitive.
    jwt_verifier = keyset_handle.primitive(jwt.JwtPublicKeyVerify)

    # 3. Configure expected validation rules (issuer, audience, expiration).
    # Google Cloud STS sets 'typ': 'JWT' in the header, so
    # expected_type_header="JWT" is required.
    validator = jwt.new_validator(
        expected_issuer=expected_issuer,
        expected_audience=expected_audience,
        expected_type_header="JWT",
        allow_missing_expiration=False,
    )

    # 4. Cryptographically verify the signature and standard OIDC claims.
    return jwt_verifier.verify_and_decode(token, validator)

Optional: Zertifikatsbindung prüfen (cnf-Anforderung)

Wenn Ihr empfangender Dienst die Zertifikatsbindung über mTLS erzwingt, prüfen Sie die cnf-Anforderung (x5t#S256) mit dem Clientzertifikat, das während des mTLS-Handshakes präsentiert wird:

  1. Gegenseitige TLS (mTLS) beenden: Konfigurieren Sie Ihren Server oder Ingress-Proxy so, dass das X.509-Zertifikat des Agenten während des TLS-Handshakes gemäß TLS 1.3 (RFC 9846) angefordert und geprüft wird.
  2. Zertifikat-Fingerabdruck berechnen (x5t#S256): Extrahieren Sie das untergeordnete X.509-Clientzertifikat aus der mTLS-Verbindung. Berechnen Sie den SHA-256-Hash über die DER-codierten Bytes und base64url-codieren Sie den Digest ohne = Padding.
  3. `cnf`-Anforderung (x5t#S256) prüfen: Prüfen Sie die geprüfte JWT-Nutzlast auf das `cnf`-Objekt ({"cnf": {"x5t#S256": "FINGERPRINT"}}) und prüfen Sie, ob der Wert x5t#S256 gemäß RFC 8705, Abschnitt 6.1,mit dem Zertifikat-Fingerabdruck des Clientzertifikats übereinstimmt. Wenn der Aufrufer kein Clientzertifikat über mTLS präsentiert hat oder die Fingerabdrücke nicht übereinstimmen, lehnen Sie die Anfrage mit der Antwort HTTP 401 Unauthorized ab.

SPIFFE-Identität des Agenten autorisieren

Nachdem Sie die Signatur und die Standardanforderungen des Tokens geprüft haben, prüfen Sie die geprüfte sub-Anforderung (Subjekt), um die Anfrage zu autorisieren und den aufrufenden Agenten in Ihren Audit-Logs zu erfassen.

Die sub Anforderung enthält die eindeutige SPIFFE-ID des Agenten, z. B.:

  spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

Vergleichen Sie in der Autorisierungslogik Ihres Dienstes die geprüfte sub-Anforderung mit einer Zulassungsliste vertrauenswürdiger SPIFFE-IDs von Agenten (oder Trust-Domain-Präfixen), bevor Sie Zugriff auf geschützte Ressourcen gewähren.

Nächste Schritte