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 GKE em Bare Metal, 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 GKE em Bare Metal. 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, você fornece CAs raiz que consistem 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 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.

Você pode fornecer um par exclusivo de chave de certificado para cada CA ou reutilizar um par de certificado-chave para mais de uma das ACs.

Aplique os pares de chave de certificado durante a criação do cluster (somente 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.

  • As CAs intermediárias e subordinadas não são compatíveis.

  • 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 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.

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.
  • Reutilizar um par de chave de certificado 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 as CAs, o GKE em Bare Metal criará e usará a CA 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.