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 ACs do cluster quando você cria um novo cluster. Neste documento, descrevemos como usar suas próprias autoridades certificadoras 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 ACs personalizadas, você fornece ACs raiz, que consistem em um arquivo de certificado de AC e o arquivo de chave privada correspondente. Forneça um par de arquivos de chave/certificado de AC para cada uma das seguintes ACs de cluster obrigató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 certificados/chaves em mais de uma AC.

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

Observação :ao criar um cluster de usuário com bmctl, normalmente você remove a seção de credenciais do arquivo de configuração do cluster. Para especificar CAs de cluster personalizadas ao criar um cluster de usuário, especifique apenas o certificado de CA de cluster personalizado e os caminhos de chave privada na seção de credenciais.

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 do certificado e da chave estão na estação de trabalho do administrador em que você executa 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.

Observação: para um cluster de usuário, remova a conta de serviço e os caminhos da chave SSH da seção de credenciais.

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.

Observação: para um cluster de usuário, remova a conta de serviço e os caminhos da chave SSH da seção de credenciais.

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 ACs de 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.

Observação: para um cluster de usuário, remova a conta de serviço e os caminhos da chave SSH da seção de credenciais.

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 certificados/chave de AC especificando os mesmos caminhos de chave e certificado para mais de uma AC de cluster.
• Omita os argumentos para os caminhos de CA personalizados. Se você não especificar caminhos de AC personalizados ao alternar as ACs, o Google Distributed Cloud vai criar e usar 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

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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

• 1.29: pré-lançamento
• 1.28: não disponível
• 1.16: não disponível

Assim como o requisito de AC raiz para ACs personalizadas, para usar ACs intermediárias, você precisa preparar três conjuntos de ACs. Cada AC consiste em um arquivo de certificado de AC e o arquivo de chave privada correspondente. Forneça um par de arquivos de chave/certificado de AC para cada uma das seguintes ACs de cluster obrigatórias:

• CA Etcd
• AC do cluster
• AC do proxy frontal

Assim como nas ACs raiz, é possível fornecer um par de chaves de certificado exclusivo para cada AC ou reutilizar um par de chaves de certificado para mais de uma AC especificando os mesmos caminhos de arquivo na configuração da AC.

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

No exemplo abaixo (começando com a AC raiz na parte de baixo), a ordem indica o seguinte:

• A AC raiz assinou o certificado da AC intermediária A
• Uma AC intermediária-A assinou o certificado da AC intermediária B
• A cadeia continua até o certificado da AC intermediária Y, que foi assinado pela AC 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 AC intermediária Y precisa ser transmitida com as cadeias de certificado da AC da mesma forma que em uma AC 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 no secret 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