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

O Azure Kubernetes Service (AKS) utiliza certificados para autenticação com muitos dos respetivos componentes. É necessário substituir periodicamente esses certificados por razões de segurança ou políticas. Este artigo mostra como funciona a rotação de certificados no cluster AKS.

Pré-requisitos

Este artigo requer a CLI do Azure versão 2.0.77 ou posterior. Verifique sua versão usando o az --version comando. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).
Configure kubectl para se ligar ao seu cluster AKS usando o az aks get-credentials comando:
```
az aks get-credentials --resource-group <resource-group> --name <cluster-name>
```

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 API do AKS cria uma CA chamada Cluster CA, que assina certificados para comunicação unidirecional do servidor API para o kubelet.
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ó agente utiliza um token SA, que é assinado pelo CA do Cluster.
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.

Datas de validade dos certificados

Importante

A data de expiração dos seus certificados depende de quando o seu cluster AKS foi criado:

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.

Podes verificar quando o teu cluster foi criado usando o kubectl get nodes comando, que te mostra os Age nós dos teus agentes.

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 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 agente no nó da máquina virtual (VM)

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

Parâmetros-chave neste comando: - --resource-group <node-resource-group>: O grupo de recursos que contém o nó agente da VM. - --name <vm-name>: O nome do nó agente VM. - --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate": O script que recupera a data de expiração do certificado do servidor API localizado em /etc/kubernetes/certs/apiserver.crt.
```
az vm run-command invoke --resource-group <node-resource-group> --name <vm-name> --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
```

Verifique a expiração do certificado para o nó de agente do Conjunto de Escala de Máquinas Virtuais do Azure

Verifique a data de expiração do certificado de nó do agente Azure Virtual Machine Scale Set usando o az vmss run-command invoke comando.

Parâmetros principais neste comando: - --resource-group <node-resource-group>: O grupo de recursos que contém o nó agente do Conjunto de Escalas de Máquinas Virtuais do Azure. - --name <vmss-name>: O nome do Azure Virtual Machine Scale Set. - --instance-id 1: O ID da instância do nó agente do Azure Virtual Machine Scale Set. - --scripts "openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate": O script que recupera a data de expiração do certificado cliente kubelet localizado em /var/lib/kubelet/pki/kubelet-client-current.pem.
```
az vmss run-command invoke --resource-group <node-resource-group> --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"
```

Girar manualmente os certificados de cluster

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 <cluster-name>
```
Importante

O az aks rotate-certs comando recria todos os teus nós agente, Conjuntos de Escala da Máquina Virtual Azure e discos. Este comando pode também causar até 30 minutos de inatividade no seu cluster AKS. Se o comando falhar antes de ser concluído, use o comando [az aks show][az-aks-show] para verificar que o estado do cluster é Certificate Rotating. Se o cluster estiver em estado falhado, reexecute o az aks rotate-certs comando para rodar novamente os seus certificados.
Verifique se os certificados antigos já não são válidos usando qualquer kubectl comando. O exemplo seguinte utiliza o kubectl get nodes comando:
```
kubectl get nodes
```
Se não atualizou os certificados usados por kubectl, verá um erro semelhante ao seguinte exemplo de saída:
```
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")
```
Atualize o certificado utilizado por kubectl através do comando az aks get-credentials com a opção --overwrite-existing.
```
az aks get-credentials --resource-group <resource-group> --name <cluster-name> --overwrite-existing
```
Verifique se os certificados são atualizados usando o kubectl get comando.
```
kubectl get nodes
```

Se tiveres algum serviço que funcione sobre o AKS, talvez precises de atualizar os certificados deles também.

Rodar o certificado de servidor do kubelet

Quando gira o certificado de serviço do kubelet, o AKS permite o Bootstrapping de Segurança da Camada de Transporte (TLS) para o servidor kubelet tanto para a inicialização como para a rotação de certificados de serviço assinados pela CA do Cluster.

Limitações para a rotação de certificados de serviço do kubelet

Suportado no Kubernetes versão 1.27 e superior.
Não há suporte quando o pool de nós está usando um instantâneo do pool de nós com base em qualquer imagem de nó anterior a 202501.12.0.
Não podes ativar esta funcionalidade manualmente. A rotação de certificados de serviço Kubelet está ativada por defeito nos pools de nós existentes quando realizam a sua primeira atualização para qualquer versão Kubernetes 1.27 ou superior. A rotação de certificados de atendimento do Kubelet está ativada por padrão em novos pools de nós usando Kubernetes versão 1.27 ou superior. Para ver se a rotação de certificados de serviço do kubelet está ativada na sua região, verifique as versões do AKS.

Verifique se a rotação do certificado de serviço kubelet está ativada

Cada nó com o recurso ativado recebe automaticamente o rótulo kubernetes.azure.com/kubelet-serving-ca=cluster.

Verifique se as etiquetas estão definidas usando o kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca comando.
```
kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca
```
A saída deve mostrar a etiqueta kubernetes.azure.com/kubelet-serving-ca com o valor cluster de cada nó agente.

Verificar se o Kubelet TLS Bootstrapping está a funcionar

Verifica se o processo de arranque está a decorrer usando o kubectl get comando.

kubectl get csr --field-selector=spec.signerName=kubernetes.io/kubelet-serving

No resultado, todos os CSRs em serviço devem estar no Approved,Issued estado, o que indica que o CSR foi aprovado e recebeu um certificado assinado. As CSRs de serviço têm um nome de signatário de kubernetes.io/kubelet-serving. Por exemplo:

NAME        AGE    SIGNERNAME                                    REQUESTOR                    REQUESTEDDURATION   CONDITION
csr-1ab2c   113s   kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:uoxr9r      none              Approved,Issued
csr-defgh   111s   kubernetes.io/kubelet-serving                 system:node:akswinp7000000   none              Approved,Issued
csr-ij3kl   46m    kubernetes.io/kubelet-serving                 system:node:akswinp6000000   none              Approved,Issued
csr-mn4op   46m    kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:ho7zyu      none              Approved,Issued

Verifique se o kubelet está a usar um certificado obtido do servidor TLS Bootstrapping

Confirme que o kubelet está a usar um certificado de serviço assinado pela CA do Cluster usando o kubectl debug comando.
```
kubectl debug node/<node> -ti --image=mcr.microsoft.com/azurelinux/base/core:3.0 -- ls -l /host/var/lib/kubelet/kubelet-server-current.pem
```
Se existir um kubelet-server-current.pem symlink, então o kubelet iniciou ou rodou o seu próprio certificado de servidor, e a CA do Cluster assinou o mesmo.

Desativar a rotação do certificado de serviço kubelet

Desative a rotação de certificados de serviço do kubelet, atualizando o pool de nós usando o comando az aks nodepool update com a tag aks-disable-kubelet-serving-certificate-rotation=true.
```
az aks nodepool update --cluster-name <cluster-name> --resource-group <resource-group> --name <node-pool-name> --tags aks-disable-kubelet-serving-certificate-rotation=true
```

Reimagina os teus nós usando uma atualização de imagem de nós ou escalando o pool para zero instâncias e depois volta ao valor desejado.

Rotação automática de certificados

Tenha em mente as seguintes considerações ao utilizar a autorrotação de certificados:

Se tiver um cluster existente, tem de atualizar esse cluster para permitir a autorrotação de certificados.
Não desatives o TLS Bootstrap para manter a autorrotação de certificados ativada.
Se o cluster estiver num estado parado durante a autorrotação dos certificados, apenas os certificados do plano de controlo são renovados. 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 AKS renova automaticamente certificados não-CA tanto no plano de controlo como nos nós do agente, dentro de 80% do tempo de validade do certificado do cliente antes de expirar, sem tempo de inatividade para o cluster.

Verifique se o TLS Bootstrapping está ativado no atual pool de nós do agente

Verifique se o seu cluster tem o TLS Bootstrapping ativado navegando para um dos seguintes caminhos:
- Numa node Linux: /var/lib/kubelet/bootstrap-kubeconfig ou /host/var/lib/kubelet/bootstrap-kubeconfig
- Num nó Windows: C:\k\bootstrap-config
Para mais informações, consulte os nós do cluster Connect to Azure Kubernetes Service (AKS) para manutenção ou resolução de problemas.

Nota

O caminho do arquivo pode mudar à medida que as versões do Kubernetes evoluem.
Depois de configurada uma região, criar um novo cluster ou atualizar um cluster existente para definir a autorrotação do certificado do cluster. Você precisa atualizar o plano de controle e o pool de nós para habilitar esse recurso.

Boas práticas para segurança de clusters e atualizações no Azure Kubernetes Service (AKS).

Feedback

Esta página foi útil?

Last updated on 2025-12-17