Faça a transição para diferentes modos de ICP

O Google Distributed Cloud (GDC) air-gapped fornece uma API de infraestrutura de chave pública (PKI) para obter certificados Web. Esta página fornece instruções para fazer a transição de um modo de certificado PKI para outro. Para mais informações sobre os tipos de configuração do modo PKI, consulte o artigo Configuração do certificado TLS Web

Antes de começar

Para receber as autorizações necessárias para configurar o emissor de certificados predefinido da PKI, peça ao administrador da IAM da organização que lhe conceda a função de administrador da PKI da infraestrutura (infra-pki-admin) no espaço de nomes do sistema.

Faça a transição para o modo de subCA TSPD

Esta secção fornece uma série de passos para fazer a transição para o modo de certificado de subCA (BYO).

Crie uma subCA do tipo BYO

Para criar uma subCA BYO, aplique um recurso personalizado à sua zona do Distributed Cloud.

1. Crie um recurso CertificateAuthority e guarde-o como um ficheiro YAML. No exemplo seguinte, vê um exemplo de recurso 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
   

   Substitua as seguintes variáveis:

   • CA_NAME: o nome da subCA.
   • COMMON_NAME: o nome comum do certificado da AC.
   • DURATION: a duração pedida do certificado da AC.
   • RENEW_BEFORE: o tempo de rotação antes de o certificado da AC expirar.
   • SECRET_NAME: o nome do segredo do Kubernetes que vai conter a chave privada e o certificado de AC assinado.

2. Aplique o recurso personalizado à sua zona do Distributed Cloud.

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

   Substitua MANAGEMENT_API_SERVER pelo ficheiro kubeconfig do servidor da API de gestão.

Um CSR para a AC subordinada é gerado e aguarda a sua assinatura. Para assinar a CSR, siga as instruções na secção Assine o certificado da subCA da BYO.

Assine o certificado da subCA da funcionalidade BYO

1. Obtenha os pedidos de assinatura de certificado (CSR) do seu ambiente do GDC:

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

   O comando gera o ficheiro sub_ca.csr no diretório atual. Este ficheiro contém um CSR para um certificado de AC X.509.

2. Use o protocolo da CA de raiz do cliente para pedir certificados da CA assinados para o ficheiro sub_ca.csr.

3. Para um pedido de assinatura de certificado aprovado, recebe um certificado de AC assinado pela AC de raiz do cliente. Armazene o certificado no ficheiro sub_ca.crt no diretório atual. Além disso, obtenha o certificado de raiz da CA do cliente e armazene-o no ficheiro ca.crt no diretório atual. Contacte o PMO para receber instruções exatas.

4. Verifique o seguinte para garantir a integridade e a precisão dos certificados:

   1. Certifique-se de que sub_ca.crt cumpre o formato de certificado codificado PEM padrão:

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

   2. Verifique se sub_ca.crt é uma autoridade de certificação (AC) válida na extensão "Restrições básicas":

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

      O resultado tem de incluir CA:TRUE ou é necessária uma investigação mais aprofundada:

      X509v3 Basic Constraints: critical
          CA:TRUE
      

   3. Verifique as extensões do nome alternativo do requerente (SAN) no certificado:

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

      Se o certificado da AC tiver um nome comum (CN) em vez de um SAN, verifique o CN no certificado:

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

5. Gere a especificação para aplicar o patch ao recurso CertificateAuthority:

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

   O conteúdo no ficheiro patch.txt tem um aspeto semelhante ao seguinte fragmento:

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

6. Edite a especificação do recurso CertificateAuthority:

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

7. Verifique a prontidão da subCA BYO:

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

   Vê um resultado semelhante ao seguinte:

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

8. Verifique a validade dos certificados da AC assinados:

   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. Crie um ficheiro YAML de recursos CertificateIssuer e guarde-o. Por exemplo: 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
   

   Substitua BYO_SUBCA_ISSUER pelo nome do emissor da subCA byo.

10. Aplique o recurso personalizado à sua zona do Distributed Cloud no servidor da API Management através da CLI kubectl:

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

11. Valide a disponibilidade do novo emissor:

    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))'
    

Transição para o modo de certificado BYO

Esta secção fornece uma série de passos para fazer a transição para o modo BYO-cert.

Crie um CertificateIssuer BYO

1. Crie um recurso CertificateIssuer e guarde-o como um ficheiro YAML, por exemplo, byo-cert-issuer.yaml. Este emissor de certificados BYO usa a AC gerida default-tls-ca como AC alternativa:

   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
   

   Substitua BYO_CERT_ISSUER_NAME pelo nome do emissor do BYO-cert.

2. Aplique o recurso personalizado à sua zona do Distributed Cloud no servidor da API Management:

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

3. Valide a disponibilidade do novo emissor.

   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))'
   

   O resultado tem um aspeto semelhante ao seguinte:

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

Assine o certificado BYO

Nota: os administradores da plataforma não podem aceder ao certificado default-wildcard-cert no espaço de nomes istio-system. Contacte o seu operador de infraestrutura (IO) para realizar estes passos.

1. Quando aguarda que o CSR seja assinado externamente, pode ser emitido temporariamente um certificado BYO por uma CA alternativa especificada no emissor do certificado BYO. Obtenha o estado atual do BYO-cert 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))'
   

   O resultado tem um aspeto semelhante ao seguinte:

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

   O motivo de prontidão indica UsingFallbackCA para indicar que a AC alternativa emite o certificado. Em seguida, é armazenado no segredo e fica pronto a ser usado.

2. Obtenha o nome do Secret do certificado:

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

   O resultado tem um aspeto semelhante ao seguinte:

   web-tls
   

3. Verifique o emissor do segredo:

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

   O resultado tem um aspeto semelhante ao seguinte:

   Issuer: CN = GDC Managed ORG TLS CA
   

   Um certificado do tipo "traga o seu próprio certificado" (BYO-cert) pode usar temporariamente um certificado correspondente enquanto aguarda a sua própria assinatura de CSR. Um certificado example-service com dnsName como example-service.org-1.zone1.google.gdch.test corresponde ao default-wildcard-certcom DNSName *.org-1.zone1.google.gdch.test do mesmo emissor de certificado. O certificado example-service pode ter o seguinte estado enquanto aguarda que o respetivo CSR seja assinado:

   {
     "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. Obtenha o CSR a partir do estado do certificado:

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

   O resultado tem um aspeto semelhante ao seguinte:

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

5. Existem diferentes métodos para assinar um CSR com base na configuração da AC externa. Ao assinar, use o SAN do CSR. Por exemplo:

   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. Verifique os seguintes detalhes:

   • O estado do CSR do certificado é 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"
      }
   ]
   

   • O certificado está Ready pelo motivo 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))'
   

   O resultado tem um aspeto semelhante ao seguinte:

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

   • O código secreto é atualizado:

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

   O resultado tem um aspeto semelhante ao seguinte:

           Issuer: CN = external-ca
   

Faça a transição para um certificado BYO com o modo ACME

Esta secção fornece uma série de passos para fazer a transição para um BYO-cert com o modo ACME.

Crie um CertificateIssuer com a configuração ACME

1. Crie um recurso CertificateIssuer com a configuração ACME e guarde-o como um ficheiro YAML, como 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
   

   Substitua as seguintes variáveis:

   • ACME_ISSUER_NAME: o nome do emissor ACME.
   • ROOT_CA_CERTIFICATE: os dados da CA de raiz dos certificados emitidos pelo servidor ACME.
   • ACME_SERVER_URL: o URL para aceder ao ponto final do diretório do servidor ACME.
   • CA_BUNDLE: o pacote de ACs PEM codificado em Base64 que valida a cadeia de certificados apresentada pelo servidor ACME.
   • PRIVATE_KEY_SECRET_NAME: o nome do segredo que contém a chave privada da conta ACME.

   Para usar uma chave privada de conta ACME existente, certifique-se de que o segredo que a contém usa o nome PRIVATE_KEY_SECRET_NAME no mesmo espaço de nomes que o emissor ACME. Se não facultar este segredo, é gerado automaticamente um novo com o mesmo nome para armazenar a chave privada da conta ACME.

2. Aplique o recurso personalizado à sua zona do Distributed Cloud:

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

3. Valide a disponibilidade do novo emissor:

   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))'
   

   Vê um resultado semelhante ao seguinte:

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

Reemissão de certificado

Para mudar o emissor predefinido para o novo emissor ACME, consulte o artigo Altere o emissor do certificado predefinido

Para reemitir imediatamente certificados com o novo emissor predefinido, consulte o artigo Reemita manualmente certificados Web de PKI.