Girar certificados kubernetes usando o mecanismo do AKS no Azure Stack Hub

  • Artigo

Este documento fornece diretrizes sobre como girar certificados em um cluster existente do Mecanismo do AKS e recomendações para usar a adoção aks-engine rotate-certs como uma ferramenta.

Pré-requisitos

Este guia pressupõe que você já implantou um cluster usando o mecanismo do AKS e que o cluster está em um estado íntegro.

Planejando a rotação de certificados

Ao considerar o uso dessa funcionalidade, lembre-se de que o painel de controle do Kubernetes ficará indisponível durante as etapas de atualização, validação e reinicialização. Planeje essa operação de manutenção adequadamente. Além disso, planeje executar essa operação em um ambiente de preparo com configuração igual ao ambiente de produção antes de tentar em produção.

Examine as seguintes considerações antes de tentar esta operação:

Observação

Para o AKSe versão 0.75.3 e superior, os comandos para rotação de certificado começam com aks-engine-azurestack em vez de aks-engine.

  • Você precisará de acesso ao modelo de API (apimodel.json) que foi gerado pelos comandos aks-engine deploy ou aks-engine generate. Por padrão, esse arquivo é colocado em um diretório relativo, como _output/<clustername>/.

  • Uma aks-engine rotate-certs operação causa tempo de inatividade do servidor de API.

  • aks-engine rotate-certs espera um modelo de API que esteja em conformidade com o estado atual do cluster. aks-engine rotate-certs executa comandos remotos nos nós de cluster e usa as informações do modelo de API para estabelecer uma conexão SSH segura. aks-engine rotate-certs também depende de alguns recursos a serem nomeados de acordo com a implantação original aks-engine , por exemplo, as VMs devem seguir a nomenclatura fornecida por aks-engine.

  • aks-engine rotate-certs depende de uma conexão de trabalho com o plano de controle de cluster durante a rotação de certificados:

    • Para validar cada etapa do processo.
    • Para reiniciar/recriar recursos de cluster, como pods do sistema kube e tokens de conta de serviço.

    Se você estiver girando os certificados de um cluster em uma VNet fechada para acesso externo, deverá executar aks-engine rotate-certs a partir de uma VM de host que tenha acesso de rede ao painel de controle, por exemplo, uma VM jumpbox que reside na mesma VNet que as VMs master.

  • Se você estiver usando aks-engine rotate-certs em produção, é recomendável preparar um teste de rotação de certificado em um cluster criado com as mesmas especificações. Ou seja, o cluster é criado com a mesma configuração de cluster, a mesma versão da ferramenta de linha de comando do mecanismo do AKS e o mesmo conjunto de complementos habilitados que o cluster de produção antes de executar a rotação do certificado. O mecanismo do AKS dá suporte a diferentes configurações de cluster e à extensão dos testes de ponta a ponta que a equipe do mecanismo do AKS executa não pode praticamente cobrir todas as configurações possíveis. Portanto, é recomendável que você garanta em um ambiente de preparo que sua configuração de cluster específica funcione aks-engine rotate-certs antes de tentar a operação no cluster de produção.

  • aks-engine rotate-certsnão garante a compatibilidade com versões anteriores. Se você implantou com o aks-engine versão 0.60.x, você deve preferir executar o processo de rotação de certificado com a versão 0.60.x.

  • Não há suporte para buscar um novo conjunto de certificados de Key Vault neste momento.

  • Use uma conexão de rede confiável. aks-engine rotate-certs requer a execução de vários comandos remotos, que estão sujeitos a possíveis falhas, principalmente se a conexão com os nós de cluster não for confiável. Executar aks-engine rotate-certs a partir de uma VM em execução no selo do Azure Stack de destino pode reduzir a ocorrência de problemas transitórios.

Parâmetros

Parâmetro Obrigatório Descrição
--api-model sim Caminho relativo para o modelo de API (definição de cluster) que declara a configuração de cluster esperada.
--ssh-host sim FQDN (nome de domínio totalmente qualificado) ou endereço IP de um ouvinte SSH que pode alcançar todos os nós no cluster.
--linux-ssh-private-key sim Caminho para uma chave SSH privada válida para acessar os nós do Linux do cluster.
--location sim Local do Azure em que o cluster é implantado.
--subscription-id sim Assinatura do Azure em que a infra do cluster é implantada.
--resource-group sim Grupo de recursos do Azure em que a infra do cluster é implantada.
--client-id Depende A ID do cliente da entidade de serviço. Obrigatório se o método de autenticação estiver definido como client_secret ou client_certificate.
--client-secret Depende O segredo do cliente da entidade de serviço. Obrigatório se o método de autenticação estiver definido como client_secret.
--azure-env Depende O nome da nuvem de destino. Opcional se a nuvem de destino for o AzureCloud.
--certificate-profile não Caminho relativo para um arquivo JSON que contém o novo conjunto de certificados.
-Force não Force a execução mesmo que o Servidor de API não responda.

Etapas simples para girar certificados

Para as versões do Mecanismo do AKS 0.75.3 e superiores, depois de ler todos os requisitos, execute aks-engine-azurestack rotate-certs com os argumentos apropriados (veja abaixo).

Para as versões do Mecanismo do AKS 0.73.0 e inferiores, depois de ler todos os requisitos, execute aks-engine rotate-certs com os argumentos apropriados:

./bin/aks-engine rotate-certs \
  --location <resource-group-location> \
  --api-model <generated-apimodel.json> \
  --linux-ssh-private-key <private-SSH-key> \
  --ssh-host <apiserver-URI> \
  --resource-group <resource-group-name> \
  --client-id <service-principal-id> \
  --client-secret <service-principal-secret> \
  --subscription-id <subscription-id> \
  --azure-env <cloud-name>

Por exemplo:

./bin/aks-engine rotate-certs \
  --location "westus2" \
  --api-model "_output/my-cluster/apimodel.json" \
  --linux-ssh-private-key "~/.ssh/id_rsa" \
  --ssh-host "my-cluster.westus2.cloudapp.azure.com"\
  --resource-group "my-cluster" \
  --client-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --client-secret "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --subscription-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --azure-env "AzureStackCloud" # optional if targeting AzureCloud

front-proxy Girar certificados

Observação

Para o AKSe versão 0.75.3 e superior, os comandos para rotação de certificado começam com aks-engine-azurestack em vez de aks-engine.

O mecanismo do AKS cria uma PKI separada para o front-proxy como parte do processo de inicialização de nó e os entrega a todos os nós por meio etcdde . Para reutilizar efetivamente essa funcionalidade, rotate-certs é necessário substituir os certificados armazenados em etcd. Os front-proxy certificados expiram após 30 anos. aks-engine rotate-certs gira os certificados de proxy frontal.

Solução de problemas

Observação

Para o AKSe versão 0.75.3 e superior, os comandos para rotação de certificado começam com aks-engine-azurestack em vez de aks-engine.

Se o processo de rotação de certificados for interrompido antes da conclusão devido a uma falha ou problema transitório, por exemplo, conectividade de rede, é seguro executar aks-engine rotate-certs novamente usando o --force sinalizador.

Observe também que aks-engine rotate-certs registra a saída de cada etapa no arquivo /var/log/azure/rotate-certs.log (Linux) e c:\\k\\rotate-certs.log (Windows).

Para obter mais informações sobre o que acontece nos bastidores ao executar essa operação ou para personalização adicional, consulte Em The Hood.

Próximas etapas