Usar autoridades de certificação de cluster personalizadas

As autoridades certificadoras (CAs) de cluster emitem e assinam certificados para ativar a autenticação e a criptografia seguras entre os componentes do cluster. Por padrão, no Google Distributed Cloud, a API Cluster cria as CAs do cluster quando você cria um novo cluster. Neste documento, descrevemos como usar suas próprias autoridades de certificação com o Google Distributed Cloud. O uso de CAs de cluster personalizadas oferece mais controle sobre a emissão e o gerenciamento dos certificados de cluster. Também é possível controlar a confiança, os parâmetros de algoritmo de criptografia, a profundidade dos certificados subordinados e a finalidade deles.

Para usar CAs personalizadas, forneça CAs raiz, que consistem em um arquivo de certificado de CA e seu arquivo de chave privada correspondente. Forneça um certificado de CA e um par de arquivos de chave para cada uma das seguintes CAs de cluster necessárias:

  • CA do etcd: o certificado de CA do etcd protege a comunicação do servidor da API Kubernetes com as réplicas do etcd e também a comunicação entre as réplicas do etcd.

  • CA de cluster: o certificado da CA do cluster protege a comunicação entre o servidor da API Kubernetes e todos os clientes internos da API Kubernetes. Os clientes incluem o kubelet, o gerenciador do controlador e o programador.

  • CA de proxy frontal: o certificado da CA de proxy frontal garante a comunicação com APIs agregadas.

É possível fornecer um par exclusivo de certificado-chave para cada AC ou reutilizar um par de chaves de certificado para mais de uma das ACs.

Os pares de chave de certificado são aplicados durante a criação do cluster (somente o método bmctl) e a rotação de CA. O recurso Custom Cluster CA funciona com todos os tipos de cluster: administrador, usuário, híbrido e autônomo.

Pré-requisitos

Você é responsável por preparar suas próprias CAs raiz de acordo com as seguintes regras:

  • CAs personalizadas são CAs raiz, cada uma consistindo em um arquivo de certificado autoassinado e um arquivo de chave privada.

  • Para seu certificado, recomendamos o uso do formato de regras de codificação diferenciadas (DER, na sigla em inglês). Consulte a recomendação X.690 para regras de codificação ASN.1. Seu arquivo de certificado precisa conter dados codificados em base64 precedidos por ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ e seguidos por ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

  • Para a chave privada, recomendamos o uso do formato Public-Key Cryptography Standards (PKCS) #1. Seu arquivo de chave precisa conter dados codificados em base64 precedidos por ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ e seguidos por ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

  • Para minimizar possíveis interrupções de cluster, as CAs personalizadas não devem expirar antes de cinco anos. Recomendamos um período de validade maior, como 10 a 30 anos.

  • Verifique se os arquivos de certificado e de chave estão na estação de trabalho do administrador em que você executa os comandos bmctl.

  • O usuário que executa comandos bmctl precisa ter acesso ao diretório em que os arquivos são armazenados. Recomendamos que você coloque os arquivos em um diretório atual usado para certificados e chaves. Por exemplo, é possível armazenar os arquivos em ~/baremetal/bmctl-workspace/.sa-keys com as chaves da conta de serviço.

  • O usuário que executa os comandos bmctl precisa ter acesso de leitura aos arquivos.

Usar uma CA personalizada durante a criação do cluster

Ao criar um cluster com bmctl, você primeiro atualiza o arquivo de configuração do cluster para descrever os recursos e as configurações dele. Para usar o recurso de CA do cluster personalizado durante a criação do cluster, há duas opções para especificar as CAs de cluster personalizadas no arquivo de configuração do cluster:

  • Especifique os caminhos dos arquivos de certificado de CA e de chave privada.
  • Especifique os caminhos apenas para os arquivos da chave privada.

Quando você especifica apenas as chaves privadas, o bmctl procura os arquivos de certificado de CA correspondentes no mesmo diretório. Os arquivos de certificado precisam ter o mesmo nome dos arquivos de chave privada correspondentes e da extensão .crt. Por exemplo, se o caminho da chave privada for /custom-ca/cluster_ca.key, bmctl espera que o caminho do certificado seja /custom-ca/cluster_ca.crt.

Em ambos os casos, os caminhos são especificados na seção de credenciais do arquivo de configuração, conforme mostrado nos exemplos abaixo.

Exemplo 1: especificar os caminhos de certificado e chave

O trecho a seguir de um arquivo de configuração de cluster mostra como especificar os caminhos para os arquivos de certificado e de chave para cada CA de cluster. Neste exemplo, o certificado de CA e os arquivos de chave estão no mesmo diretório que os arquivos de chave JSON da conta de serviço.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Exemplo 2: especificar somente caminhos de chave privada

O trecho a seguir de um arquivo de configuração de cluster mostra como especificar os caminhos somente para arquivos principais. Neste exemplo, os arquivos da chave privada da CA estão no mesmo diretório que os arquivos da chave JSON da conta de serviço. Os arquivos de certificado de CA correspondentes também precisam estar no diretório /.sa-keys. Os arquivos de certificado têm o mesmo nome de arquivo que os arquivos de chave, mas com uma extensão .crt. Portanto, o arquivo de certificado de CA do etcd tem o nome etcd_ca.crt.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Exemplo 3: reutilizar um único par de arquivos de certificado de CA e de chave

O trecho a seguir de um arquivo de configuração de cluster mostra como especificar os caminhos somente para arquivos principais. Neste exemplo, um único par de certificado-chave é usado para todas as CAs do cluster. Os arquivos do certificado de CA e da chave privada estão no diretório /custom-ca. Seguindo a convenção de nomenclatura, o nome do arquivo do certificado de CA é custom_ca.crt.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Usar uma CA personalizada durante a rotação de CA

Ao rotacionar CAs, você pode especificar os caminhos para seu certificado de CA de cluster personalizado e arquivos de chave privada. As opções que você tem são semelhantes às opções para especificar CAs de cluster personalizadas durante a criação do cluster. Ao executar o comando bmctl update credentials certificate-authorities rotate, você tem as seguintes opções:

  • Especifique os caminhos dos arquivos de certificado de CA personalizados e de chave privada.
  • Especifique os caminhos apenas para os arquivos de chave privada da CA personalizada. O arquivo de certificado de CA correspondente precisa estar no mesmo diretório, ter o mesmo nome do arquivo de chave e ter a extensão .crt.
  • Reutilize um par de certificado/chave de CA especificando o mesmo certificado e caminhos de chave para mais de uma CA de cluster.
  • Omita os argumentos para os caminhos de CA personalizados. Se você não especificar caminhos de CA personalizados ao alternar CAs, o Google Distributed Cloud cria e usa a AC de cluster padrão.

Exemplo 1: especificar caminhos de certificado de CA e de chave privada

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Substitua:

  • CLUSTER_NAME: o nome do cluster em que você quer rotacionar as CAs.
  • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador. Para o gerenciamento automático de clusters, esse arquivo é o kubeconfig do cluster.
  • CLUSTER_CA_CERT_PATH: o caminho do arquivo de certificado de CA do cluster.
  • CLUSTER_CA_KEY_PATH: o caminho do arquivo de chave privada da CA do cluster.
  • ETCD_CA_CERT_PATH: o caminho do arquivo de certificado de CA do etcd.
  • ETCD_CA_KEY_PATH: o caminho do arquivo de chave privada de CA do etcd.
  • FRONT_PROXY_CA_CERT_PATH: o caminho do arquivo de certificado do proxy frontal.
  • FRONT_PROXY_CA_KEY_PATH: o caminho do arquivo de chave privada do proxy frontal.

Exemplo 2: especificar somente caminhos de chave privada

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Substitua:

  • CLUSTER_NAME: o nome do cluster em que você quer rotacionar as CAs.
  • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador. Para o gerenciamento automático de clusters, esse arquivo é o kubeconfig do cluster.
  • CLUSTER_CA_KEY_PATH: o caminho do arquivo de chave privada da CA do cluster.
  • ETCD_CA_KEY_PATH: o caminho do arquivo de chave privada de CA do etcd.
  • FRONT_PROXY_CA_KEY_PATH: o caminho do arquivo de chave privada do proxy frontal.

ACs intermediárias

Os clusters da versão 1.29 são compatíveis com o uso de ACs intermediárias como um recurso de prévia. Esse recurso não está na mesma etapa de lançamento para todas as versões de produtos com suporte:

  • 1.29: prévia
  • 1.28: Não disponível
  • 1.16: Não disponível

Semelhante ao requisito da CA raiz para ACs personalizadas, para usar ACs intermediárias, é necessário preparar três conjuntos de ACs. Cada CA consiste em um arquivo de certificado de CA e o arquivo de chave privada correspondente. Forneça um certificado de CA e um par de arquivos de chave para cada uma das seguintes CAs de cluster necessárias:

  • CA Etcd
  • CA do cluster
  • AC front-proxy

Assim como acontece com as CAs raiz, é possível fornecer um par único de certificado-chave para cada CA ou reutilizar um par de chave de certificado para mais de uma das ACs especificando os mesmos caminhos de arquivo na configuração da AC.

Quando você usa CAs intermediárias, o arquivo de certificado de CA precisa conter toda a cadeia de certificados, o que inclui certificados das CAs intermediárias até a CA raiz. Os certificados são listados na ordem inversa de como foram assinados, com o último certificado de AC intermediária na parte superior e o certificado de AC raiz na parte inferior.

No exemplo a seguir (começando com a CA raiz na parte inferior), a ordem indica o seguinte:

  • A AC raiz assinou o certificado de AC intermediária A
  • AC intermediária A assinou o certificado de AC intermediária B
  • A cadeia continua até o certificado da CA intermediária Y final, que foi assinado pela CA intermediária-X.
-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE-----

Para continuar com este exemplo, a chave privada associada ao certificado de CA intermediário-Y precisa ser transmitida com as cadeias de certificados de CA da mesma maneira que em uma CA personalizada.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

Para verificar se o cluster está usando a AC intermediária, inspecione a contagem de certificados na chave secreta da AC do cluster:

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l