Use autoridades de certificação de cluster personalizadas

As autoridades de certificação (ACs) do cluster emitem e assinam certificados para permitir a autenticação e a encriptação seguras entre os componentes do cluster. Por predefinição, no Google Distributed Cloud, a API Cluster cria as ACs do cluster quando cria um novo cluster. Este documento descreve como pode usar as suas próprias autoridades de certificação com o Google Distributed Cloud. A utilização de ACs de cluster personalizadas dá-lhe mais controlo sobre a emissão e a gestão dos certificados de cluster. Também pode controlar a confiança, os parâmetros do algoritmo de encriptação, a profundidade dos certificados subordinados e a respetiva finalidade.

Para usar ACs personalizadas, faculta ACs de raiz, que consistem num ficheiro de certificado de AC e no ficheiro de chave privada correspondente. Fornece um par de ficheiros de chave e certificado da AC para cada uma das seguintes ACs de cluster necessárias:

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

  • AC do cluster: o certificado da AC do cluster protege a comunicação entre o servidor da API Kubernetes e todos os clientes da API Kubernetes internos. Os clientes incluem o kubelet, o gestor de controladores e o agendador.

  • AC do proxy frontal: o certificado da AC do proxy frontal protege a comunicação com as APIs agregadas.

Pode fornecer um par de chave-certificado exclusivo para cada AC ou pode reutilizar um par de chave-certificado para mais do que uma das ACs.

Aplica os pares de chave-certificado durante a criação do cluster (apenas o método bmctl) e a rotação da CA. A funcionalidade de CA de cluster personalizado funciona com todos os tipos de clusters: administrador, utilizador, híbrido e autónomo.

Pré-requisitos

É responsável por preparar as suas próprias ACs de raiz de acordo com as seguintes regras:

  • As CAs personalizadas são CAs de raiz, cada uma constituída por um ficheiro de certificado autoassinado e um ficheiro de chave privada.

  • Para o seu certificado, recomendamos que use o formato das Regras de Codificação Distintas (DER) (consulte a recomendação X.690 para regras de codificação ASN.1). O ficheiro de certificado deve conter dados codificados em base64 precedidos por ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ e seguidos por ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

  • Para a chave privada, recomendamos que use o formato Public-Key Cryptography Standards (PKCS) #1. O ficheiro de chave deve conter dados codificados em base64 precedidos por ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ e seguidos por ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

  • Para minimizar a potencial interrupção do cluster, as ACs personalizadas não devem expirar antes de cinco anos. Recomendamos um período de validade mais longo, como 10 a 30 anos.

  • Certifique-se de que os ficheiros de certificado e chave estão na estação de trabalho de administração onde executa os comandos bmctl.

  • O utilizador que executa comandos bmctl tem de ter acesso ao diretório no qual armazena os ficheiros. Recomendamos que coloque os ficheiros num diretório existente usado para certificados e chaves. Por exemplo, pode armazenar os ficheiros no ~/baremetal/bmctl-workspace/.sa-keys juntamente com as chaves da conta de serviço.

  • O utilizador que executa comandos bmctl tem de ter acesso de leitura aos ficheiros.

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

Quando cria um cluster com o bmctl, primeiro atualiza o ficheiro de configuração do cluster para descrever as funcionalidades e as definições do cluster. Para usar a funcionalidade de ACs de cluster personalizadas durante a criação do cluster, tem duas opções para especificar as ACs de cluster personalizadas no ficheiro de configuração do cluster:

  • Especifique os caminhos para os ficheiros de certificado da AC e os ficheiros de chave privada
  • Especifique apenas os caminhos para os ficheiros de chaves privadas

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

Em qualquer dos casos, os caminhos são especificados na secção de credenciais do ficheiro de configuração, conforme mostrado nos exemplos seguintes.

Exemplo 1: especifique os caminhos dos certificados e das chaves

O excerto seguinte de um ficheiro de configuração do cluster mostra como especificar os caminhos para os ficheiros de certificado e de chave para cada CA do cluster. Neste exemplo, os ficheiros de chave e certificado da AC estão no mesmo diretório que os ficheiros 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: especifique apenas os caminhos das chaves privadas

O excerto seguinte de um ficheiro de configuração do cluster mostra como especificar apenas os caminhos para os ficheiros de chaves. Neste exemplo, os ficheiros de chave privada da AC estão no mesmo diretório que os ficheiros de chave JSON da conta de serviço. Os ficheiros de certificado de AC correspondentes também têm de estar no diretório /.sa-keys. Os ficheiros de certificado têm o mesmo nome de ficheiro que os ficheiros de chave, mas com uma extensão .crt. Assim, o ficheiro do certificado da AC 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: reutilize um único par de ficheiros de chave e certificado da AC

O excerto seguinte de um ficheiro de configuração do cluster mostra como especificar apenas os caminhos para os ficheiros de chaves. Neste exemplo, é usado um único par de chave-certificado para todas as ACs do cluster. Os ficheiros de chave privada e certificado da AC estão ambos no diretório /custom-ca. Seguindo a convenção de nomenclatura, o nome do ficheiro do certificado da AC é 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
...

Use uma AC personalizada durante a rotação de ACs

Quando roda as ACs, pode especificar os caminhos para os ficheiros de chave privada e certificado da AC do cluster personalizado. As opções disponíveis são semelhantes às opções para especificar ACs de clusters personalizados durante a criação de clusters. Quando executa o comando bmctl update credentials certificate-authorities rotate, tem as seguintes opções:

  • Especifique os caminhos para os ficheiros de certificado da AC personalizada e os ficheiros de chave privada.
  • Especifique apenas os caminhos para os ficheiros de chave privada da AC personalizada. O ficheiro de certificado da AC correspondente tem de estar no mesmo diretório, ter o mesmo nome que o ficheiro de chave e ter uma extensão de ficheiro .crt.
  • Reutilize um par de chave-certificado da CA especificando os mesmos caminhos de certificado e chave para mais do que uma CA do cluster.
  • Omita os argumentos para os caminhos de AC personalizados. Se não especificar caminhos de AC personalizados quando roda as ACs, o Google Distributed Cloud cria e usa a AC do cluster padrão.

Exemplo 1: especifique os caminhos do certificado da AC e da 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 o seguinte:

  • CLUSTER_NAME: o nome do cluster para o qual quer rodar as ACs.
  • ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador. Para clusters autogeridos, este ficheiro é o ficheiro kubeconfig do cluster.
  • CLUSTER_CA_CERT_PATH: o caminho do ficheiro do certificado da AC do cluster.
  • CLUSTER_CA_KEY_PATH: o caminho do ficheiro de chave privada da AC do cluster.
  • ETCD_CA_CERT_PATH: o caminho do ficheiro do certificado da AC do etcd.
  • ETCD_CA_KEY_PATH: o caminho do ficheiro da chave privada da AC do etcd.
  • FRONT_PROXY_CA_CERT_PATH: o caminho do ficheiro de certificado do proxy frontal.
  • FRONT_PROXY_CA_KEY_PATH: o caminho do ficheiro de chave privada do proxy frontal.

Exemplo 2: especifique apenas os caminhos das chaves privadas

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 o seguinte:

  • CLUSTER_NAME: o nome do cluster para o qual quer rodar as ACs.
  • ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador. Para clusters autogeridos, este ficheiro é o ficheiro kubeconfig do cluster.
  • CLUSTER_CA_KEY_PATH: o caminho do ficheiro de chave privada da AC do cluster.
  • ETCD_CA_KEY_PATH: o caminho do ficheiro da chave privada da AC do etcd.
  • FRONT_PROXY_CA_KEY_PATH: o caminho do ficheiro de chave privada do proxy frontal.

ACs intermédias

Os clusters da versão 1.29 suportam a utilização de ACs intermédias como uma capacidade de pré-visualização. Esta capacidade não está na mesma fase de lançamento para todas as versões de produtos suportadas:

Tal como no requisito da AC raiz para ACs personalizadas, para usar ACs intermédias, tem de preparar três conjuntos de ACs. Cada AC consiste num ficheiro de certificado da AC e no ficheiro de chave privada correspondente. Fornece um par de ficheiros de chave e certificado da AC para cada uma das seguintes ACs de cluster necessárias:

  • AC etcd
  • CA de cluster
  • CA de proxy frontal

Tal como acontece com as ACs de raiz, pode fornecer um par de chave-certificado exclusivo para cada AC ou pode reutilizar um par de chave-certificado para mais do que uma das ACs especificando os mesmos caminhos de ficheiros na configuração da AC.

Quando usa ACs intermédias, o ficheiro de certificado da AC deve conter toda a cadeia de certificados, que inclui certificados das ACs intermédias até à AC de raiz. Os certificados são apresentados por ordem inversa da forma como foram assinados, com o último certificado da CA intermédia na parte superior e o certificado da CA de raiz na parte inferior.

No exemplo seguinte (começando pela AC raiz na parte inferior), a ordem indica o seguinte:

  • A CA de raiz assinou o certificado da CA intermédia A
  • A CA intermédia A assinou o certificado da CA intermédia B
  • A cadeia continua até ao certificado final da AC Intermediate-Y, que foi assinado pela AC Intermediate-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 da AC Intermediate-Y deve ser transmitida juntamente com as cadeias de certificados da AC da mesma forma que numa AC personalizada.

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

Para verificar se o cluster está a usar a AC intermédia, inspecione a quantidade de certificados no segredo 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