Passer à différents modes PKI

Google Distributed Cloud (GDC) sous air gap fournit une API d'infrastructure à clé publique (PKI) pour obtenir des certificats Web. Cette page explique comment passer d'un mode de certificat PKI à un autre. Pour en savoir plus sur les types de configuration du mode PKI, consultez Configuration des certificats TLS Web.

Avant de commencer

Pour obtenir les autorisations nécessaires pour configurer l'émetteur de certificats PKI par défaut, demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle Administrateur PKI de l'infrastructure (infra-pki-admin) dans l'espace de noms système.

Passer au mode BYO subCA

Cette section fournit une série d'étapes pour passer au mode "Apportez votre propre certificat de sous-autorité de certification" (BYO-SubCA).

Créer une sous-autorité de certification BYO

Pour créer une sous-autorité de certification BYO, appliquez une ressource personnalisée à votre zone Distributed Cloud.

1. Créez une ressource CertificateAuthority et enregistrez-la en tant que fichier YAML. Dans l'exemple suivant, vous voyez un exemple de ressource CertificateAuthority.

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     name: CA_NAME
     namespace: pki-system
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
     caCertificate:
       externalCA: {}
     certificateProfile:
       keyUsage:
       - digitalSignature
       - keyCertSign
       - crlSign
       extendedKeyUsage:
       - serverAuth
     secretConfig:
       secretName: SECRET_NAME
   

   Remplacez les variables suivantes :

   • CA_NAME : nom de la sous-autorité de certification.
   • COMMON_NAME : nom commun du certificat de l'autorité de certification.
   • DURATION : durée de vie demandée pour le certificat de l'autorité de certification.
   • RENEW_BEFORE : délai de rotation avant l'expiration du certificat CA.
   • SECRET_NAME : nom du secret Kubernetes qui contiendra la clé privée et le certificat CA signé.

2. Appliquez la ressource personnalisée à votre zone Distributed Cloud.

   kubectl apply -f byo-subca.yaml --kubeconfig MANAGEMENT_API_SERVER
   

   Remplacez MANAGEMENT_API_SERVER par le fichier kubeconfig du serveur de l'API Management.

Une CSR pour l'autorité de certification intermédiaire est générée et vous devez la signer. Pour signer la RDC, suivez les instructions de la section Signer le certificat de sous-autorité de certification BYO.

Signer le certificat de sous-autorité de certification BYO

1. Obtenez les demandes de signature de certificat (CSR) depuis votre environnement GDC :

   kubectl get certificateauthorities CA_NAME -n pki-system -ojson | jq -j '"echo ",
   .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
   

   La commande génère le fichier sub_ca.csr dans le répertoire actuel. Ce fichier contient une RDC pour un certificat d'AC X.509.

2. Utilisez le protocole de l'autorité de certification racine du client pour demander des certificats d'autorité de certification signés pour le fichier sub_ca.csr.

3. Pour une demande de signature de certificat approuvée, vous obtiendrez un certificat d'autorité de certification signé par l'autorité de certification racine du client. Stockez le certificat dans le fichier sub_ca.crt du répertoire actuel. De plus, obtenez le certificat CA racine du client et stockez-le dans le fichier ca.crt du répertoire actuel. Contactez le PMO pour obtenir des instructions précises.

4. Vérifiez les points suivants pour garantir l'intégrité et l'exactitude des certificats :

   1. Assurez-vous que sub_ca.crt respecte le format standard des certificats encodés au format PEM :

      -----BEGIN CERTIFICATE-----
            <Certificate>
      -----END CERTIFICATE-----
      

   2. Vérifiez que sub_ca.crt est une autorité de certification (AC) valide dans l'extension "Contraintes de base" :

      openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Basic Constraints"
      

      Le résultat doit inclure CA:TRUE. Si ce n'est pas le cas, une enquête plus approfondie est nécessaire :

      X509v3 Basic Constraints: critical
          CA:TRUE
      

   3. Vérifiez les extensions SAN (Subject Alternative Name) dans le certificat :

      openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
      

      Si le certificat de l'autorité de certification comporte un nom commun (CN) plutôt qu'un SAN, vérifiez le CN dans le certificat :

      openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject: CN"
      

5. Générez la spécification pour corriger la ressource CertificateAuthority :

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

   Le contenu du fichier patch.txt ressemble à l'extrait suivant :

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

6. Modifiez la spécification de la ressource CertificateAuthority :

   kubectl patch certificateauthority CA_NAME -n pki-system --patch-file patch.txt --type='merge'
   

7. Vérifiez que la sous-autorité de certification BYO est prête :

   kubectl get certificateauthority CA_NAME -n pki-system -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   Vous obtenez un résultat semblable à celui-ci :

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

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

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

9. Créez un fichier YAML de ressources CertificateIssuer et enregistrez-le. Par exemple, byo-subca-issuer.yaml :

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateIssuer
   metadata:
     name: BYO_SUBCA_ISSUER
     namespace: pki-system
   spec:
     caaasConfig:
       certificateAuthorityRef:
         namespace: pki-system
         name: CA_NAME
   

   Remplacez BYO_SUBCA_ISSUER par le nom de l'émetteur de l'autorité de certification subordonnée BYO.

10. Appliquez la ressource personnalisée à votre zone Distributed Cloud dans le serveur de l'API Management à l'aide de la CLI kubectl :

    kubectl apply -f byo-subca-issuer.yaml --kubeconfig MANAGEMENT_API_SERVER
    

11. Vérifiez que le nouvel émetteur est prêt :

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

Passer au mode "Apportez votre propre certificat"

Cette section fournit une série d'étapes pour passer au mode BYO-cert.

Créer un CertificateIssuer BYO

1. Créez une ressource CertificateIssuer et enregistrez-la en tant que fichier YAML, par exemple byo-cert-issuer.yaml. Cet émetteur de certificat BYO utilise l'default-tls-ca géré comme CA de secours :

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateIssuer
   metadata:
     name: BYO_CERT_ISSUER_NAME
     namespace: pki-system
   spec:
     byoCertConfig:
       fallbackCertificateAuthority:
         name: default-tls-ca
         namespace: pki-system
   

   Remplacez BYO_CERT_ISSUER_NAME par le nom de l'émetteur de certificat BYO.

2. Appliquez la ressource personnalisée à votre zone Distributed Cloud dans le serveur de l'API Management :

   kubectl apply -f byo-cert-issuer.yaml --kubeconfig MANAGEMENT_API_SERVER
   

3. Vérifiez que le nouvel émetteur est prêt.

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

   La sortie ressemble à ceci :

   {
     "lastTransitionTime": "2024-05-01T22:25:20Z",
     "message": "",
     "observedGeneration": 1,
     "reason": "FallbackCAReady",
     "status": "True",
     "type": "Ready"
   }
   

Signer le certificat BYO

1. En attendant que la RDC soit signée en externe, une autorité de certification de secours spécifiée dans l'émetteur de certificat BYO peut émettre temporairement un certificat BYO. Obtenez l'état actuel de default-wildcard-cert :

   kubectl get certificate.pki.security.gdc.goog/default-wildcard-cert -n istio-system -o json | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   La sortie ressemble à ceci :

   {
     "lastTransitionTime": "2024-05-03T08:42:10Z",
     "message": "Certificate is issued by a fallback CA",
     "observedGeneration": 1,
     "reason": "UsingFallbackCA",
     "status": "True",
     "type": "Ready"
   }
   

   La raison de l'état prêt indique UsingFallbackCA pour indiquer que l'autorité de certification de secours a émis le certificat. Il est ensuite stocké dans le secret et prêt à être utilisé.

2. Récupérez le nom du secret du certificat :

   kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r '.spec.secretConfig.secretName'
   

   La sortie ressemble à ceci :

   web-tls
   

3. Vérifiez l'émetteur du secret :

   kubectl get secret web-tls -n istio-system -o jsonpath='{.data.tls\.crt}' |
   base64 -d | openssl x509 -text -noout | grep Issuer
   

   La sortie ressemble à ceci :

   Issuer: CN = GDC Managed ORG TLS CA
   

   Un certificat BYO (Bring Your Own Certificate) peut utiliser temporairement un certificat correspondant en attendant la signature de sa propre CSR. Un certificat example-service avec dnsName défini sur example-service.org-1.zone1.google.gdch.test correspond à default-wildcard-cert avec DNSName *.org-1.zone1.google.gdch.test du même émetteur de certificat. Le certificat example-service peut avoir l'état suivant en attendant que sa CSR soit signée :

   {
     "lastTransitionTime": "2024-05-03T22:30:51Z",
     "message": "Using a matched issued Certificate: default-wildcard-cert/istio-system",
     "observedGeneration": 1,
     "reason": "UsingMatchedCert",
     "status": "True",
     "type": "Ready"
   }
   

4. Obtenez la CSR à partir de l'état du certificat :

   kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r ' .status.byoCertStatus.csrStatus'
   

   La sortie ressemble à ceci :

   {
     "conditions": [
       {
         "lastTransitionTime": "2024-05-03T18:14:19Z",
         "message": "",
         "observedGeneration": 1,
         "reason": "WaitingForSigning",
         "status": "False",
         "type": "Ready"
       }
     ],
     "csr": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSB..."
   }
   

5. Il existe différentes méthodes pour signer une RDC en fonction de la configuration de l'autorité de certification externe. Lors de la signature, utilisez le SAN de la CSR. Exemple :

   function signCert() {
      certName=$1
      ns=$2
   
      # Download the CSR from the certificate
      kubectl get certificate.pki.security.gdc.goog $certName -n $ns -o jsonpath='{.status.byoCertStatus.csrStatus.csr}' | base64 -d > $certName.csr
   
      # Get SAN from the csr
      san=$(openssl req -in $certName.csr -noout -text | grep 'DNS:' | sed -s 's/^[ ]*//')
   
      # Save SAN to extension config
      cat <<EOF >$certName-csr.ext
    keyUsage=digitalSignature,keyEncipherment
    extendedKeyUsage=serverAuth,clientAuth
    subjectAltName=${san}
    EOF
   
      # Sign the CSR with an external CA. You need to prepare the external CA cert and key
      openssl x509 -req -in $certName.csr -days 365 -CA ext-ca.crt -CAkey ext-ca.key -CAcreateserial -extfile $certName-csr.ext -out $certName-signed.crt
      openssl x509 -in $certName-signed.crt -text -noout
   
      # Upload the externally signed certificate by patching.
      echo "spec:
        byoCertificate:
           certificate: $(base64 -w0 $certName-signed.crt)
           ca: $(base64 -w0 ext-ca.crt)" > patch.txt
   
      kubectl patch certificate.pki.security.gdc.goog $certName -n $ns --patch-file patch.txt --type='merge'
    }
   
    # Use the function to sign the default-wildcard-cert in the istio-system namespace
    signCert default-wildcard-cert istio-system
   

6. Vérifiez les informations suivantes :

   • L'état de la RDC du certificat est Ready

   kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r ' .status.byoCertStatus.csrStatus.conditions'
   

   [
      {
         "lastTransitionTime": "2024-05-03T21:56:25Z",
         "message": "",
         "observedGeneration": 2,
         "reason": "Signed",
         "status": "True",
         "type": "Ready"
      }
   ]
   

   • Le certificat est Ready pour la raison suivante : Issued

   kubectl get certificate.pki.security.gdc.goog/default-wildcard-cert -n istio-system -o json | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   La sortie ressemble à ceci :

   {
     "lastTransitionTime": "2024-05-03T08:42:10Z",
     "message": "Certificate is issued",
     "observedGeneration": 2,
     "reason": "Issued",
     "status": "True",
     "type": "Ready"
   }
   

   • La clé secrète est mise à jour :

   kubectl get secret web-tls -n istio-system -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout | grep Issuer
   

   La sortie ressemble à ceci :

           Issuer: CN = external-ca
   

Passer à un certificat BYO avec le mode ACME

Cette section fournit une série d'étapes pour passer à un certificat BYO avec le mode ACME.

Créer un CertificateIssuer avec une configuration ACME

1. Créez une ressource CertificateIssuer avec la configuration ACME et enregistrez-la en tant que fichier YAML, tel que acme-issuer.yaml.

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateIssuer
   metadata:
     name: ACME_ISSUER_NAME
     namespace: pki-system
   spec:
        acmeConfig:
          rootCACertificate: ROOT_CA_CERTIFICATE
          acme:
            server: ACME_SERVER_URL
            caBundle: CA_BUNDLE
            privateKeySecretRef:
              name: PRIVATE_KEY_SECRET_NAME
   

   Remplacez les variables suivantes :

   • ACME_ISSUER_NAME : nom de l'émetteur ACME.
   • ROOT_CA_CERTIFICATE : données de l'autorité de certification racine des certificats émis par le serveur ACME.
   • ACME_SERVER_URL : URL permettant d'accéder au point de terminaison du répertoire du serveur ACME.
   • CA_BUNDLE : bundle encodé en base64 des autorités de certification PEM qui valident la chaîne de certificats présentée par le serveur ACME.
   • PRIVATE_KEY_SECRET_NAME : nom du secret contenant la clé privée du compte ACME.

   Pour utiliser une clé privée de compte ACME existante, assurez-vous que le secret qui la contient utilise le nom PRIVATE_KEY_SECRET_NAME dans le même espace de noms que l'émetteur ACME. Si vous ne fournissez pas ce secret, un nouveau secret portant le même nom est généré automatiquement pour stocker la clé privée du compte ACME.

2. Appliquez la ressource personnalisée à votre zone Distributed Cloud :

   kubectl apply -f acme-issuer.yaml --kubeconfig MANAGEMENT_API_SERVER
   

3. Vérifiez que le nouvel émetteur est prêt :

   kubectl --kubeconfig MANAGEMENT_API_SERVER -n pki-system get certificateissuer.pki.security.gdc.goog/ACME_ISSUER_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   Vous obtenez un résultat semblable à celui-ci :

   {
     "lastTransitionTime": "2024-05-01T18:32:17Z",
     "message": "",
     "observedGeneration": 1,
     "reason": "ACMEClientReady",
     "status": "True",
     "type": "Ready"
   }
   

Réémission de certificats

Pour définir le nouvel émetteur ACME comme émetteur par défaut, consultez Modifier l'émetteur de certificat par défaut.

Pour réémettre immédiatement des certificats avec le nouvel émetteur par défaut, consultez Réémettre manuellement des certificats Web PKI.