Girar certificados do Kubernetes Azure Stack Hub

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.

Importante

Esse recurso está atualmente em visualização pública. Essa versão prévia é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou podem ter restrição de recursos. Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

Pré-requisitos

Este guia pressu que você já implantou um cluster usando o mecanismo do AKS e que o cluster está em um estado bem-estar.

Planejando a rotação de certificados

Ao considerar o uso dessa funcionalidade, esteja ciente de que o plano 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 preparação com configuração igual ao ambiente de produção antes de tentar em produção.

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

  • Você precisará de acesso ao modelo de API ( ) que apimodel.json foi gerado pelos comandos ou aks-engine deployaks-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, por exemplo, as VMs devem seguir a aks-engine nomenização fornecida pelo aks-engine .

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

    • 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 de uma VM host que tenha acesso de rede ao plano de controle, por exemplo, uma VM jumpbox que reside na mesma VNet que as aks-engine rotate-certs VMs mestras.

  • Se você estiver usando em produção, é recomendável fazer um teste de rotação de certificado em um cluster que foi criado aks-engine rotate-certs 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 de testes de ponta a ponta executados pela equipe do mecanismo do AKS não pode abranger praticamente todas as configurações possíveis. Portanto, é recomendável garantir que, em um ambiente de preparação, sua configuração de cluster específica funcione antes de tentar a operação aks-engine rotate-certs em seu cluster de produção.

  • aks-engine rotate-certs não aks-engine rotate-certs compatibilidade com compatibilidade com vertida. Se você implantou com aks-engine versão 0.60.x, prefira executar o processo de rotação de certificados com a versão 0.60.x.

  • A busca de um novo conjunto de certificados Key Vault não tem suporte 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. A aks-engine rotate-certs execução de uma VM em execução no carimbo de Azure Stack 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 linux do cluster.
--location sim Local do Azure em que o cluster é implantado.
--subscription-id sim Assinatura do Azure em que o infra do cluster é implantado.
--resource-group sim Grupo de recursos do Azure em que o infra do cluster é implantado.
--client-id Depende A ID do cliente da entidade de serviço. Necessário se o método auth estiver definido como client_secret ou client_certificate.
--client-secret Depende O segredo do cliente da entidade de serviço. Necessário se o método auth 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 Forçar a execução mesmo que o Servidor de API não seja responsivo.

Etapas simples para girar certificados

Depois de ler todos os requisitos,execute 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

Solução de problemas

Se o processo de rotação de certificado for interrompido antes da conclusão devido a uma falha ou problema transitório, por exemplo, conectividade de rede, é seguro ser reprisado usando aks-engine rotate-certs 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 detalhes ao executar essa operação ou para obter mais personalização, consulte Under The Hood.

Próximas etapas