Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Mit Dienstidentitäten authentifizieren

Eine Dienstidentität in Google Distributed Cloud (GDC) mit Air Gap bietet eine dedizierte Identität für Arbeitslasten oder Dienste, um programmatisch und sicher auf Ressourcen und Mikrodienste zuzugreifen. Dies sind spezielle Identitäten, die von Anwendungen oder Arbeitslasten und nicht von einer Person verwendet werden. Sie können nicht für die Anmeldung von Personen verwendet werden. Ähnlich wie bei Nutzerkonten weisen Sie einer Dienstidentität Berechtigungen und Rollen zu, um festzulegen, worauf sie zugreifen darf.

Für dieses Konzept werden zwei Begriffe verwendet. In der GDC-Konsole wird hauptsächlich der Begriff „Dienstidentität“ verwendet, während in gdcloud-Befehlen und API-Interaktionen häufig „Dienstkonto“ verwendet wird. Letzterer spiegelt den Namen der zugrunde liegenden benutzerdefinierten Kubernetes-Ressource ProjectServiceAccount wider. Beide Begriffe beziehen sich auf dasselbe: die nicht menschliche Identität für Ihre Arbeitslasten. In diesem Dokument wird die Dienstidentität als primärer Begriff verwendet.

Dienstidentitäten sind nützlich für die Verwaltung der GDC-Infrastruktur, z. B.:

Interne Distributed Cloud-Dienste und -Arbeitslasten für den sicheren Zugriff auf die API der Distributed Cloud-Steuerungsebene. Beispiel: Datenbankdienste, die mit den Kubernetes APIs interagieren, um Datenbanken zu erstellen und zu löschen.
Kundenarbeitslasten in Distributed Cloud, um auf Distributed Cloud-Dienste zuzugreifen und autorisierte API-Aufrufe (Application Programming Interface) auszuführen. Dienstidentitäten können beispielsweise einen Kunden verwalten, der ein Vertex AI Workbench-Notebook verwendet, um Audiodateien mit der Speech-to-Text API zu transkribieren.
Externe Arbeitslasten, die mit Distributed Cloud verbunden werden sollen. Dienstidentitäten können beispielsweise eine Anwendung außerhalb von Distributed Cloud verwalten, die Dokumente digitalisiert, aber die Optical Character Recognition (OCR) API verwenden möchte, um die aktuelle OCR-Engine zu ersetzen.
Distributed Cloud-Dienste oder Systemcontroller, um sicher auf Kundenressourcen oder Nutzercluster zuzugreifen. Dienstidentitäten können beispielsweise Authentifizierungs- und Autorisierungs-Workflows verwalten, bei denen die in Administratorclustern ausgeführten Dienstcontroller Arbeitslasten in den von Kunden verwalteten Nutzerclustern ausführen müssen.

Die Verwaltung von Dienstidentitäten umfasst sowohl die Dienstidentität (dargestellt durch eine ProjectServiceAccount-Ressource) als auch die zugehörigen Anmeldedaten (öffentliche und private Schlüsselpaare). Sie können Konten für Dienstidentitäten über die GDC Console, die gdcloud CLI oder die API verwalten. In der gdcloud CLI basiert das Dienstidentitätsfeature auf der globalen ProjectServiceAccount API. Da ProjectServiceAccount-Ressourcen global konfiguriert sind, werden sie in allen Zonen Ihres gdcloud-Universums ausgeführt.

Hinweis

Zum Ausführen der Aufgaben in diesem Dokument benötigen Sie ein Projekt. Informationen zum Erstellen eines Projekts finden Sie unter Projekt erstellen.

Außerdem benötigen Sie die erforderlichen Berechtigungen und müssen Ihre Umgebung vorbereiten.

IAM-Rollen anfordern

Wenn Sie Dienstidentitäten in einem Projekt erstellen, aktualisieren und löschen möchten, wenden Sie sich an Ihren IAM-Admin der Organisation oder IAM-Projektadministrator, um die Rolle IAM-Projektadministrator (project-iam-admin) anzufordern.

Der IAM-Organisationsadministrator kann diese Rolle für jedes Projekt innerhalb der Organisation zuweisen. Der IAM-Projektadministrator kann diese Rolle im Rahmen seines spezifischen Projekts zuweisen.

Umgebung vorbereiten

Führen Sie die folgende Einrichtung aus, um die Befehlszeilentools zum Verwalten von Dienstidentitäten zu verwenden:

Laden Sie die gdcloud CLI herunter und installieren Sie sie, falls noch nicht geschehen.
Wenn Sie die API mit kubectl verwenden möchten, ist eine zusätzliche Einrichtung erforderlich:
- Installieren Sie die kubectl-Befehlszeile.
- Generieren Sie die kubeconfig-Datei für den globalen API-Server, um den Zugriff auf kubectl zu konfigurieren.

Dienstidentität erstellen

Beim Erstellen einer Dienstidentität werden ein Konto und die zugehörigen Anmeldedaten erstellt.

Konto erstellen

Wenn Sie ein Konto für eine Dienstidentität erstellen möchten, verwenden Sie die GDC-Konsole, die gdcloud CLI oder die API, um eine ProjectServiceAccount-Ressource in einem Projekt zu erstellen.

Console

Melden Sie sich in der GDC-Konsole an.
Wählen Sie im Navigationsmenü Identität und Zugriff > Dienstidentitäten aus.
Klicken Sie auf Dienstidentität erstellen. Die Seite Details zur Dienstidentität wird geöffnet.
Geben Sie im Feld Name der Dienstidentität einen Namen für Ihre Dienstidentität ein. Beispiel: testserviceidentity
Klicken Sie auf Erstellen.

gdcloud

Konto erstellen:

gdcloud iam service-accounts create NAME \
    --project=PROJECT

Ersetzen Sie die folgenden Werte:

NAME: der Name des ProjectServiceAccount. Der Name muss innerhalb des Projekt-Namespace eindeutig sein.
PROJECT: das Projekt, in dem die Dienstidentität erstellt werden soll. Wenn gdcloud init bereits festgelegt ist, lassen Sie das Flag --project weg.

Mit diesem Befehl wird ein ProjectServiceAccount im Projekt-Namespace auf dem Management API-Server erstellt.

API

Erstellen Sie eine YAML-Datei für die benutzerdefinierte Ressource ProjectServiceAccount, z. B. my-project-sa.yaml:
```
apiVersion: resourcemanager.global.gdc.goog/v1
kind: ProjectServiceAccount
metadata:
  name: NAME
  namespace: PROJECT
spec:
  keys:
  - algorithm: ALGORITHM
    id: KEY_ID
    key: BASE64_ENCODED_KEY
    validAfter: "START_TIME"
    validBefore: "EXPIRATION_TIME"
```
Ersetzen Sie die folgenden Variablen:
- NAME: der Name der ProjectServiceAccount-Ressource. Der Name muss innerhalb des Projekt-Namespace eindeutig sein.
- PROJECT: das Projekt, in dem die Dienstidentität erstellt werden soll.
- ALGORITHM: der Algorithmus des Schlüssels. Es werden nur ES256-Schlüssel unterstützt.
- KEY_ID: die eindeutige Kennung des Schlüssels. Anhand der ID wird bestimmt, mit welchem Schlüssel die Überprüfung erfolgen soll.
- BASE64_ENCODED_KEY: der base64-codierte öffentliche Schlüssel im PEM-Format, der für die Überprüfung verwendet werden soll. Der private Schlüssel, der zum Generieren dieses öffentlichen Schlüssels verwendet wird, wird im ECDSA P256 PEM-Format erwartet.
- START_TIME: die Startzeit, ab der der Schlüssel gültig ist, z. B. 2025-02-07T00:59:34Z.
- EXPIRATION_TIME: die Ablaufzeit für den Schlüssel, z. B. 2026-02-07T00:59:34Z.
Wenden Sie die benutzerdefinierte Ressource ProjectServiceAccount auf den globalen API-Server an:
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f my-project-sa.yaml
```
Ersetzen Sie die Variable GLOBAL_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei für den globalen API-Server.

Anmeldedaten erstellen

Damit sich eine Arbeitslast oder Anwendung als Dienstidentität (repräsentiert durch das von Ihnen erstellte Konto) authentifizieren kann, müssen Sie Anmeldedaten generieren. Zum Erstellen von Anmeldedaten wird ein kryptografisches Schlüsselpaar aus privatem und öffentlichem Schlüssel generiert und der öffentliche Schlüssel mit der Dienstidentität verknüpft.

Verwenden Sie die GDC-Konsole, die gdcloud CLI oder die API, um Anmeldedaten für eine Dienstidentität zu erstellen.

Console

Melden Sie sich in der GDC-Konsole an.
Wählen Sie im Navigationsmenü Identität und Zugriff > Dienstidentitäten aus.
Klicken Sie auf den Namen der Dienstidentität, die Sie dem Schlüssel hinzufügen möchten.
Klicken Sie auf Neuen Schlüssel erstellen.
Der neue Schlüssel wird in der Liste Schlüssel angezeigt und in einem Dialogfeld wird bestätigt, dass der Schlüssel erstellt wurde.

gdcloud

Mit dem Befehl gdcloud wird eine JSON-Datei mit Standardanmeldedaten für Anwendungen sowie ein öffentliches und privates Schlüsselpaar erstellt:

gdcloud iam service-accounts keys create APPLICATION_DEFAULT_CREDENTIALS_FILENAME \
    --project=PROJECT \
    --iam-account=NAME \
    --ca-cert-path=CA_CERTIFICATE_PATH

Ersetzen Sie die folgenden Werte:

APPLICATION_DEFAULT_CREDENTIALS_FILENAME: der Name der JSON-Datei.
PROJECT : Wählt das Projekt aus, für das der Schlüssel erstellt werden soll. Wenn gdcloud init bereits festgelegt ist, können Sie das Flag --project weglassen.
NAME: der Name der Dienstidentität, für die der Schlüssel hinzugefügt werden soll.
CA_CERTIFICATE_PATH (optional): Der Pfad des Zertifikats der Zertifizierungsstelle (Certificate Authority, CA) zur Überprüfung des Authentifizierungsendpunkts. Wenn Sie diesen Pfad nicht angeben, werden die CA-Zertifikate des Systems verwendet. Sie müssen die Zertifizierungsstelle in den System-CA-Zertifikaten installieren.

Distributed Cloud fügt den öffentlichen Schlüssel zu den ProjectServiceAccount-Schlüsseln hinzu, mit denen Sie die JSON Web Tokens (JWT) verifizieren, die mit dem privaten Schlüssel signiert werden. Der private Schlüssel wird in die JSON-Datei mit den Standardanmeldedaten für Anwendungen geschrieben.

Das folgende Beispiel zeigt die JSON-Datei mit den Standardanmeldedaten für Anwendungen:

{
"type": "gdch_service_account",
"format_version": "1",
"project": "project_name",
"private_key_id": "abcdef1234567890",
"private_key": "-----BEGIN PRIVATE KEY-----\nETC\n-----END PRIVATE KEY-----\n",
"name": "service_identity_name",
"ca_cert_path": "/path/to/ca.crt",
"token_uri": "https://service-identity.<Domain>/authenticate"
}

In diesem Beispiel werden die folgenden Werte verwendet:

project: der Projekt-Namespace in der Organisation.
private_key_id: die dem Schlüssel zugewiesene ID.
private_key: der private ECDSA P256-Schlüssel im PEM-Format, der von der Befehlszeile generiert wird.
name: der Name der Dienstidentität.
ca_cert_path: der Pfad zum Zertifikat der Zertifizierungsstelle (CA), das zur Überprüfung des Authentifizierungsendpunkts verwendet wird.
token_uri: die Adresse des Authentifizierungsendpunkts.

API

Generieren Sie das öffentliche und private Schlüsselpaar. In den folgenden Befehlen wird openssl als Beispiel verwendet, ein gängiges Tool für diesen Zweck.
```
openssl ecparam -name prime256v1 -genkey -noout -out "key.pem"
openssl ec -in "key.pem" -pubout > "pub.pem"
```

Codieren Sie den öffentlichen Schlüssel mit Base64 und rufen Sie seine Schlüssel-ID ab:

KEY_ID=$(openssl pkey -in key.pem -pubout -outform der | openssl dgst -sha256 | sed 's/^.* //')
BASE64_ENCODED_KEY=$(cat pub.pem | base64)

Erstellen oder aktualisieren Sie die YAML-Datei für die benutzerdefinierte Ressource ProjectServiceAccount, einschließlich der generierten Schlüsselinformationen aus dem vorherigen Schritt:
```
apiVersion: resourcemanager.global.gdc.goog/v1
kind: ProjectServiceAccount
metadata:
  name: NAME
  namespace: PROJECT
spec:
  keys:
  - algorithm: ALGORITHM
    id: KEY_ID
    key: BASE64_ENCODED_KEY
    validAfter: "START_TIME"
    validBefore: "EXPIRATION_TIME"
```
Ersetzen Sie die folgenden Variablen:
- NAME: der Name der ProjectServiceAccount-Ressource. Der Name muss innerhalb des Projekt-Namespace eindeutig sein.
- PROJECT: das Projekt, in dem Sie den Schlüssel erstellen.
- ALGORITHM: der Algorithmus des Schlüssels. Es werden nur ES256-Schlüssel unterstützt.
- KEY_ID: die eindeutige Kennung des Schlüssels. Anhand der ID wird bestimmt, mit welchem Schlüssel die Überprüfung erfolgen soll.
- BASE64_ENCODED_KEY: der base64-codierte öffentliche Schlüssel im PEM-Format, der für die Überprüfung verwendet werden soll. Der private Schlüssel, der zum Generieren dieses öffentlichen Schlüssels verwendet wird, wird im ECDSA P256 PEM-Format erwartet.
- START_TIME: die Startzeit, ab der der Schlüssel gültig ist, z. B. 2025-02-07T00:59:34Z.
- EXPIRATION_TIME: die Ablaufzeit für den Schlüssel, z. B. 2026-02-07T00:59:34Z.
Wenden Sie die benutzerdefinierte Ressource ProjectServiceAccount auf den globalen API-Server an:
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f my-project-sa.yaml
```
Ersetzen Sie die Variable GLOBAL_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei für den globalen API-Server.
Erstellen Sie die JSON-Datei mit den Standardanmeldedaten für Anwendungen, die den privaten Schlüssel enthält. Achten Sie darauf, dass die Variable KEY_ID in der JSON-Datei auf denselben Wert wie die Variable KEY_ID festgelegt ist, die Sie in der Spezifikation ProjectServiceAccount verwendet haben.
```
cat <<EOF > "key_file.json"
{
  "format_version": "1",
  "name": "NAME",
  "private_key": "$(tr '\n' '\t' < "key.pem" | sed 's/\t/\\n/g')",
  "private_key_id": "KEY_ID",
  "project": "PROJECT",
  "token_uri": "AUTH_URL",
  "type": "gdch_service_account"
}
EOF
```
Ersetzen Sie die folgenden Variablen:
- NAME: der Name der Dienstidentität.
- KEY_ID: die eindeutige Kennung des Schlüssels. Anhand der ID wird bestimmt, mit welchem Schlüssel die Überprüfung erfolgen soll. Sie muss mit dem Wert KEY_ID übereinstimmen, der in der ProjectServiceAccount-Spezifikation verwendet wird.
- PROJECT: der Projekt-Namespace in der Organisation.
- AUTH_URL: die Adresse des Authentifizierungsendpunkts.

Weitere Informationen zur Verwendung der generierten Schlüsseldatei für die Authentifizierung als diese Dienstidentität finden Sie unter Dienstidentität authentifizieren und verwenden. In diesem Abschnitt wird die Verwendung des Schlüssels mit der gdcloud CLI und programmatisch mit Clientbibliotheken beschrieben.

Dienstidentitäten ansehen

In diesem Abschnitt wird beschrieben, wie Sie Ihre Dienstidentitäten und die zugehörigen öffentlichen Schlüssel aufrufen.

Liste der Dienstidentitäten ansehen

Verwenden Sie die GDC-Konsole oder die gdcloud CLI, um eine Liste der Dienstidentitäten in einem Projekt aufzurufen.

Console

Melden Sie sich in der GDC-Konsole an.
Wählen Sie ein Projekt aus.
Klicken Sie im Navigationsmenü auf Identität und Zugriff > Dienstidentitäten, um die Liste der Dienstidentitäten für das Projekt aufzurufen.

gdcloud

Listen Sie die Dienstidentitätskonten in einem Projekt auf:

gdcloud iam service-accounts list \
    --project=PROJECT

Ersetzen Sie PROJECT durch die Projekt-ID.

Liste der öffentlichen Schlüssel für eine Dienstidentität aufrufen

Listen Sie die öffentlichen Schlüssel auf, die für ein Dienstidentitätskonto im Projekt registriert sind:

gdcloud iam service-accounts keys list \
    --project=PROJECT \
    --iam-account=NAME

Ersetzen Sie Folgendes:

PROJECT: Projekt-ID.
NAME: der Name des zu verwendenden Dienstidentitätskontos.

Berechtigungen für Dienstidentitäten gewähren

Wenn Sie einer Dienstidentität Berechtigungen gewähren möchten, weisen Sie ihr eine oder mehrere Rollen zu. Erstellen Sie dazu Rollenbindungen mit der GDC-Konsole oder der gdcloud CLI.

Console

Melden Sie sich in der GDC-Konsole an.
Wählen Sie ein Projekt aus.
Wählen Sie im Navigationsmenü Identität und Zugriff > Zugriff aus.
Klicken Sie in der Liste Mitglied auf Mitglied hinzufügen. Die Seite Nutzer und Rollen wird angezeigt.
Wählen Sie in der Liste Mitgliedstyp die Option Dienstidentität aus.
Wählen Sie in der Liste Dienstidentität die Dienstidentität aus, der Sie eine Rollenbindung zuweisen möchten.
Wählen Sie in der Liste Rolle die Rolle aus, die Sie der Dienstidentität zuweisen möchten, z. B. Backup Creator.
Optional: Klicken Sie auf Weitere Rolle hinzufügen, um eine weitere Rolle hinzuzufügen. Wählen Sie die zusätzliche Rolle aus.
Klicken Sie auf Hinzufügen.

gdcloud

Sie können das Dienstidentitätskonto an Rollen im Projekt-Namespace oder an Rollen in einem anderen Namespace binden.

Binden Sie das Konto an eine Rolle im Projekt-Namespace:
```
gdcloud iam service-accounts add-iam-policy-binding \
    --project=PROJECT \
    --role=ROLE \
    --iam-account=NAME
```
Ersetzen Sie Folgendes:
- PROJECT: das Projekt, in dem die Rollenbindung erstellt werden soll. Wenn gdcloud init bereits festgelegt ist, können Sie das Flag --project weglassen.
- ROLE: die vordefinierte Rolle, die dem Konto zugewiesen werden soll. Geben Sie Rollen im Format Role/name an, wobei Role der Kubernetes-Typ IAMRole und name der Name der vordefinierten Rolle ist. Wenn Sie beispielsweise die Rolle „Project Viewer“ zuweisen möchten, legen Sie die Rolle auf IAMRole/project-viewer fest.
- NAME: der Name des zu verwendenden Dienstidentitätskontos.
Binden Sie das Konto an eine Rolle in einem anderen Namespace:
```
gdcloud iam service-accounts add-iam-policy-binding \
    --role=ROLE \
    --role-namespace=ROLE_NAMESPACE \
    --iam-account=NAME
```
Ersetzen Sie Folgendes:
- ROLE: die vordefinierte Rolle, die dem Konto zugewiesen werden soll. Geben Sie Rollen im Format Role/name an, wobei Role der Kubernetes-Typ IAMRole und name der Name der vordefinierten Rolle ist. Wenn Sie beispielsweise die Rolle „Project Viewer“ zuweisen möchten, legen Sie die Rolle auf IAMRole/project-viewer fest.
- ROLE_NAMESPACE: der Namespace der Rolle, die an das Konto gebunden werden soll, mit Ausnahme des Projekt-Namespace.
- NAME: der Name des zu verwendenden Dienstidentitätskontos.

Dienstidentität authentifizieren und verwenden

Nachdem Sie eine Dienstidentität erstellt und die zugehörige Schlüsseldatei generiert haben, können Sie die Schlüsseldatei verwenden, um sich bei GDC-Diensten und -Clustern zu authentifizieren. Durch die Authentifizierung können Sie kurzlebige Zugriffstokens für API-Aufrufe abrufen oder den Clusterzugriff konfigurieren.

Es gibt zwei Möglichkeiten, sich mit einer Dienstidentität zu authentifizieren:

Mit der gdcloud CLI authentifizieren
Programmatisch mit Clientbibliotheken authentifizieren

Mit der gdcloud CLI authentifizieren

Wenn Sie Aktionen mit der Dienstidentität ausführen möchten, müssen Sie zuerst die zugehörige Schlüsseldatei aktivieren. Nach der Aktivierung können Sie die gdcloud CLI verwenden, um Tokens abzurufen oder kubeconfig-Dateien zu generieren.

Dienstidentität mit einem Schlüssel autorisieren

Mit dem Befehl gdcloud auth activate-service-account wird die gdcloud CLI mit einer Dienstidentität authentifiziert. So können Sie Aktionen für Distributed Cloud-Ressourcen mit den Berechtigungen des Dienstidentitätskontos anstelle eines Nutzerkontos ausführen.

Dienstidentität mit einem Schlüssel autorisieren:

Erstellen Sie eine Schlüsseldatei für Anmeldedaten, falls Sie noch keine haben.
Aktivieren Sie die Dienstidentität mit dem folgenden Befehl:
```
gdcloud auth activate-service-account --key-file=KEY_FILE
```
Ersetzen Sie KEY_FILE durch den Pfad zur Schlüsseldatei für die Anmeldedaten, die normalerweise im JSON-Format vorliegt.

Nach erfolgreicher Aktivierung verwendet gdcloud die Anmeldedaten der Dienstidentität anstelle Ihrer Nutzeranmeldedaten.

Zugriffstoken mit der gdcloud CLI abrufen

Nachdem Sie eine Dienstidentität autorisiert haben, können Sie mit gdcloud ein Zugriffstoken ausgeben. Sie können dieses Token als Inhabertoken verwenden, um HTTP-Anfragen zu authentifizieren. Das Token gewährt Zugriff auf Dienste, wie im Parameter AUDIENCES definiert.

Geben Sie ein Identitätstoken für das angegebene Dienstidentitätskonto aus:

gdcloud auth print-identity-token --audiences=AUDIENCES

Ersetzen Sie AUDIENCES durch den vorgesehenen Empfänger oder Dienst, für den das Token bestimmt ist. Es kann nur eine Zielgruppe angegeben werden.

kubeconfig-Datei generieren

Nachdem Sie eine Dienstidentität autorisiert haben, können Sie eine kubeconfig-Datei generieren, um sich bei Kubernetes-Clustern zu authentifizieren.

Legen Sie das gdcloud-Attribut core/organization_console_url fest:
```
gdcloud config set core/organization_console_url
https://GDC_URL
```
Ersetzen Sie GDC_URL durch die URL Ihrer Organisation.
Generieren Sie die kubeconfig-Datei, um mit der aktiven Dienstidentität auf einen Cluster zuzugreifen:
- Für einen zonalen Cluster:
```
export KUBECONFIG=KUBECONFIG_PATH
gdcloud clusters get-credentials CLUSTER_NAME --zone ZONE
```
  Ersetzen Sie Folgendes:
  - KUBECONFIG_PATH: Der Pfad, unter dem Sie die generierte kubeconfig-Datei speichern möchten.
  - CLUSTER_NAME: der Name des zonalen Clusters.
    
    Hinweis: Die Liste der Clusternamen ist in der URL der Anmeldekonfiguration verfügbar:
    https://GDC_URL/.well-known/login-config.
  - ZONE: der Name der Zone, in der sich der Cluster befindet.
- Für den globalen API-Server:
```
export KUBECONFIG=KUBECONFIG_PATH
gdcloud clusters get-credentials global-api
```
  Ersetzen Sie KUBECONFIG_PATH durch den Pfad, unter dem Sie die generierte kubeconfig-Datei speichern möchten.

Es wird eine kubeconfig-Datei generiert, die für die Authentifizierung als Dienstidentität konfiguriert ist. Im Folgenden finden Sie ein Beispiel für eine YAML-Datei:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <REDACTED>
    server: <REDACTED>
  name: cluster-name
contexts:
- context:
    cluster: cluster-name
    user: gdch_console-<REDACTED>_cluster-name
  name: cluster-name-gdch_console-<REDACTED>_cluster-name
current-context: cluster-name-gdch_console-gdc1-staging-gpcdemolabs-com_cluster-name
kind: Config
preferences: {}
users:
- name: gdch_console-<REDACTED>_cluster-name
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - --audience=<REDACTED>
      command: gdcloud-k8s-auth-plugin
      env: null
      installHint: Run 'gdcloud components install gdcloud-k8s-auth-plugin' to use
        plugin
      interactiveMode: Never
      provideClusterInfo: false

Programmatisch mit Clientbibliotheken authentifizieren

In den folgenden Beispielen wird gezeigt, wie Sie sich mithilfe der standardmäßigen Google Cloud-Clientbibliotheken programmatisch bei GDC APIs authentifizieren. Diese Bibliotheken verwenden die generierte Dienstkontoschlüsseldatei, um entweder ein Security Token Service-Zugriffstoken (STS) zu generieren oder einen Dienstclient mit den Anmeldedaten der Dienstidentität zu konfigurieren. Für diese Methode ist keine vorherige gdcloud-Autorisierung erforderlich.

Python

import google.auth
from google.auth.transport import requests
import requests as reqs

api_endpoint = "https://console.org-1.zone1.google.gdch.test"

# Load the GDC credentials (via GOOGLE_APPLICATION_CREDENTIALS or default path)
creds, project_id = google.auth.default()

# Apply the required audience for the GDC Management API
creds = creds.with_gdch_audience(api_endpoint)

def fetch_gdch_token():
    sesh = reqs.Session()
    # Note: Set verify to False only if bypassing self-signed cert verification.
    # Otherwise, rely on the "ca_cert_path" present in your gdch_credentials.json
    sesh.verify = False
    req = requests.Request(session=sesh)

    # Refresh the credentials to fetch the STS access token
    creds.refresh(req)

    print("Access Token:", creds.token)

fetch_gdch_token()

Java

import com.google.auth.oauth2.GdchCredentials;
import com.google.auth.oauth2.GoogleCredentials;

import java.io.FileInputStream;
import java.io.InputStream;

public class GdchAuthExample {
    public static void main(String[] args) throws Exception {
        // Path to your service account JSON file
        String credentialsPath = "/path/to/gdch/credentials.json";
        String apiAudience = "https://console.org-1.zone1.google.gdch.test";

        try (InputStream credentialsStream = new FileInputStream(credentialsPath)) {
            // Load the generic Google credentials from the stream
            GoogleCredentials credentials = GoogleCredentials.fromStream(credentialsStream);

            // Verify it loaded as GdchCredentials
            if (credentials instanceof GdchCredentials) {
                // Cast and attach the targeted GDC audience
                GdchCredentials gdch = ((GdchCredentials) credentials).createWithGdchAudience(apiAudience);

                // Force negotiation with the GDC Auth Server to fetch the token
                gdch.refreshIfExpired();

                System.out.println("Access Token: " + gdch.getAccessToken().getTokenValue());
            } else {
                System.err.println("The provided file is not a valid GdchCredentials format.");
            }
        }
    }
}

Go

package main

import (
  "context"
  "fmt"
  "log"

  "cloud.google.com/go/auth/credentials"
)

func main() {
  ctx := context.Background()
  apiEndpoint := "https://console.org-1.zone1.google.gdch.test"

  // Load default credentials. The STSAudience parameter is specifically
  // required for the GDC auth flow to correctly negotiate the token.
  creds, err := credentials.DetectDefault(&credentials.DetectOptions{
    STSAudience: apiEndpoint,
  })
  if err != nil {
    log.Fatalf("Failed to detect credentials: %v", err)
  }

  // Fetch an access token
  token, err := creds.Token(ctx)
  if err != nil {
    log.Fatalf("Failed to retrieve token: %v", err)
  }

  fmt.Printf("Access Token: %s\n", token.Value)
}

C++

[](std::string const& keyfile, std::string const& audience) {
  auto is = std::ifstream(keyfile);
  is.exceptions(std::ios::badbit);  // Minimal error handling in examples
  auto contents = std::string(std::istreambuf_iterator<char>(is.rdbuf()), {});
  auto options =
      google::cloud::Options{}.set<google::cloud::UnifiedCredentialsOption>(
          google::cloud::MakeGDCHServiceAccountCredentials(contents, audience));
  return google::cloud::speech_v1::AdaptationClient(
      google::cloud::speech_v1::MakeAdaptationConnection(options));
}

Dienstidentität löschen

Nachdem Sie eine Dienstidentität gelöscht haben, werden die ProjectServiceAccount und die zugehörigen öffentlichen Schlüssel gelöscht, vorhandene private Schlüssel werden ungültig und Anwendungen haben über diese Dienstidentität keinen Zugriff mehr auf Projektressourcen.

Verwenden Sie zum Löschen einer Dienstidentität die GDC-Konsole oder die gdcloud CLI.

Console

Melden Sie sich in der GDC-Konsole an.
Wählen Sie im Navigationsmenü Identität und Zugriff > Dienstidentitäten aus.
Klicken Sie auf das Kästchen neben der Dienstidentität, die Sie löschen möchten.
Klicken Sie auf Löschen.
Das Bestätigungsdialogfeld wird angezeigt. Geben Sie im Feld Bestätigen Sie den Vorgang, indem Sie Folgendes eingeben den Wert remove ein.
Klicken Sie auf Löschen.

gdcloud

Führen Sie den folgenden Befehl aus, um ein Dienstidentitätskonto zu löschen:

gdcloud iam service-accounts delete NAME \
    --project=PROJECT

Ersetzen Sie Folgendes:

NAME: der Name des zu löschenden Dienstidentitätskontos.
PROJECT: Projekt-ID.

Anmeldedaten löschen

Wenn Sie ein bestimmtes Schlüsselpaar deaktivieren möchten, ohne das gesamte Dienstidentitätskonto zu löschen, können Sie den öffentlichen Schlüssel aus dem Dienstidentitätskonto löschen. Durch diese Aktion wird der entsprechende private Schlüssel ungültig.

Verwenden Sie zum Löschen des öffentlichen Schlüssels die GDC-Konsole oder die gdcloud CLI.

Console

Melden Sie sich in der GDC-Konsole an.
Wählen Sie im Navigationsmenü Identität und Zugriff > Dienstidentitäten aus.
Klicken Sie auf den Namen der Dienstidentität, die den Schlüssel enthält, den Sie löschen möchten.
Klicken Sie auf Löschen.
Klicken Sie im Bestätigungsdialogfeld auf Löschen.

gdcloud

Entfernen Sie den öffentlichen Schlüssel mit der Schlüssel-ID aus einem Dienstidentitätskonto im Projekt:

gdcloud iam service-accounts keys delete KEY_ID \
    --project=PROJECT \
    --iam-account=NAME

Ersetzen Sie Folgendes:

KEY_ID: die eindeutige Kennung des Schlüssels.
PROJECT: Projekt-ID.
NAME: der Name des Dienstidentitätskontos.

Mit Dienstidentitäten authentifizieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweis

IAM-Rollen anfordern

Umgebung vorbereiten

Dienstidentität erstellen

Konto erstellen

Console

gdcloud

API

Anmeldedaten erstellen

Console

gdcloud

API

Dienstidentitäten ansehen

Liste der Dienstidentitäten ansehen

Console

gdcloud

Liste der öffentlichen Schlüssel für eine Dienstidentität aufrufen

Berechtigungen für Dienstidentitäten gewähren

Console

gdcloud

Dienstidentität authentifizieren und verwenden

Mit der gdcloud CLI authentifizieren

Dienstidentität mit einem Schlüssel autorisieren

Zugriffstoken mit der gdcloud CLI abrufen

kubeconfig-Datei generieren

Programmatisch mit Clientbibliotheken authentifizieren

Python

Java

Go

C++

Dienstidentität löschen

Console

gdcloud

Anmeldedaten löschen

Console

gdcloud

Mit Dienstidentitäten authentifizieren