Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

S'authentifier avec des identités de service

Une identité de service dans Google Distributed Cloud (GDC) avec isolation physique fournit une identité dédiée aux charges de travail ou aux services pour accéder de manière programmatique aux ressources et aux microservices de manière sécurisée. Il s'agit d'identités spéciales utilisées par des applications ou des charges de travail, et non par une personne. Elles ne peuvent pas être utilisées pour la connexion humaine. Comme pour les comptes utilisateur, vous accordez des autorisations et des rôles à une identité de service pour définir ce à quoi elle est autorisée à accéder.

Vous remarquerez peut-être que deux termes sont utilisés pour ce concept. La console GDC utilise principalement le terme "identité de service", tandis que les commandes gdcloud et les interactions avec l'API utilisent souvent le terme "compte de service". Ce dernier reflète le nom de la ressource personnalisée Kubernetes sous-jacente, ProjectServiceAccount. Les deux termes désignent la même chose : l'identité non humaine de vos charges de travail. Ce document utilise l'identité de service comme terme principal.

Les identités de service sont utiles pour gérer l'infrastructure GDC, par exemple :

Services et charges de travail Distributed Cloud internes pour accéder de manière sécurisée à l'interface de programmation d'application (API) du plan de contrôle Distributed Cloud. Par exemple, les services de base de données interagissent avec les API Kubernetes pour créer et supprimer des bases de données.
Les charges de travail client dans Distributed Cloud pour accéder aux services Distributed Cloud et effectuer des appels d'API (interface de programmation d'application) autorisés. Par exemple, les identités de service peuvent gérer un client qui utilise un notebook Vertex AI Workbench pour transcrire des fichiers audio à l'aide de l'API Speech-to-Text.
Charges de travail externes à fédérer avec Distributed Cloud. Par exemple, les identités de service peuvent gérer une application externe à Distributed Cloud qui numérise des documents, mais qui souhaite utiliser l'API Optical Character Recognition (OCR) pour remplacer son moteur d'OCR actuel.
Les services ou les contrôleurs système Distributed Cloud pour accéder de manière sécurisée aux ressources client ou aux clusters d'utilisateur. Par exemple, les identités de service peuvent gérer les workflows d'authentification et d'autorisation lorsque les contrôleurs de service exécutés dans les clusters d'administrateur doivent exécuter des charges de travail dans les clusters d'utilisateur gérés par les clients.

La gestion des identités de service implique à la fois l'identité de service (représentée par une ressource ProjectServiceAccount) et ses identifiants associés (paires de clés publique et privée). Vous pouvez gérer les comptes des identités de service à l'aide de la console GDC, de la CLI gdcloud ou de l'API. Avec la CLI gdcloud, la fonctionnalité d'identité de service est basée sur l'API globale ProjectServiceAccount. Étant donné que les ressources ProjectServiceAccount sont configurées de manière globale, elles fonctionnent dans toutes les zones de votre univers gdcloud.

Avant de commencer

Pour effectuer les tâches décrites dans ce document, vous devez disposer d'un projet. Pour savoir comment créer un projet, consultez Créer un projet.

Vous devez également disposer des autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Pour créer, mettre à jour et supprimer des identités de service dans un projet, contactez votre administrateur IAM de l'organisation ou votre administrateur IAM de projet pour demander le rôle Administrateur IAM de projet (project-iam-admin).

L'administrateur de l'organisation IAM peut attribuer ce rôle pour n'importe quel projet de l'organisation. L'administrateur de projet IAM peut accorder ce rôle dans le cadre de son projet spécifique.

Préparer votre environnement

Pour utiliser les outils de ligne de commande afin de gérer les identités de service, effectuez la configuration suivante :

Téléchargez et installez la CLI gdcloud, si ce n'est pas déjà fait.
Pour utiliser l'API avec kubectl, une configuration supplémentaire est requise :
- Installez la CLI kubectl.
- Générez le fichier kubeconfig pour le serveur d'API global afin de configurer l'accès à kubectl.

Créer une identité de service

La création d'une identité de service inclut la création d'un compte et des identifiants associés.

Créer un compte

Pour créer un compte pour une identité de service, utilisez la console GDC, la CLI gdcloud ou l'API pour créer une ressource ProjectServiceAccount dans un projet.

Console

Connectez-vous à la console GDC.
Dans le menu de navigation, sélectionnez Identité et accès > Identités de service.
Cliquez sur Créer une identité de service. La page Détails de l'identité du service s'ouvre.
Dans le champ Nom de l'identité de service, saisissez un nom pour votre identité de service. Exemple : testserviceidentity.
Cliquez sur Créer.

gdcloud

Créez un compte :

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

Remplacez les valeurs suivantes :

NAME : nom du ProjectServiceAccount. Le nom doit être unique dans l'espace de noms du projet.
PROJECT : projet dans lequel créer l'identité de service. Si gdcloud init est déjà défini, omettez l'option --project.

Cette commande crée un ProjectServiceAccount dans l'espace de noms du projet sur le serveur d'API Management.

API

Créez un fichier YAML de ressource personnalisée ProjectServiceAccount, tel que 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"
```
Remplacez les variables suivantes :
- NAME : nom de la ressource ProjectServiceAccount. Le nom doit être unique dans l'espace de noms du projet.
- PROJECT : projet dans lequel créer l'identité de service.
- ALGORITHM : algorithme de la clé. Seules les clés ES256 sont acceptées.
- KEY_ID : identifiant unique de la clé. L'ID permet de déterminer la clé à utiliser pour la vérification.
- BASE64_ENCODED_KEY : clé publique encodée en base64 au format PEM à utiliser pour la validation. La clé privée utilisée pour générer cette clé publique doit être au format ECDSA P256 PEM.
- START_TIME : heure de début à laquelle la clé devient valide, par exemple 2025-02-07T00:59:34Z.
- EXPIRATION_TIME : date d'expiration de la clé, par exemple 2026-02-07T00:59:34Z.
Appliquez la ressource personnalisée ProjectServiceAccount au serveur d'API global :
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f my-project-sa.yaml
```
Remplacez la variable GLOBAL_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur d'API global.

Créer des identifiants

Pour permettre à une charge de travail ou à une application de s'authentifier en tant qu'identité de service (représentée par le compte que vous avez créé), vous devez générer des identifiants. La création d'identifiants implique de générer une paire de clés cryptographiques privée et publique, et d'associer la clé publique à l'identité du service.

Pour créer des identifiants pour une identité de service, utilisez la console GDC, la CLI gdcloud ou l'API.

Console

Connectez-vous à la console GDC.
Dans le menu de navigation, sélectionnez Identité et accès > Identités de service.
Cliquez sur le nom de l'identité de service que vous souhaitez ajouter à la clé.
Cliquez sur Créer une clé.
La nouvelle clé apparaît dans la liste Clés, et une boîte de dialogue confirme que vous l'avez bien créée.

gdcloud

La commande gdcloud crée un fichier JSON d'identifiants par défaut de l'application, ainsi qu'une paire de clés publique et privée :

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

Remplacez les valeurs suivantes :

APPLICATION_DEFAULT_CREDENTIALS_FILENAME : nom du fichier JSON.
PROJECT : sélectionne le projet pour lequel créer la clé. Si gdcloud init est déjà défini, vous pouvez omettre l'option --project.
NAME : nom de l'identité de service à laquelle ajouter la clé.
CA_CERTIFICATE_PATH : (facultatif) chemin d'accès au certificat de l'autorité de certification (CA) pour valider le point de terminaison d'authentification. Si vous ne spécifiez pas ce chemin d'accès, les certificats CA du système sont utilisés. Vous devez installer l'autorité de certification dans les certificats CA du système.

Distributed Cloud ajoute la clé publique aux clés ProjectServiceAccount que vous utilisez pour valider les jetons Web JSON (JWT) signés par la clé privée. La clé privée est écrite dans le fichier JSON des identifiants par défaut de l'application.

L'exemple suivant montre le fichier JSON des identifiants par défaut de l'application :

{
"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"
}

Cet exemple utilise les valeurs suivantes :

project : espace de noms du projet dans l'organisation.
private_key_id : ID attribué à la clé.
private_key : clé privée ECDSA P256 au format PEM générée par la CLI.
name : nom de l'identité de service.
ca_cert_path : chemin d'accès au certificat de l'autorité de certification (CA) utilisé pour valider le point de terminaison d'authentification.
token_uri : adresse du point de terminaison d'authentification.

API

Générez la paire de clés publique et privée. Les commandes suivantes utilisent openssl comme exemple, qui est un outil courant à cet effet.
```
openssl ecparam -name prime256v1 -genkey -noout -out "key.pem"
openssl ec -in "key.pem" -pubout > "pub.pem"
```

Encodez la clé publique en base64 et récupérez son ID de clé :

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

Créez ou mettez à jour le fichier YAML de la ressource personnalisée ProjectServiceAccount, en incluant les informations de clé générées à l'étape précédente :
```
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"
```
Remplacez les variables suivantes :
- NAME : nom de la ressource ProjectServiceAccount. Le nom doit être unique dans l'espace de noms du projet.
- PROJECT : projet dans lequel vous créez la clé.
- ALGORITHM : algorithme de la clé. Seules les clés ES256 sont acceptées.
- KEY_ID : identifiant unique de la clé. L'ID permet de déterminer la clé à utiliser pour la vérification.
- BASE64_ENCODED_KEY : clé publique encodée en base64 au format PEM à utiliser pour la validation. La clé privée utilisée pour générer cette clé publique doit être au format ECDSA P256 PEM.
- START_TIME : heure de début à laquelle la clé devient valide, par exemple 2025-02-07T00:59:34Z.
- EXPIRATION_TIME : date d'expiration de la clé, par exemple 2026-02-07T00:59:34Z.
Appliquez la ressource personnalisée ProjectServiceAccount au serveur d'API global :
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f my-project-sa.yaml
```
Remplacez la variable GLOBAL_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur d'API global.
Créez le fichier JSON des identifiants par défaut de l'application contenant la clé privée. Assurez-vous que la variable KEY_ID du fichier JSON est définie sur la même valeur que la variable KEY_ID que vous avez utilisée dans la spécification ProjectServiceAccount.
```
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
```
Remplacez les variables suivantes :
- NAME : nom de l'identité de service.
- KEY_ID : identifiant unique de la clé. L'ID permet de déterminer la clé à vérifier et doit correspondre à la valeur KEY_ID utilisée dans la spécification ProjectServiceAccount.
- PROJECT : espace de noms du projet dans l'organisation.
- AUTH_URL : adresse du point de terminaison d'authentification.

Pour savoir comment utiliser le fichier de clé généré pour vous authentifier en tant qu'identité de service, consultez S'authentifier et utiliser une identité de service. Cette section explique comment utiliser la clé avec la CLI gdcloud et de manière programmatique avec les bibliothèques clientes.

Afficher les identités de service

Cette section explique comment afficher vos identités de service et leurs clés publiques associées.

Afficher la liste des identités de service

Pour afficher la liste des identités de service d'un projet, utilisez la console GDC ou la CLI gdcloud.

Console

Connectez-vous à la console GDC.
Sélectionnez un projet.
Dans le menu de navigation, cliquez sur Identité et accès > Identités de service pour afficher la liste des identités de service du projet.

gdcloud

Répertoriez les comptes d'identité de service d'un projet :

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

Remplacez PROJECT par l'ID du projet.

Afficher la liste des clés publiques d'une identité de service

Répertoriez les clés publiques enregistrées avec un compte d'identité de service dans le projet :

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

Remplacez les éléments suivants :

PROJECT : ID du projet.
NAME : nom du compte d'identité de service à utiliser.

Accorder des autorisations pour les identités de service

Pour accorder des autorisations à une identité de service, attribuez-lui un ou plusieurs rôles en créant des liaisons de rôles à l'aide de la console GDC ou de la CLI gdcloud.

Console

Connectez-vous à la console GDC.
Sélectionnez un projet.
Dans le menu de navigation, sélectionnez Identité et accès > Accès.
Dans la liste Membre, cliquez sur Ajouter un membre. La page Utilisateurs et rôles s'affiche.
Sélectionnez Identité du service dans la liste Type de membre.
Dans la liste Identité du service, sélectionnez l'identité du service à laquelle vous souhaitez attribuer une liaison de rôle.
Dans la liste Rôle, sélectionnez le rôle que vous souhaitez attribuer à l'identité de service, par exemple Créateur de sauvegardes.
Facultatif : Pour ajouter un autre rôle, cliquez sur Ajouter un autre rôle. Sélectionnez le rôle supplémentaire.
Cliquez sur Ajouter.

gdcloud

Vous pouvez lier le compte d'identité de service à des rôles dans l'espace de noms du projet ou à des rôles dans un autre espace de noms.

Liez le compte à un rôle dans l'espace de noms du projet :
```
gdcloud iam service-accounts add-iam-policy-binding \
    --project=PROJECT \
    --role=ROLE \
    --iam-account=NAME
```
Remplacez les éléments suivants :
- PROJECT : projet dans lequel créer la liaison de rôle. Si gdcloud init est déjà défini, vous pouvez omettre l'option --project.
- ROLE : rôle prédéfini à attribuer au compte. Spécifiez les rôles au format Role/name, où Role est le type Kubernetes IAMRole et name est le nom du rôle prédéfini. Par exemple, pour attribuer le rôle "Lecteur de projet", définissez le rôle sur IAMRole/project-viewer.
- NAME : nom du compte d'identité de service à utiliser.
Liez le compte à un rôle dans un autre espace de noms :
```
gdcloud iam service-accounts add-iam-policy-binding \
    --role=ROLE \
    --role-namespace=ROLE_NAMESPACE \
    --iam-account=NAME
```
Remplacez les éléments suivants :
- ROLE : rôle prédéfini à attribuer au compte. Spécifiez les rôles au format Role/name, où Role est le type Kubernetes IAMRole et name est le nom du rôle prédéfini. Par exemple, pour attribuer le rôle "Lecteur de projet", définissez le rôle sur IAMRole/project-viewer.
- ROLE_NAMESPACE : espace de noms du rôle à lier au compte autre que l'espace de noms du projet.
- NAME : nom du compte d'identité de service à utiliser.

S'authentifier et utiliser une identité de service

Après avoir créé une identité de service et généré son fichier de clé, vous pouvez utiliser ce fichier de clé pour vous authentifier auprès des services et des clusters GDC. L'authentification vous permet d'obtenir des jetons d'accès de courte durée pour les appels d'API ou de configurer l'accès au cluster.

Il existe deux façons de s'authentifier avec une identité de service :

S'authentifier avec la CLI gdcloud
S'authentifier de manière programmatique avec des bibliothèques clientes

S'authentifier avec la CLI gdcloud

Pour effectuer des actions avec l'identité du service, vous devez d'abord activer son fichier de clé. Après l'activation, vous pouvez utiliser la CLI gdcloud pour obtenir des jetons ou générer des fichiers kubeconfig.

Autoriser une identité de service à l'aide d'une clé

La commande gdcloud auth activate-service-account authentifie la CLI gdcloud avec une identité de service. Cela vous permet d'effectuer des actions sur les ressources Distributed Cloud à l'aide des autorisations du compte d'identité de service au lieu d'un compte utilisateur.

Autorisez une identité de service à l'aide d'une clé :

Créez un fichier de clé d'identifiants si vous n'en avez pas déjà un.
Activez l'identité de service en exécutant la commande suivante :
```
gdcloud auth activate-service-account --key-file=KEY_FILE
```
Remplacez KEY_FILE par le chemin d'accès au fichier de clé d'identifiants, généralement au format JSON.

Une fois l'activation réussie, gdcloud utilise les identifiants de l'identité de service au lieu de vos identifiants utilisateur.

Obtenir un jeton d'accès à l'aide de la CLI gdcloud

Après avoir autorisé une identité de service, vous pouvez utiliser gdcloud pour imprimer un jeton d'accès. Vous pouvez utiliser ce jeton comme jeton de support pour authentifier les requêtes HTTP. Le jeton accorde l'accès aux services, comme défini dans le paramètre AUDIENCES.

Imprimez un jeton d'identité pour le compte d'identité de service spécifié :

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

Remplacez AUDIENCES par le destinataire ou le service auquel le jeton est destiné. Vous ne pouvez spécifier qu'une seule audience.

Générer le fichier kubeconfig

Après avoir autorisé une identité de service, vous pouvez générer un fichier kubeconfig pour vous authentifier auprès des clusters Kubernetes.

Définissez la propriété gdcloud core/organization_console_url :
```
gdcloud config set core/organization_console_url
https://GDC_URL
```
Remplacez GDC_URL par l'URL de votre organisation.
Générez le fichier kubeconfig pour accéder à un cluster à l'aide de l'identité de service active :
- Pour un cluster zonal :
```
export KUBECONFIG=KUBECONFIG_PATH
gdcloud clusters get-credentials CLUSTER_NAME --zone ZONE
```
  Remplacez les éléments suivants :
  - KUBECONFIG_PATH : chemin d'accès où enregistrer le fichier kubeconfig généré.
  - CLUSTER_NAME : nom du cluster zonal.
    
    Remarque : La liste des noms de cluster est disponible dans l'URL de configuration de connexion :
    https://GDC_URL/.well-known/login-config.
  - ZONE : nom de la zone où se trouve le cluster.
- Pour le serveur d'API global :
```
export KUBECONFIG=KUBECONFIG_PATH
gdcloud clusters get-credentials global-api
```
  Remplacez KUBECONFIG_PATH par le chemin d'accès où vous souhaitez enregistrer le fichier kubeconfig généré.

Un fichier kubeconfig est généré et configuré pour s'authentifier en tant qu'identité de service. Voici un exemple de fichier YAML :

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

S'authentifier de manière programmatique avec des bibliothèques clientes

Les exemples suivants montrent comment s'authentifier de manière programmatique auprès des API GDC à l'aide des bibliothèques clientes Google Cloud standards. Ces bibliothèques utilisent le fichier de clé de compte de service généré pour générer un jeton d'accès Security Token Service (STS) ou configurer un client de service avec les identifiants de l'identité de service. Cette méthode ne nécessite aucune autorisation gdcloud préalable.

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));
}

Supprimer une identité de service

Après avoir supprimé une identité de service, l'ProjectServiceAccount et ses clés publiques associées sont supprimés, les clés privées existantes deviennent non valides et les applications n'ont plus accès aux ressources du projet via cette identité de service.

Pour supprimer une identité de service, utilisez la console GDC ou la CLI gdcloud.

Console

Connectez-vous à la console GDC.
Dans le menu de navigation, sélectionnez Identité et accès > Identités de service.
Cochez la case correspondant à l'identité de service que vous souhaitez supprimer.
Cliquez sur Supprimer.
La boîte de dialogue de confirmation s'affiche. Dans le champ Confirmez en saisissant ce qui suit, saisissez remove.
Cliquez sur Supprimer.

gdcloud

Exécutez la commande suivante pour supprimer un compte d'identité de service :

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

Remplacez les éléments suivants :

NAME : nom du compte d'identité de service à supprimer.
PROJECT : ID du projet.

Supprimer les identifiants

Si vous souhaitez désactiver une paire de clés spécifique sans supprimer l'intégralité du compte d'identité de service, vous pouvez supprimer sa clé publique du compte d'identité de service. Cette action invalide la clé privée correspondante.

Pour supprimer la clé publique, utilisez la console GDC ou la CLI gdcloud.

Console

Connectez-vous à la console GDC.
Dans le menu de navigation, sélectionnez Identité et accès > Identités de service.
Cliquez sur le nom de l'identité de service qui possède la clé que vous souhaitez supprimer.
Cliquez sur Supprimer.
Dans la boîte de dialogue de confirmation, cliquez sur Supprimer.

gdcloud

Supprimez la clé publique avec l'ID de clé d'un compte d'identité de service dans le projet :

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

Remplacez les éléments suivants :

KEY_ID : identifiant unique de la clé.
PROJECT : ID du projet.
NAME : nom du compte d'identité de service.

S'authentifier avec des identités de service Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Demander des rôles IAM

Préparer votre environnement

Créer une identité de service

Créer un compte

Console

gdcloud

API

Créer des identifiants

Console

gdcloud

API

Afficher les identités de service

Afficher la liste des identités de service

Console

gdcloud

Afficher la liste des clés publiques d'une identité de service

Accorder des autorisations pour les identités de service

Console

gdcloud

S'authentifier et utiliser une identité de service

S'authentifier avec la CLI gdcloud

Autoriser une identité de service à l'aide d'une clé

Obtenir un jeton d'accès à l'aide de la CLI gdcloud

Générer le fichier kubeconfig

S'authentifier de manière programmatique avec des bibliothèques clientes

Python

Java

Go

C++

Supprimer une identité de service

Console

gdcloud

Supprimer les identifiants

Console

gdcloud

S'authentifier avec des identités de service