Ce document explique comment configurer des identités de charge de travail gérées pour Google Kubernetes Engine (GKE) dans vos clusters gérés par des flottes GKE. Il explique également comment déployer une charge de travail et vérifier son identité et son certificat.
La configuration et l'utilisation des identités de charge de travail gérées pour GKE impliquent les étapes suivantes :
Pool d'identités de charge de travail géré par Google
Lorsque vous ajoutez vos clusters à des parcs GKE, les parcs créent automatiquement un pool d'identités de charge de travail géré par Google qui sert de racine à votre domaine de confiance. Le pool d'identités de charge de travail géré par Google présente les contraintes suivantes :
Google gère entièrement le pool. Vous ne pouvez donc pas créer de sous-ressources, telles que des espaces de noms, des identités ou des fournisseurs d'identité.
Le pool ne peut être utilisé que pour les charges de travail GKE. Vous ne pouvez pas ajouter d'autres types de charges de travail au pool, comme les VM Compute Engine.
Tous les clusters du pool sont soumis au modèle d'identité d'espace de noms Kubernetes standard. Cela signifie que tous les clusters du pool disposent des mêmes privilèges. Les charges de travail qui s'exécutent sur l'un des clusters du pool peuvent utiliser n'importe quelle identité du pool.
Configuration multiprojets
Les ressourcesGoogle Cloud que vous utilisez dans ce document, telles que les clusters GKE, l'autorité de certification racine et les autorités de certification subordonnées, peuvent exister dans des projets distincts. Lorsque vous faites référence à ces ressources, utilisez l'indicateur --project
pour spécifier le projet approprié pour chaque ressource.
Avant de commencer
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_ID
with a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_ID
with your Google Cloud project name.
-
Comprendre les identités de charge de travail gérées
Assurez-vous de disposer d'au moins un cluster GKE. Assurez-vous que vos clusters exécutent la version 1.33.0-gke.2248000 ou ultérieure.
Ajoutez vos clusters aux flottes GKE. Si votre cluster est un cluster Autopilot, omettez
--enable-workload-identity
. Les parcs créent automatiquement un pool d'identités de charge de travail géré par Google qui sert de domaine de confiance.Activez les flottes GKE en exécutant la commande suivante :
gcloud container clusters update CLUSTER_NAME \ --enable-workload-identity \ --enable-fleet \ --fleet-project=PROJECT_ID
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster GKE que vous souhaitez enregistrer auprès du parc GKEPROJECT_ID
: ID du projet hôte du parc GKE
Enable the IAM and Certificate Authority Service APIs:
gcloud services enable cloudresourcemanager.googleapis.com
iam.googleapis.com privateca.googleapis.com Configurez la Google Cloud CLI pour utiliser le projet de facturation et de quota.
gcloud config set billing/quota_project PROJECT_ID
Remplacez PROJECT_ID par l'ID du projet de parc.
Rôles requis
Pour obtenir les autorisations nécessaires pour créer des identités de charge de travail gérées et provisionner des certificats d'identité de charge de travail gérés, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le projet :
-
Pour créer et configurer des identités de charge de travail gérées :
Administrateur IAM de pools d'identités de charge de travail (
roles/iam.workloadIdentityPoolAdmin
) -
Pour créer et configurer des pools d'autorités de certification :
Administrateur de services d'autorité de certification (
roles/privateca.admin
)
Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.
Configurer le service d'autorité de certification pour émettre des certificats pour les identités de charge de travail gérées
Pour configurer des identités de charge de travail gérées pour GKE, vous devez d'abord configurer une autorité de certification (AC) et une ou plusieurs AC subordonnées. Cette configuration est appelée hiérarchie d'AC.
Vous pouvez utiliser des pools CA Service pour configurer cette hiérarchie. Avec cette hiérarchie, le pool d'autorités de certification subordonnées émet les certificats d'identité de charge de travail X.509 pour vos charges de travail.
Configurer votre pool d'autorités de certification racine
Pour créer le pool de CA racine, procédez comme suit :
Créez le pool d'autorités de certification racine au niveau Enterprise à l'aide de gcloud privateca pools create
.
Ce niveau est conçu pour l'émission de certificats de longue durée, à faible volume.
gcloud privateca pools create ROOT_CA_POOL_ID \ --location=REGION \ --project=CA_PROJECT_ID \ --tier=enterprise
Remplacez les éléments suivants :
ROOT_CA_POOL_ID
: ID unique pour le pool d'autorités de certification racine. L'ID peut comporter jusqu'à 64 caractères et ne doit contenir que des caractères alphanumériques minuscules et majuscules, des traits de soulignement ou des traits d'union. L'ID de pool doit être unique dans la région.REGION
: région où se trouve le pool d'autorités de certification racine.CA_PROJECT_ID
: ID du projet dans lequel vous souhaitez créer l'autorité de certification racine.
Pour en savoir plus sur les pools, les niveaux et les régions d'autorités de certification, consultez Créer des pools d'autorités de certification.
Configurer votre autorité de certification racine
Créez une autorité de certification racine dans le pool d'autorités de certification racine à l'aide de gcloud privateca roots create
.
Vous serez peut-être invité à activer l'autorité de certification racine s'il s'agit de la seule autorité de certification du pool d'autorités de certification racine.
Pour créer une autorité de certification racine, exécutez la commande suivante :
gcloud privateca roots create ROOT_CA_ID \ --pool=ROOT_CA_POOL_ID \ --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \ --key-algorithm="KEY_ALGORITHM" \ --max-chain-length=1 \ --location=REGION \ --project=CA_PROJECT_ID \ --auto-enable
Remplacez les éléments suivants :
ROOT_CA_ID
: nom unique de l'autorité de certification racine. Ce nom peut comporter jusqu'à 64 caractères et ne doit contenir que des caractères alphanumériques minuscules et majuscules, des traits de soulignement ou des traits d'union. Le nom de l'autorité de certification doit être unique dans la région.ROOT_CA_POOL_ID
: ID du pool d'autorités de certification racine.ROOT_CA_CN
: nom commun de l'autorité de certification racine.ROOT_CA_ORGANIZATION
: organisation de l'autorité de certification racine.KEY_ALGORITHM
: algorithme de la clé (par exemple,ec-p256-sha256
)REGION
: région où se trouve le pool d'autorités de certification racine.CA_PROJECT_ID
: ID du projet dans lequel vous avez créé l'autorité de certification racine.
Pour en savoir plus sur les champs subject
de l'autorité de certification, consultez Objet.
Vous pouvez également créer des autorités de certification racine supplémentaires dans votre pool d'autorités de certification racine. Cela peut être utile pour la rotation de l'autorité de certification racine.
Configurer les autorités de certification subordonnées
Vous pouvez également configurer des autorités de certification subordonnées. La configuration des autorités de certification subordonnées peut vous aider dans les cas suivants :
Plusieurs scénarios d'émission de certificat : si vous disposez de plusieurs scénarios d'émission de certificat, vous pouvez créer une autorité de certification subordonnée pour chacun d'entre eux.
Meilleur équilibrage de charge : l'ajout de plusieurs autorités de certification subordonnées dans un pool d'autorités de certification vous permet d'améliorer l'équilibrage de charge des requêtes de certificat.
Pour créer un pool d'autorités de certification subordonnées et une autorité de certification subordonnée, procédez comme suit :
Créez le pool d'autorités de certification subordonnées au niveau DevOps, conçu pour l'émission de certificats de courte durée et à volume élevé.
gcloud privateca pools create SUBORDINATE_CA_POOL_ID \ --location=REGION \ --project=CA_PROJECT_ID \ --tier=devops
Remplacez les éléments suivants :
SUBORDINATE_CA_POOL_ID
: ID unique pour le pool d'autorités de certification subordonnée. L'ID peut comporter jusqu'à 64 caractères et ne doit contenir que des caractères alphanumériques minuscules et majuscules, des traits de soulignement ou des traits d'union. L'ID de pool doit être unique dans la région.REGION
: région dans laquelle créer le pool d'autorités de certification subordonné.CA_PROJECT_ID
: ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.
Pour en savoir plus, consultez Créer des pools d'autorités de certification.
Créez une autorité de certification subordonnée dans le pool d'autorités de certification subordonnées. Ne modifiez pas le mode d'émission basé sur la configuration par défaut.
gcloud privateca subordinates create SUBORDINATE_CA_ID \ --pool=SUBORDINATE_CA_POOL_ID \ --location=REGION \ --issuer-pool=ROOT_CA_POOL_ID \ --issuer-location=REGION \ --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \ --key-algorithm="KEY_ALGORITHM" \ --use-preset-profile=subordinate_mtls_pathlen_0 \ --project=CA_PROJECT_ID \ --auto-enable
Remplacez les éléments suivants :
SUBORDINATE_CA_ID
: nom unique de l'autorité de certification subordonnée. Ce nom peut comporter jusqu'à 64 caractères et ne doit contenir que des minuscules et majuscules, des traits de soulignement ou des traits d'union. Le nom du pool doit être unique dans la région.SUBORDINATE_CA_POOL_ID
: nom du pool d'autorités de certification subordonnées.REGION
: région où se trouve le pool d'autorités de certification subordonné.ROOT_CA_POOL_ID
: ID du pool d'autorités de certification racine.REGION
: région du pool d'autorités de certification racine.SUBORDINATE_CA_CN
: nom commun de l'autorité de certification subordonnée.SUBORDINATE_CA_ORGANIZATION
: nom de l'organisation émettrice de l'autorité de certification subordonnée.KEY_ALGORITHM
: algorithme de la clé (par exemple,ec-p256-sha256
)CA_PROJECT_ID
: ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.
Pour en savoir plus sur les champs
subject
de l'autorité de certification, consultez Objet.
Créer un fichier de configuration d'émission de certificats
Pour associer des autorités de certification à des pools d'identités de charge de travail, elles doivent disposer d'une configuration d'émission de certificats. Si vous avez besoin que vos charges de travail s'authentifient dans plusieurs domaines de confiance, vous pouvez également mettre à jour le pool avec des configurations de confiance.
Pour configurer la configuration d'émission de certificats, vous devez créer un fichier de configuration d'émission de certificats. Le format du fichier est semblable à ce qui suit :
{ "inlineCertificateIssuanceConfig": { "caPools": { "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1", "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2" }, "lifetime": "DURATION", "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE, "keyAlgorithm": "ALGORITHM" } }
Remplacez les éléments suivants :
REGION
: régions où se trouvent les autorités de certification.CA_PROJECT_NUMBER
: numéro du projet dans lequel vous avez créé le pool d'autorités de certification subordonné. Pour obtenir le numéro de projet du projet CA_PROJECT_ID, exécutez la commande suivante :gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"
SUBORDINATE_CA_POOL_ID
: nom du pool d'autorités de certification subordonnées.ALGORITHM
: facultatif. Algorithme de chiffrement utilisé pour générer la clé privée. Les valeurs valides sontECDSA_P256
(par défaut),ECDSA_P384
,RSA_2048
,RSA_3072
etRSA_4096
.DURATION
: facultatif. Durée de validité du certificat feuille, en secondes. La valeur doit être comprise entre 86 400 (1 jour) et 2 592 000 (30 jours). Si aucune valeur n'est spécifiée, la valeur par défaut de 86400 (1 jour) est utilisée. La validité réelle du certificat émis dépend également de l'autorité de certification émettrice, car elle peut restreindre la durée de vie de ce certificat.ROTATION_WINDOW_PERCENTAGE
: (facultatif) pourcentage de la durée de vie du certificat au cours duquel un renouvellement est déclenché. La valeur doit être comprise entre 50 et 80. La valeur par défaut est 50.
Créer le fichier de configuration de confiance
Par défaut, vos charges de travail appartenant au même domaine de confiance peuvent s'authentifier mutuellement à l'aide d'identités de charge de travail gérées. Si vous souhaitez que les charges de travail qui se trouvent dans des domaines de confiance différents s'authentifient mutuellement, vous devez déclarer explicitement la relation d'approbation dans le pool d'identités de charge de travail.
Pour ce faire, créez un fichier de configuration de confiance contenant un inlineTrustConfig
qui fournit des certificats pour chaque domaine.
Le fichier de configuration de confiance contient un ensemble d'ancres de confiance que l'identité de charge de travail gérée utilise pour valider les certificats de pairs. Le fichier de configuration de confiance mappe le domaine de confiance SPIFFE aux certificats CA.
Pour créer le fichier de configuration de l'approbation, procédez comme suit :
-
Téléchargez les certificats.
gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \ --output-file=CERTIFICATE_PATH \ --location=REGION
Remplacez les éléments suivants :
-
ROOT_CA_POOL_ID
: ID du pool d'autorités de certification racine -
CERTIFICATE_PATH
: chemin d'accès au certificat encodé au format PEM -
REGION
: région du pool d'autorités de certification racine
-
-
Créez un fichier contenant votre configuration de confiance intégrée, avec des certificats au format PEM. Le fichier ressemble à ceci :
{ "inlineTrustConfig": { "additionalTrustBundles": { "TRUST_DOMAIN_NAME1": { "trustAnchors": [ { "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----" }, { "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----" } ] }, "TRUSTED_DOMAIN_NAME2": { "trustAnchors": [ { "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----" }, { "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----" } ] } } } }
Remplacez les éléments suivants :
-
TRUST_DOMAIN_NAME
: nom de domaine approuvé, formaté comme suit :PROJECT_ID.svc.id.goog
-
CERTIFICATE_MATERIAL
: ensemble de certificats CA au format PEM autorisés à émettre des certificats dans le domaine de confiance.
-
Associer les CA au pool d'identités de charge de travail
Après avoir créé votre hiérarchie d'autorités de certification et des configurations d'émission de certificats pour chaque autorité de certification, vous associez les autorités de certification au pool d'identités de charge de travail. Pour associer une autorité de certification au pool d'identités de charge de travail, vous devez mettre à jour le pool d'identités de charge de travail avec la configuration d'émission de certificats de l'autorité de certification. Vous pouvez ensuite vérifier que le pool a été mis à jour.
Mettre à jour le pool d'identités de charge de travail
Pour mettre à jour le pool, exécutez la commande suivante :
gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \ --location="global" \ --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \ --inline-trust-config-file=TC_JSON_FILE_PATH \ --project=PROJECT_ID
Remplacez les éléments suivants :
TRUST_DOMAIN_NAME
: nom du domaine de confiance, au format suivant :PROJECT_ID.svc.id.goog
CIC_JSON_FILE_PATH
: chemin d'accès au fichier de configuration d'émission de certificat au format JSON (cic.json
) que vous avez créé précédemment.TC_JSON_FILE_PATH
: facultatif. Chemin d'accès au fichier de configuration de confiance au format JSON (tc.json
) que vous avez créé précédemment. Si vos charges de travail s'authentifient dans différents domaines de confiance, vous devez spécifier ce fichier. Sinon, vous pouvez omettre--inline-trust-config
.
Vérifier que le pool d'identités de charge de travail a été mis à jour
Pour vérifier que votre pool d'identités de charge de travail a été mis à jour en même temps que la configuration d'émission de certificats et la configuration de confiance, exécutez la commande suivante :
gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \ --location="global" \ --project=PROJECT_ID
Remplacez TRUST_DOMAIN_NAME
par le nom de domaine approuvé que vous avez utilisé pour mettre à jour le pool d'identités de charge de travail plus tôt dans ce document.
Le résultat de la commande ressemble à ceci :
inlineCertificateIssuanceConfig: caPools: REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1, REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2 keyAlgorithm: ALGORITHM lifetime: DURATION rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE inlineTrustConfig: additionalTrustBundles: example.com: trustAnchors: - pemCertificate: |- -----BEGIN CERTIFICATE----- CERTIFICATE_MATERIAL1 -----END CERTIFICATE----- - pemCertificate: |- -----BEGIN CERTIFICATE----- CERTIFICATE_MATERIAL2 -----END CERTIFICATE----- myorg.com: trustAnchors: - pemCertificate: |- -----BEGIN CERTIFICATE----- CERTIFICATE_MATERIAL3 -----END CERTIFICATE----- - pemCertificate: |- -----BEGIN CERTIFICATE----- CERTIFICATE_MATERIAL4 -----END CERTIFICATE----- name: PROJECT_ID.svc.id.goog state: ACTIVE
Si inlineCertificateIssuanceConfig
ou inlineTrustConfig
ne figurent pas dans le résultat de la commande, vérifiez que vous avez correctement configuré votre gcloud CLI afin d'utiliser le projet approprié pour la facturation et les quotas.
Vous devrez peut-être passer à une version plus récente de gcloud CLI.
Autoriser les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification
Une fois que vous avez associé les autorités de certification au pool d'identités de charge de travail, vous devez autoriser les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification. Pour autoriser ces identités, procédez comme suit :
Accordez le rôle IAM Demandeur de certificat de charge de travail du service CA (
roles/privateca.workloadCertificateRequester
) sur chaque pool d'autorités de certification subordonnées au domaine de confiance. La commandegcloud privateca pools add-iam-policy-binding
suivante autorise le domaine de confiance à demander des certificats à partir des chaînes de certificats de CA Service.gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \ --location=REGION \ --role=roles/privateca.workloadCertificateRequester \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \ --project=CA_PROJECT_ID
Remplacez les éléments suivants :
SUBORDINATE_CA_POOL_ID
: ID du pool d'autorités de certification subordonnées.REGION
: région du pool d'autorités de certification subordonnées.PROJECT_NUMBER
: numéro du projet contenant le pool d'identités de charge de travail GKE.Pour obtenir
PROJECT_NUMBER
à partir dePROJECT_ID
, exécutez la commande suivante :gcloud projects describe PROJECT_ID --format="value(projectNumber)"
PROJECT_ID
: ID du projet hôte de parc GKE.CA_PROJECT_ID
: ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.
Accordez le rôle Lecteur de pool du service d'autorités de certification (
roles/privateca.poolReader
) sur les pools d'autorités de certification subordonnés à l'identité de charge de travail gérée. Cela permet à l'identité de charge de travail gérée d'obtenir les certificats X.509 signés à partir des chaînes de certificats de l'autorité de certification.gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \ --location=REGION \ --role=roles/privateca.poolReader \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \ --project=CA_PROJECT_ID
Remplacez les éléments suivants :
SUBORDINATE_CA_POOL_ID
: ID du pool d'autorités de certification subordonnées.REGION
: région du pool d'autorités de certification subordonnées.PROJECT_NUMBER
: numéro du projet contenant le pool d'identités de charge de travail GKE.PROJECT_ID
: ID du projet hôte de parc GKE.CA_PROJECT_ID
: ID du projet dans lequel vous avez créé l'autorité de certification subordonnée.
Déployer des charges de travail avec des identités de charge de travail gérées
Une fois que vous avez configuré vos pools d'autorités de certification pour émettre des certificats pour les identités de charge de travail gérées, vous pouvez déployer des charges de travail qui possèdent des identités de charge de travail gérées.
Cette section explique comment déployer une charge de travail de test dotée d'une identité de charge de travail gérée. Pour ce faire, vous déployez un pod, vérifiez que des identifiants ont été générés, puis affichez le certificat et l'ID SPIFFE.
Déployer un pod
Pour déployer un pod de test dans votre cluster, procédez comme suit :
Obtenez les identifiants du cluster.
gcloud container clusters get-credentials CLUSTER_NAME \ --location=CLUSTER_ZONE \ --project=CLUSTER_PROJECT_ID
Créez l'espace de noms Kubernetes.
kubectl create namespace KUBERNETES_NAMESPACE
Déployez un PodSpec de test.
cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: namespace: KUBERNETES_NAMESPACE name: example-pod spec: containers: - name: main image: debian command: ['sleep', 'infinity'] volumeMounts: - name: fleet-spiffe-credentials mountPath: /var/run/secrets/workload-spiffe-credentials readOnly: true nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true" volumes: - name: fleet-spiffe-credentials csi: driver: podcertificate.gke.io volumeAttributes: signerName: spiffe.gke.io/fleet-svid trustDomain: fleet-project/svc.id.goog EOF
Lister les identifiants de la charge de travail
Pour lister les identifiants de charge de travail, exécutez la commande suivante. La création des identifiants peut prendre quelques minutes.
kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls /var/run/secrets/workload-spiffe-credentials
Vous devriez obtenir le résultat suivant :
ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json
Afficher le certificat
Pour afficher le certificat, procédez comme suit :
Exportez le certificat dans un fichier de certificat.
kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile
Affichez le fichier de certificat.
cat certfile
Dans le certificat, dans l'attribut
X509v3 Subject Alternative Name
, vous voyez l'ID SPIFFE au format suivant :spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default
.default
fait référence au ServiceAccount Kubernetes par défaut.
Tester l'authentification de charge de travail à charge de travail
Pour tester l'authentification de charge de travail à charge de travail, consultez Tester l'authentification mTLS à l'aide de Go.
L'exemple de code du dépôt crée des charges de travail client et serveur. Vous pouvez tester l'authentification mutuelle entre les charges de travail à l'aide des certificats que vous avez générés précédemment dans ce document.
Étapes suivantes
- Résoudre les problèmes liés à l'identité de charge de travail gérée pour GKE
- En savoir plus sur la création de pools d'autorités de certification.
Faites l'essai
Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
Essai gratuit