Esta página foi traduzida pela API Cloud Translation.

Crie uma autoridade de certificação subordinada

Esta página descreve os passos para criar uma autoridade de certificação subordinada (AC sub).

As ACs subordinadas são responsáveis pela emissão de certificados diretamente para entidades finais, como utilizadores, computadores e dispositivos. São assinados criptograficamente por uma CA principal, muitas vezes a CA de raiz. Os sistemas que confiam na CA de raiz confiam automaticamente nas sub-ACs e nos certificados que emitem.

O signatário do certificado da AC pode ser outra AC criada no serviço de AC, por exemplo, a AC de raiz, ou uma AC externa. Com as ACs externas, o serviço de AC gera um pedido de assinatura de certificado (CSR) que a AC externa tem de assinar.

Antes de começar

Para receber as autorizações necessárias para criar uma autoridade de certificação subordinada, peça ao administrador de IAM da sua organização para lhe conceder a função de administrador do serviço de autoridade de certificação (certificate-authority-service-admin). Para mais informações sobre as funções, consulte o artigo Definições de funções.

Obtenha o ficheiro kubeconfig

Para executar comandos no servidor da API Management, certifique-se de que tem os seguintes recursos:

Inicie sessão e gere o ficheiro kubeconfig para o servidor da API Management, se não tiver um.
Use o caminho para o ficheiro kubeconfig do servidor da API de gestão para substituir MANAGEMENT_API_SERVER_KUBECONFIG nestas instruções.

Crie uma sub-CA gerida

Para uma sub-AC gerida, o signatário do certificado da AC é outra AC (CA de raiz) criada no serviço de AC.

Para criar uma sub-AC gerida, aplique um recurso personalizado à sua instância do Distributed Cloud Appliance.

Crie um recurso CertificateAuthority e guarde-o como um ficheiro YAML denominado 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

Substitua as seguintes variáveis:

Variável	Descrição
`SUB_CA_NAME`	O nome da AC subordinada.
`USER_PROJECT_NAMESPACE`	O nome do espaço de nomes onde reside o projeto do utilizador.
`COMMON_NAME`	O nome comum do certificado da AC.
`DURATION`	A duração total pedida do certificado da CA.
`ROOT_CA_NAME`	O nome da AC de raiz.
`SECRET_NAME`	O nome do segredo do Kubernetes que contém a chave privada e o certificado da CA assinado.

As seguintes variáveis são valores opcionais:

Variável	Descrição
`RENEW_BEFORE`	O tempo de rotação antes de o certificado da CA expirar.
`ORGANIZATIONS`	Organizações a usar no certificado.
`ORGANIZATIONAL_UNITS`	Unidades organizacionais a usar no certificado.
`COUNTRIES`	Países a usar no certificado.
`LOCALITIES`	Cidades a usar no certificado.
`PROVINCES`	Estados ou províncias a usar no certificado.
`STREET_ADDRESSES`	Moradas a usar no certificado.
`POSTAL_CODES`	Códigos postais a usar no certificado.
`EXTENDED_KEY_USAGE`	A utilização alargada da chave para o certificado. Se for fornecido, os valores permitidos são `serverAuth` e `clientAuth`.
`KEY_ALGORITHYM`	O algoritmo de chave privada usado para este certificado. Os valores permitidos são RSA, Ed25519 ou ECDSA. Se o tamanho não for fornecido, o valor predefinido é 256 para ECDSA e 2048 para RSA. O tamanho da chave é ignorado para Ed25519.
`KEY_SIZE`	O tamanho, em bits, da chave privada deste certificado depende do algoritmo. O RSA permite 2048, 3072, 4096 ou 8192 (predefinição: 2048). O ECDSA permite 256, 384 ou 521 (predefinição: 256). O Ed25519 ignora o tamanho.
`ACME_ENABLED`	Se estiver definido como `true`, a AC é executada no modo ACME e produz o URL do servidor ACME. Em seguida, pode usar o cliente e o protocolo ACME para gerir certificados.

Aplique o recurso personalizado à sua instância do Distributed Cloud:
```
kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
```
Substitua MANAGEMENT_API_SERVER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do servidor da API Management.

Verifique a prontidão da AC subordinada. A CA demora cerca de 40 minutos a ficar pronta:

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

O resultado tem um aspeto semelhante ao seguinte:

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

Crie uma CA subordinada a partir de uma CA externa

Esta sub-AC suporta a assinatura de certificados finais com ACs externas ou geridas pelo utilizador. Gera um CSR para os utilizadores assinarem.

Crie um recurso CertificateAuthority e guarde-o como um ficheiro YAML denominado 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

Substitua as seguintes variáveis:

Variável	Descrição
`SUB_CA_NAME`	O nome da subCA.
`USER_PROJECT_NAMESPACE`	O ID do projeto onde quer importar a imagem.
`COMMON_NAME`	O nome comum do certificado da AC.
`DURATION`	O tempo de vida pedido do certificado da AC
`SECRET_NAME`	O nome do segredo do Kubernetes que contém a chave privada e o certificado da CA assinado.

As seguintes variáveis são valores opcionais:

Variável	Descrição
`RENEW_BEFORE`	O tempo de rotação antes de o certificado da CA expirar.
`ORGANIZATION`	Organização a usar no certificado.
`ORGANIZATIONAL_UNITS`	Unidades organizacionais a usar no certificado.
`COUNTRIES`	Países a usar no certificado.
`LOCALITIES`	Cidades a usar no certificado.
`PROVINCES`	Estados ou províncias a usar no certificado.
`STREET_ADDRESSES`	Moradas a usar no certificado.
`POSTAL_CODES`	Códigos postais a usar no certificado.
`EXTENDED_KEY_USAGE`	A utilização alargada da chave para o certificado. Se for fornecido, os valores permitidos são `serverAuth` e `clientAuth`.
`KEY_ALGORITHYM`	O algoritmo de chave privada usado para este certificado. Os valores permitidos são `RSA`, `Ed25519` ou `ECDSA`. Se o tamanho não for fornecido, o valor predefinido é 256 para `ECDSA` e 2048 para `RSA`. O tamanho da chave é ignorado para `Ed25519`.
`KEY_SIZE`	O tamanho, em bits, da chave privada deste certificado depende do algoritmo. `RSA` permite 2048, 3072, 4096 ou 8192 (predefinição: 2048). `ECDSA` permite 256, 384 ou 521 (predefinição 256). `Ed25519` ignora o tamanho.
`ACME_ENABLED`	Se estiver definido como `true`, a AC é executada no modo ACME e produz o URL do servidor ACME. Em seguida, pode usar o cliente e o protocolo ACME para gerir certificados.

Aplique o recurso personalizado à sua instância do Distributed Cloud:

kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG

É gerado um CSR para a AC subordinada no servidor da API GDC Management. Tem de transferir o CSR e assiná-lo. Depois de assinado, pode carregar o certificado assinado para o servidor da API Google Data Commons Management.
Recolha os pedidos de assinatura de certificados (CSR) do seu ambiente de nuvem distribuída:
```
kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
```
O comando gera um ficheiro CSR denominado sub_ca.csr no diretório atual. Este ficheiro contém um CSR para um certificado de AC X.509.
Use a CA de raiz do cliente para pedir certificados de CA assinados para o ficheiro sub_ca.csr.
Para um pedido de assinatura de certificado aprovado, tem de obter um certificado de AC assinado pela AC de raiz do cliente. Armazene o certificado no ficheiro sub_ca.crt no diretório atual.
Se aplicável, obtenha o certificado da CA raiz do cliente e armazene-o no ficheiro ca.crt no diretório atual.
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, valide o CN no certificado:
```
openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject: CN"
```

Gere o spec para aplicar o patch ao recurso CertificateAuthority:

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

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

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

Edite o campo spec do recurso CertificateAuthority:

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

Valide a prontidão da sub CA do tipo "traga a sua própria" (BYO). Normalmente, a AC demora cerca de 40 minutos a ficar pronta:

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

O resultado tem um aspeto semelhante ao seguinte:

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

Verifique a data de validade dos certificados da AC assinados:

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

Apresente ACs

Para apresentar uma lista de todos os recursos do serviço de autoridade de certificação na sua instância isolada do Distributed Cloud, faça o seguinte:

Use o parâmetro certificateauthorities para listar todos os recursos CertificateAuthority:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

O resultado tem um aspeto semelhante ao seguinte:

   NAMESPACE    NAME              READY   REASON   AGE
   foo          root-ca           True    Ready    7h24m
   foo          sub-ca            True    Ready    7h24m

Crie uma autoridade de certificação subordinada Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Obtenha o ficheiro kubeconfig

Crie uma sub-CA gerida

Crie uma CA subordinada a partir de uma CA externa

Apresente ACs

Crie uma autoridade de certificação subordinada