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.

Créer une autorité de certification subordonnée

Ce document explique comment créer une autorité de certification subordonnée (sous-CA).

Les autorités de certification secondaires sont chargées d'émettre des certificats directement pour les entités finales, telles que les utilisateurs, les ordinateurs et les appareils. Ils sont signés de manière cryptographique par une autorité de certification parente, souvent l'autorité de certification racine. Les systèmes qui font confiance à l'autorité de certification racine font automatiquement confiance aux autorités de certification secondaires et aux certificats qu'elles émettent.

Le signataire du certificat CA peut être une autre CA créée dans CA Service (par exemple, une CA racine) ou une CA externe. Avec les autorités de certification externes, CA Service génère une demande de signature de certificat (CSR) que l'autorité de certification externe doit signer.

Ce document s'adresse aux membres du groupe d'opérateurs d'application, tels que les développeurs d'applications ou les data scientists, qui gèrent les cycles de vie des certificats dans leur projet. Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Avant de commencer

Avant de pouvoir créer une autorité de certification secondaire, vous devez demander les autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Pour créer, mettre à jour et supprimer des ressources d'autorité de certification, contactez l'administrateur de l'organisation IAM pour demander le rôle Administrateur du service Certificate Authority (certificate-authority-service-admin) dans l'espace de noms du projet de l'autorité de certification.

Préparer votre environnement

Téléchargez et installez la CLI gdcloud, si ce n'est pas déjà fait.
Installez la CLI kubectl.
Générez un fichier kubeconfig pour configurer l'accès à kubectl.

Créer une autorité de certification secondaire gérée

Pour une autorité de certification subordonnée gérée, le signataire du certificat CA est une autre autorité de certification (autorité de certification racine) créée dans CA Service.

Pour créer une autorité de certification secondaire gérée, appliquez une ressource personnalisée à votre instance Distributed Cloud Appliance.

Créez une ressource CertificateAuthority et enregistrez-la dans un fichier YAML nommé subca.yaml :

apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  Name: SUB_CA_NAME
  namespace: USER_PROJECT_NAMESPACE
spec:
  caProfile:
    commonName: COMMON_NAME
    duration: DURATION
    renewBefore: RENEW_BEFORE
    organizations:
    - ORGANIZATIONS
    organizationalUnits:
    - ORGANIZATIONAL_UNITS
    countries:
    - COUNTRIES
    localities:
    - LOCALITIES
    provinces:
    - PROVINCES
    streetAddresses:
    - STREET_ADDRESSES
    postalCodes:
    - POSTAL_CODES
  caCertificate:
    managedSubCA:
      certificateAuthorityRef:
        name: ROOT_CA_NAME
        namespace: USER_PROJECT_NAMESPACE
  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
`SUB_CA_NAME`	Nom de l'autorité de certification secondaire.
`USER_PROJECT_NAMESPACE`	Nom de l'espace de noms où réside le projet utilisateur.
`COMMON_NAME`	Nom commun du certificat CA.
`DURATION`	Durée de vie demandée du certificat CA. Spécifiez une durée en heures (par exemple, `1000h`). Les unités telles que les jours (`d`) ou les années (`y`) ne sont pas acceptées.
`ROOT_CA_NAME`	Nom de l'autorité de certification racine.
`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.
`ORGANIZATIONS`	Organisations à 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`	État 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 elles sont fournies, les valeurs autorisées sont `serverAuth` et `clientAuth`.
`KEY_ALGORITHYM`	Algorithme de clé privée utilisé pour ce certificat. Les valeurs autorisées sont RSA, Ed25519 ou ECDSA. Si la taille n'est pas spécifiée, elle est définie par défaut sur 256 pour ECDSA et 2048 pour RSA. La taille de la clé est ignorée pour Ed25519.
`KEY_SIZE`	La taille, en bits, de la clé privée de ce certificat dépend de l'algorithme. RSA autorise les valeurs 2048, 3072, 4096 ou 8192 (valeur par défaut : 2048). ECDSA autorise 256, 384 ou 521 (par défaut : 256). Ed25519 ignore la taille.
`ACME_ENABLED`	Si la valeur est définie sur `true`, l'AC 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 subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
```
Remplacez MANAGEMENT_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur d'API Management.

Vérifiez que l'autorité de certification secondaire est prête. La préparation de l'autorité de certification prend environ 40 minutes :

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' 
.status.conditions[] | select( .type as $id | "Ready" | index($id))'

La sortie ressemble à ceci :

{
  "lastTransitionTime": "2025-01-24T17:09:29Z",
  "message": "CA reconciled",
  "observedGeneration": 2,
  "reason": "Ready",
  "status": "True",
  "type": "Ready"
}

Créer une autorité de certification secondaire à partir d'une autorité de certification externe

Cette autorité de certification secondaire permet de signer des certificats d'entité finale avec des autorités de certification externes ou gérées par l'utilisateur. Il génère une demande de signature de certificat (CSR) que les utilisateurs doivent signer.

Créez une ressource CertificateAuthority et enregistrez-la dans un fichier YAML nommé subca-external.yaml :

apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  Name: SUB_CA_NAME
  namespace: USER_PROJECT_NAMESPACE
spec:
  caProfile:
    commonName: COMMON_NAME
    duration: DURATION
    renewBefore: RENEW_BEFORE
    organizations:
    - ORGANIZATION
    organizationalUnits:
    - ORGANIZATIONAL_UNITS
    countries:
    - COUNTRIES
    localities:
    - LOCALITIES
    provinces:
    - PROVINCES
    streetAddresses:
    - STREET_ADDRESSES
    postalCodes:
    - POSTAL_CODES
  caCertificate:
    externalCA: {}
  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
`SUB_CA_NAME`	Nom de l'autorité de certification secondaire.
`USER_PROJECT_NAMESPACE`	ID du projet dans lequel vous souhaitez importer l'image.
`COMMON_NAME`	Nom commun du certificat CA.
`DURATION`	Durée de vie demandée du certificat CA. Spécifiez une durée en heures (par exemple, `1000h`). Les unités telles que les jours (`d`) ou les années (`y`) ne sont pas acceptées.
`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`	État 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 elles sont fournies, les valeurs autorisées sont `serverAuth` et `clientAuth`.
`KEY_ALGORITHYM`	Algorithme de clé privée utilisé pour ce certificat. Les valeurs autorisées sont `RSA`, `Ed25519` ou `ECDSA`. Si la taille n'est pas fournie, elle est définie par défaut sur 256 pour `ECDSA` et sur 2048 pour `RSA`. La taille de la clé est ignorée pour `Ed25519`.
`KEY_SIZE`	La taille, en bits, de la clé privée de ce certificat dépend de l'algorithme. `RSA` accepte les valeurs 2048, 3072, 4096 ou 8192 (valeur par défaut : 2048). `ECDSA` accepte les valeurs 256, 384 ou 521 (256 par défaut). `Ed25519` ignore la taille.
`ACME_ENABLED`	Si la valeur est définie sur `true`, l'AC 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 subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG

Une demande de signature de certificat pour l'autorité de certification secondaire est générée sur le serveur de l'API Management GDC. Vous devez télécharger la CSR et la signer. Une fois signé, vous pouvez importer le certificat signé dans le serveur de l'API Management GDC.
Récupérez les demandes de signature de certificat (CSR) de votre environnement Distributed Cloud :
```
kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
```
La commande génère un fichier CSR appelé sub_ca.csr dans le répertoire actuel. Ce fichier contient une CSR pour un certificat CA X.509.
Utilisez l'autorité de certification racine du client pour demander des certificats CA signés pour le fichier sub_ca.csr.
Pour une demande de signature de certificat approuvée, vous devez obtenir un certificat CA signé par l'autorité de certification racine du client. Stockez le certificat dans le fichier sub_ca.crt du répertoire actuel.
Le cas échéant, obtenez le certificat CA racine du client et stockez-le dans le fichier ca.crt du répertoire actuel.
Vérifiez le nom commun (CN) du certificat CA :
```
openssl x509 -noout -subject -in sub_ca.crt
```
Si votre configuration nécessite des extensions d'autre nom de l'objet (SAN), vérifiez les extensions SAN dans le certificat :
```
openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
```

Générez le spec pour corriger la ressource CertificateAuthority :

echo "spec:
  caCertificate:
    externalCA:
      signedCertificate:
        certificate: $(base64 -w0 SUB_CA_NAME.crt)
        ca: $(base64 -w0 ca.crt)" > patch.txt

Le contenu du fichier patch.txt ressemble à ce qui suit :

spec:
  caCertificate:
    externalCA:
      signedCertificate:
        certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
        ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…

Modifiez le champ spec de la ressource CertificateAuthority :

kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'

Vérifiez la disponibilité de l'autorité de certification secondaire BYO (Bring Your Own). Il faut généralement environ 40 minutes pour que l'autorité de certification soit prête :

kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'

La sortie ressemble à ceci :

{
  "lastTransitionTime": "2024-04-30T22:10:50Z",
  "message": "Certificate authority is ready for use",
  "observedGeneration": 3,
  "reason": "Ready",
  "status": "True",
  "type": "Ready"
}

Vérifiez la date d'expiration des certificats CA signés :

kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash

Répertorier les autorités de certification

Pour lister toutes les ressources Certificate Authority Service de votre instance Distributed Cloud sous air gap, 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

Créer une autorité de certification subordonnée 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 autorité de certification secondaire gérée

Créer une autorité de certification secondaire à partir d'une autorité de certification externe

Répertorier les autorités de certification

Créer une autorité de certification subordonnée