Partilhar via

Rotação de certificados no Serviço Kubernetes do Azure (AKS)

  • Artigo

O Azure Kubernetes Service (AKS) utiliza certificados para autenticação com muitos dos respetivos componentes. Os clusters com controle de acesso baseado em função do Azure (Azure RBAC) que foram criados após março de 2022 são habilitados com a rotação automática de certificados. Talvez seja necessário alternar periodicamente esses certificados por motivos de segurança ou de política. Por exemplo, você pode ter uma política para alternar todos os seus certificados a cada 90 dias.

Nota

A rotação automática de certificados é ativada por padrão apenas para clusters AKS habilitados para RBAC.

Este artigo mostra como funciona a rotação de certificados no cluster AKS.

Antes de começar

Este artigo requer a CLI do Azure versão 2.0.77 ou posterior. Executar az --version para localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).

Certificados AKS, Autoridades de Certificação e Contas de Serviço

O AKS gera e usa os seguintes certificados, Autoridades de Certificação (CA) e Contas de Serviço (SA):

  • O servidor de API do AKS cria uma autoridade de certificação chamada CA de cluster.
  • O servidor de API tem uma CA de Cluster, que assina certificados para comunicação unidirecional do servidor de API para kubelets.
  • Cada kubelet cria uma Solicitação de Assinatura de Certificado (CSR), que a CA do Cluster assina, para comunicação do kubelet com o servidor de API.
  • O agregador de API usa a CA de cluster para emitir certificados para comunicação com outras APIs. O agregador de API também pode ter sua própria autoridade de certificação para emitir esses certificados, mas atualmente usa a autoridade de certificação de cluster.
  • Cada nó usa um token SA, que a autoridade de certificação do cluster assina.
  • O kubectl cliente tem um certificado para se comunicar com o cluster AKS.

A Microsoft mantém todos os certificados mencionados nesta seção, exceto o certificado de cluster.

Nota

  • Os clusters AKS criados antes de maio de 2019 têm certificados que expiram após dois anos.
  • Os clusters AKS criados após maio de 2019 têm certificados de CA de cluster que expiram após 30 anos.

Você pode verificar quando o cluster foi criado usando o kubectl get nodes comando, que mostra a idade dos pools de nós.

Verificar datas de validade do certificado

Verificar a data de expiração do certificado de cluster

  • Verifique a data de expiração do certificado de cluster usando o kubectl config view comando.

    kubectl config view --raw -o jsonpath="{.clusters[?(@.name == '')].cluster.certificate-authority-data}" | base64 -d | openssl x509 -text | grep -A2 Validity

Verifique a data de expiração do certificado do servidor de API

  • Verifique a data de expiração do certificado do servidor de API usando o seguinte curl comando.

    curl https://{apiserver-fqdn} -k -v 2>&1 | grep expire

Verifique a data de expiração do certificado do nó do agente VMAS

  • Verifique a data de expiração do certificado do nó do agente do VMAS usando o az vm run-command invoke comando.

    az vm run-command invoke --resource-group MC_rg_myAKSCluster_region --name vm-name --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"

Verificar a expiração do certificado para o nó do agente do conjunto de escala da máquina virtual

  • Verifique a data de expiração do certificado do nó do agente do conjunto de escala da máquina virtual usando o az vmss run-command invoke comando.

    az vmss run-command invoke --resource-group "MC_rg_myAKSCluster_region" --name "vmss-name" --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in  /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate" --query "value[0].message"

Autorrotação do certificado

Para que o AKS gire automaticamente certificados que não sejam de CA, o cluster deve ter o Bootstrapping TLS, que é habilitado por padrão em todas as regiões do Azure.

Nota

  • Se você tiver um cluster existente, será necessário atualizá-lo para habilitar a Rotação Automática de Certificados.
  • Não desative o Bootstrap para manter a rotação automática ativada.
  • Se o cluster estiver em um estado interrompido durante a rotação do certificado automático, somente os certificados do plano de controle serão girados. Nesse caso, você deve recriar o pool de nós após a rotação de certificados para iniciar a rotação de certificados do pool de nós.

Para quaisquer clusters AKS criados ou atualizados após março de 2022, o Serviço Kubernetes do Azure gira automaticamente certificados que não sejam de CA no plano de controle e nos nós do agente dentro de 80% do tempo válido do certificado do cliente antes de expirarem, sem tempo de inatividade para o cluster.

Como verificar se o pool de nós do agente atual está habilitado para inicialização TLS?

  1. Verifique se o cluster tem a Inicialização TLS habilitada navegando para um dos seguintes caminhos:

    • Em um nó Linux: /var/lib/kubelet/bootstrap-kubeconfig ou /host/var/lib/kubelet/bootstrap-kubeconfig
    • Em um nó do Windows: C:\k\bootstrap-config

    Para obter mais informações, consulte Conectar-se aos nós de cluster do Serviço Kubernetes do Azure para manutenção ou solução de problemas.

    Nota

    O caminho do arquivo pode mudar à medida que as versões do Kubernetes evoluem.

  2. Depois que uma região estiver configurada, crie um novo cluster ou atualize um cluster existente para definir a rotação automática para o certificado de cluster. Você precisa atualizar o plano de controle e o pool de nós para habilitar esse recurso.

Girar manualmente os certificados de cluster

Aviso

Girar seus certificados usando az aks rotate-certs recria todos os nós, conjuntos de escala de máquina virtual e discos e pode causar até 30 minutos de tempo de inatividade para seu cluster AKS.

  1. Conecte-se ao cluster usando o az aks get-credentials comando.

    az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

  2. Gire todos os certificados, CAs e SAs no cluster usando o az aks rotate-certs comando.

    az aks rotate-certs --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

    Importante

    Pode levar até 30 minutos para az aks rotate-certs ser concluído. Se o comando falhar antes de concluir, use az aks show para verificar se o status do cluster é Certificado Rotativo. Se o cluster estiver em um estado de falha, execute az aks rotate-certs novamente para girar seus certificados novamente.

  3. Verifique se os certificados antigos não são mais válidos usando qualquer kubectl comando, como kubectl get nodes.

    kubectl get nodes

    Se você não tiver atualizado os certificados usados pelo kubectl, verá um erro semelhante à saída de exemplo a seguir:

    Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")

  4. Atualize o certificado usado kubectl usando o az aks get-credentials comando com o --overwrite-existing sinalizador.

    az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME --overwrite-existing

  5. Verifique se os certificados foram atualizados usando o kubectl get comando.

    kubectl get nodes

    Nota

    Se você tiver algum serviço executado em cima do AKS, talvez seja necessário atualizar seus certificados.

Próximos passos

Este artigo mostrou como girar manual e automaticamente seus certificados de cluster, CAs e SAs. Para obter mais informações, consulte Práticas recomendadas para segurança de cluster e atualizações no Serviço Kubernetes do Azure (AKS).