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 le parc GKE. Il explique également comment déployer une charge de travail et vérifier son identité et son certificat.
Pour configurer et utiliser des identités de charge de travail gérées pour GKE, procédez comme suit :
Déployer des charges de travail avec des identités de charge de travail gérées
Facultatif : Activer la fédération d'approbation entre les pools d'identités de charge de travail
Pool d'identités de charge de travail géré par Google
Lorsque vous ajoutez des clusters à des parcs GKE, GKE crée automatiquement un pool d'identités de charge de travail géré par Google, qui sert de racine de confiance, également appelé domaine de confiance SPIFFE pour vos charges de travail. Toutes les charges de travail du domaine de confiance reçoivent des certificats et des ancres de confiance qui permettent l'authentification par défaut au sein du domaine de confiance. Si vous avez plusieurs domaines approuvés, vous pouvez activer la fédération d'approbation entre eux pour permettre la communication entre les domaines approuvés.
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 de n'importe quel cluster du pool peuvent utiliser n'importe quelle identité de ce 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 le flag --project pour spécifier le projet approprié pour chaque ressource.
Avant de commencer
Créez ou sélectionnez un projet Google Cloud .
Rôles requis pour sélectionner ou créer un projet
- Sélectionnez un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique. Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
-
Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (
roles/resourcemanager.projectCreator), qui contient l'autorisationresourcemanager.projects.create. Découvrez comment attribuer des rôles.
-
Créez un projet Google Cloud :
gcloud projects create PROJECT_ID
Remplacez
PROJECT_IDpar le nom du projet Google Cloud que vous créez. -
Sélectionnez le projet Google Cloud que vous avez créé :
gcloud config set project PROJECT_ID
Remplacez
PROJECT_IDpar le nom de votre projet Google Cloud .
Comprendre les identités de charge de travail gérées
Assurez-vous que vos clusters exécutent la version 1.33.0-gke.2248000 ou ultérieure.
Ajoutez vos clusters aux parcs GKE. Si votre cluster est un cluster Autopilot, omettez l'option
--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 parcs GKE en exécutant la commande suivante :
gcloud container clusters update CLUSTER_NAME \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-fleet \ --fleet-project=PROJECT_ID
Remplacez ces valeurs :
CLUSTER_NAME: nom du cluster GKE à enregistrer auprès du parc GKEPROJECT_ID: ID du projet hôte du parc GKE
Activez les API IAM et Certificate Authority Service :
Rôles requis pour activer les API
Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (
roles/serviceusage.serviceUsageAdmin), qui contient l'autorisationserviceusage.services.enable. Découvrez comment attribuer des rôles.gcloud services enable cloudresourcemanager.googleapis.com
iam.googleapis.com privateca.googleapis.com Configurez Google Cloud CLI pour utiliser votre 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.
Choisir une option d'autorité de certification
Pour signer vos certificats de charge de travail, choisissez l'option d'autorité de certification (CA) qui correspond le mieux à votre cas d'utilisation :
CA par défaut gérée par Google : utilisez cette option pour une solution entièrement gérée et sans frais. L'autorité de certification par défaut fournit une racine de confiance partagée pour tous les utilisateurs Google Cloud .
Autorité de certification personnalisée : utilisez cette option pour configurer votre propre infrastructure à clé publique (PKI) via Certificate Authority Service. Cette option est appropriée si vous avez besoin d'une racine de confiance personnalisée ou si vous devez stocker des clés de signature dans un module de sécurité matérielle (HSM) pour répondre aux exigences de conformité. Certificate Authority Service est facturé séparément de l'identité de charge de travail gérée. Pour en savoir plus, consultez la page Tarifs du service CA.
Configurer une autorité de certification
AC par défaut
Pour associer l'autorité de certification par défaut au pool d'identités de charge de travail, mettez à jour le pool d'identités de charge de travail avec l'indicateur use-default-shared-ca.
gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
--location="global" \
--use-default-shared-ca \
--project=PROJECT_ID
Remplacez les éléments suivants :
TRUST_DOMAIN_NAME:Nom du domaine d'approbation, au format suivant :
PROJECT_ID.svc.id.goog
PROJECT_ID: ID du projet.
CA personnalisée
- Configurez le service d'autorité de certification pour émettre des certificats pour les identités de charge de travail gérées.
- Associez les CA au pool d'identités de charge de travail.
- Autorisez les identités de charge de travail gérées à demander des certificats à partir du pool d'autorités de certification.
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 d'autorités de certification, les niveaux et les régions, 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=devopsRemplacez 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-enableRemplacez 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
subjectde 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, vous devez disposer d'une configuration d'émission de certificats. Si vous avez besoin que vos charges de travail s'authentifient dans plusieurs domaines approuvés, consultez Activer la fédération d'approbation entre les pools d'identités de charge de travail (facultatif).
Pour configurer la configuration d'émission de certificat, vous devez créer un fichier de configuration d'émission de certificat nommé cic.json. 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,ECDSA_P384,RSA_2048,RSA_3072etRSA_4096. Si aucune valeur n'est spécifiée,ECDSA_P256est utilisé comme algorithme par défaut.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. Si aucune valeur n'est spécifiée, la valeur par défaut est 50.
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 \
--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 de l'émission de certificats au format JSON (cic.json) que vous avez créé précédemment.
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 avec la configuration d'émission de certificats, 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 haut dans ce document.
Le résultat ressemble à ce qui suit :
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
mode: TRUST_DOMAIN
name: PROJECT_ID.svc.id.goog
state: ACTIVE
Si inlineCertificateIssuanceConfig ne figure 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
Après avoir associé les autorités de certification au pool d'identités de charge de travail, autorisez 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 :
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-bindingsuivante 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_IDRemplacez 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 GKEPour 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_IDRemplacez 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 de projet du projet contenant le pool d'identités de charge de travail GKEPROJECT_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_IDCréez l'espace de noms Kubernetes.
kubectl create namespace KUBERNETES_NAMESPACEDé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 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 > certfileAffichez le fichier de certificat.
cat certfileDans 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.defaultfait 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.
Activer la fédération d'approbation entre les pools d'identité de charge de travail (facultatif)
Pour activer l'authentification mutuelle pour les charges de travail dans différents domaines de confiance, vous devez configurer la fédération de confiance entre les pools d'identités de charge de travail. Cette étape n'est requise que si vos charges de travail doivent s'authentifier auprès de charges de travail dans un autre pool d'identités de charge de travail.
Pour activer la fédération d'identité, procédez comme suit :
- Créez le fichier de configuration de l'approbation.
- Mettez à jour le pool d'identités de charge de travail avec la configuration de confiance.
Créer le fichier de configuration de confiance
Créez le fichier de configuration de confiance avec une section inlineTrustConfig qui spécifie les 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 une autorité de certification personnalisée, téléchargez les certificats d'un domaine de confiance qui utilise une autorité de certification personnalisée.
gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \ --output-file=CERTIFICATE_PATH \ --location=REGIONRemplacez 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 nommé
tc.jsoncontenant votre configuration de confiance intégrée. Si un domaine utilise l'autorité de certification par défaut gérée par Google, utilisez le champtrustDefaultSharedCa. Si un domaine utilise une autorité de certification personnalisée, utilisez les certificats encodés au format PEM que vous avez téléchargés précédemment.Le fichier ressemble à ceci :
Dans cet exemple, TRUST_DOMAIN_A utilise l'autorité de certification par défaut gérée par Google, et TRUSTED_DOMAIN_B utilise une autorité de certification personnalisée avec les certificats racines téléchargés.
{ "inlineTrustConfig": { "additionalTrustBundles": { "TRUST_DOMAIN_A": { "trustDefaultSharedCa": true }, "TRUSTED_DOMAIN_B": { "trustAnchors": [ { "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----" }, { "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----" } ] } } } }Remplacez les éléments suivants :
- TRUST_DOMAIN_A : nom du domaine de confiance qui utilise l'autorité de certification par défaut gérée par Google.
- TRUST_DOMAIN_B : nom du domaine de confiance qui utilise une AC personnalisée.
- CERTIFICATE_MATERIAL : ensemble de certificats CA au format PEM autorisés à émettre des certificats dans le domaine de confiance.
Mettre à jour le pool d'identités de charge de travail avec la configuration de confiance
gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
--location="global" \
--inline-trust-config-file=TC_JSON_FILE_PATH \
--project=PROJECT_ID
Remplacez les éléments suivants :
- TRUST_DOMAIN_NAME : nom du domaine approuvé.
- TC_JSON_FILE_PATH : chemin d'accès au fichier de configuration de l'approbation au format JSON (
tc.json) que vous avez créé. - PROJECT_ID : ID du projet.
Étapes suivantes
- Résolvez 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 sans frais pour exécuter, tester et déployer des charges de travail.
Essai sans frais