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 (Sub CA).

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

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

Ce document est destiné aux audiences du groupe d'opérateurs d'application, telles 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 Sub CA, 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 votre administrateur IAM de l'organisation afin de demander le rôle Administrateur de Certificate Authority Service (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 Sub CA gérée

Pour une Sub CA 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 Sub CA gérée, appliquez une ressource personnalisée à votre instance Distributed Cloud Appliance.

Créez une ressource CertificateAuthority et enregistrez-la en tant que 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 la Sub CA.
`USER_PROJECT_NAMESPACE`	Nom de l'espace de noms dans lequel 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 dans le certificat.
`ORGANIZATIONAL_UNITS`	Unités organisationnelles à utiliser dans le certificat.
`COUNTRIES`	Pays à utiliser dans le certificat.
`LOCALITIES`	Villes à utiliser dans le certificat.
`PROVINCES`	États ou provinces à utiliser dans le certificat.
`STREET_ADDRESSES`	Adresses postales à utiliser dans le certificat.
`POSTAL_CODES`	Codes postaux à utiliser dans le certificat.
`EXTENDED_KEY_USAGE`	Utilisation étendue de la clé pour le certificat. Si elle est fournie, 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 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 2048, 3072, 4096 ou 8192 (2048 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 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 la Sub CA est prête. L'autorité de certification met environ 40 minutes à être prête :

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 Sub CA à partir d'une autorité de certification externe

Cette Sub CA est compatible avec la signature de certificats de feuille avec des autorités de certification externes ou gérées par l'utilisateur. Elle génère une demande de signature de certificat que les utilisateurs peuvent signer.

Créez une ressource CertificateAuthority et enregistrez-la en tant que 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 la Sub CA.
`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 dans le certificat.
`ORGANIZATIONAL_UNITS`	Unités organisationnelles à utiliser dans le certificat.
`COUNTRIES`	Pays à utiliser dans le certificat.
`LOCALITIES`	Villes à utiliser dans le certificat.
`PROVINCES`	États ou provinces à utiliser dans le certificat.
`STREET_ADDRESSES`	Adresses postales à utiliser dans le certificat.
`POSTAL_CODES`	Codes postaux à utiliser dans le certificat.
`EXTENDED_KEY_USAGE`	Utilisation étendue de la clé pour le certificat. Si elle est fournie, 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 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 2048, 3072, 4096 ou 8192 (2048 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 subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG

Une demande de signature de certificat pour la Sub CA est générée dans le serveur d'API Management GDC. Vous devez télécharger la demande de signature de certificat et la signer. Une fois signé, vous pouvez importer le certificat signé dans le serveur d'API Management GDC.
Collectez les demandes de signature de certificat (CSR) à partir 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 de demande de signature de certificat nommé sub_ca.csr dans le répertoire actuel. Ce fichier contient une demande de signature de certificat 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 du certificat CA :
```
openssl x509 -noout -subject -in sub_ca.crt
```
Si votre configuration nécessite des extensions d'autres noms d'objet (SAN), vérifiez-les dans le certificat :
```
openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
```

Générez la spec pour appliquer un correctif à 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 à ceci :

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 que la Sub CA "apportez votre propre" (BYO) est prête. L'autorité de certification met normalement environ 40 minutes à être 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

Lister les autorités de certification

Pour lister toutes les ressources Certificate Authority Service dans 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 Sub CA gérée

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

Lister les autorités de certification

Créer une autorité de certification subordonnée