Cette page décrit la procédure à suivre pour créer une autorité de certification (CA) racine dans Google Distributed Cloud (GDC) air-gapped.
Une autorité de certification racine, qui se trouve au sommet de la hiérarchie de l'infrastructure à clé publique (PKI), établit l'ancrage de confiance pour la PKI. Pour utiliser des certificats dans une PKI, les appareils, logiciels et composants doivent faire confiance à l'autorité de certification racine. Cette configuration garantit la confiance dans tous les certificats émis par l'autorité de certification racine, ce qui permet de faire confiance à l'infrastructure PKI elle-même.
Avant de commencer
Pour obtenir les autorisations nécessaires pour créer une autorité de certification racine, demandez à votre administrateur IAM de l'organisation de vous accorder le rôle Administrateur du service d'autorité de certification (certificate-authority-service-admin
). Pour en savoir plus sur les rôles, consultez Définitions des rôles.
Obtenir le fichier kubeconfig
Pour exécuter des commandes sur le serveur de l'API Management, assurez-vous de disposer des ressources suivantes :
Connectez-vous et générez le fichier kubeconfig pour le serveur d'API Management si vous n'en avez pas.
Utilisez le chemin d'accès au fichier kubeconfig du serveur de l'API Management pour remplacer
MANAGEMENT_API_SERVER_KUBECONFIG
dans ces instructions.
Créer une autorité de certification racine
Pour créer une autorité de certification racine, appliquez une ressource personnalisée à votre instance Distributed Cloud isolée.
Créez une ressource
CertificateAuthority
et enregistrez-la en tant que fichier YAML nomméroot-ca.yaml
:apiVersion: pki.security.gdc.goog/v1 kind: CertificateAuthority metadata: name: ROOT_CA_NAME namespace: USER_PROJECT_NAMESPACE spec: caProfile: commonName: COMMON_NAME duration: DURATION renewBefore: RENEW_BEFORE organizations: - ORGANIZATION organizationalUnits: - ORGANIZATIONAL_UNITS countries: - COUNTRIES localities: - LOCALTIES provinces: - PROVINCES streetAddresses: - STREET_ADDRESSES postalCodes: - POSTAL_CODES caCertificate: selfSignedCA: {} certificateProfile: keyUsage: - digitalSignature - keyCertSign - crlSign extendedKeyUsage: - EXTENDED_KEY_USAGE secretConfig: secretName: SECRET_NAME privateKeyConfig: algorithm: KEY_ALGORITHM size: KEY_SIZE acme: enabled: ACME_ENABLED
Remplacez les variables suivantes :
Variable Description ROOT_CA_NAME Nom de l'autorité de certification racine. USER_PROJECT_NAMESPACE Nom de l'espace de noms dans lequel réside le projet utilisateur. COMMON_NAME Nom commun du certificat de l'autorité de certification. DURATION Durée de vie demandée du certificat CA. SECRET_NAME Nom du secret Kubernetes contenant la clé privée et le certificat CA signé. Les variables suivantes sont des valeurs facultatives :
Variable Description RENEW_BEFORE Délai de rotation avant l'expiration du certificat CA. ORGANIZATION Organisation à utiliser sur le certificat. ORGANIZATIONAL_UNITS Unités organisationnelles à utiliser sur le certificat. COUNTRIES Pays à utiliser sur le certificat. LOCALITIES Villes à utiliser sur le certificat. PROVINCES États ou provinces à utiliser sur le certificat. STREET_ADDRESSES Adresses postales à utiliser sur le certificat. POSTAL_CODES Codes postaux à utiliser sur le certificat. EXTENDED_KEY_USAGE Utilisation étendue de la clé pour le certificat. Si elle est fournie, les valeurs autorisées sont serverAuth
etclientAuth
.KEY_ALGORITHYM Algorithme de clé privée utilisé pour ce certificat. Les valeurs autorisées sont RSA
,Ed25519
ouECDSA
. Si la taille n'est pas indiquée, la valeur par défaut est 256 pourECDSA
et 2 048 pourRSA
. La taille de la clé est ignorée pourEd25519
.KEY_SIZE La taille, en bits, de la clé privée de ce certificat dépend de l'algorithme. RSA
autorise 2 048, 3 072, 4 096 ou 8 192 (2 048 par défaut).ECDSA
autorise 256, 384 ou 521 (256 par défaut).Ed25519
ignore la taille.ACME_ENABLED Si la valeur est définie sur true
, l'autorité de certification s'exécute en mode ACME et génère l'URL du serveur ACME. Vous pouvez ensuite utiliser le client et le protocole ACME pour gérer les certificats.Appliquez la ressource personnalisée à votre instance Distributed Cloud :
kubectl apply -f root-ca.yaml –kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
Remplacez
MANAGEMENT_API_SERVER_KUBECONFIG
par le chemin d'accès au fichier kubeconfig du serveur de l'API Management.Vérifiez la disponibilité de l'autorité de certification racine. Il faut généralement environ 40 minutes pour que l'autorité de certification soit prête :
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/ROOT_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))
La sortie ressemble à ceci :
{ "lastTransitionTime": "2025-01-24T17:09:19Z", "message": "CA reconciled", "observedGeneration": 2, "reason": "Ready", "status": "True", "type": "Ready" }
Lister les autorités de certification
Pour lister toutes les ressources Certificate Authority Service dans votre instance Distributed Cloud isolée, procédez comme suit :
Utilisez le paramètre certificateauthorities
pour lister toutes les ressources CertificateAuthority
:
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities
La sortie ressemble à ceci :
NAMESPACE NAME READY REASON AGE
foo root-ca True Ready 7h24m
foo sub-ca True Ready 7h24m