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

O AKS (Serviço de Kubernetes do Azure) usa certificados para autenticação com muitos de seus componentes. Você precisa girar periodicamente esses certificados por motivos de segurança ou política. Este artigo mostra como o giro de certificados funciona no cluster do AKS.

Pré-requisitos

• Este artigo exige a CLI do Azure versão 2.0.77 ou posterior. Verifique a versão usando o comando az --version. Se você precisa instalar ou atualizar, veja Instalar a CLI do Azure.

• Configure kubectl para se conectar ao cluster do AKS usando o comando az aks get-credentials.

  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, AC (Autoridades de Certificação) e SA (Contas de Serviço):

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

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

Datas de validade do certificado

Verifique a data de validade do certificado do cluster

• Verifique a data de validade do certificado de cluster usando o comando kubectl config view.

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

Verificar a data de validade do certificado do servidor de API

• Verifique a data de validade do certificado do servidor de API usando o seguinte curl comando:

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

Verificar a data de validade do certificado do nó do agente da máquina virtual (VM)

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

  Parâmetros principais no comando: – --resource-group <node-resource-group>: o grupo de recursos que contém o nó do agente da VM. - --name <vm-name>: o nome do nó do agente da VM. - --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate": o script que recupera a data de validade do certificado do servidor de 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"
  

Verificar a data de expiração do certificado para o nó do agente do Conjunto de Dimensionamento de Máquinas Virtuais do Azure

• Verifique a data de validade do certificado do nó do agente do Conjunto de Dimensionamento de Máquinas Virtuais do Azure usando o comando az vmss run-command invoke.

  Parâmetros principais no comando: – --resource-group <node-resource-group>: o grupo de recursos que contém o nó do agente do Conjunto de Dimensionamento de Máquinas Virtuais do Azure. - --name <vmss-name>: o nome do Conjunto Escalonável de Máquinas Virtuais do Azure. - --instance-id 1: a ID da instância do nó do agente do Conjunto de Dimensionamento de Máquinas Virtuais do Azure. - --scripts "openssl x509 -in  /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate": o script que recupera a data de validade do certificado de 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"
  

Gire manualmente os certificados do cluster

1. Gire todos os certificados, CAs e SAs em seu cluster usando o comando az aks rotate-certs.

   az aks rotate-certs --resource-group <resource-group> --name <cluster-name>
   

   Importante

   O comando az aks rotate-certs recria todos os nós do agente, Conjunto de Dimensionamento de Máquinas Virtuais do Azure e discos. Esse comando também pode causar até 30 minutos de tempo de inatividade para o cluster do AKS. Se o comando falhar antes de concluir, use o comando [az aks show][az-aks-show] para verificar se o status do cluster é Certificate Rotating. Se o cluster estiver em um estado com falha, execute novamente o az aks rotate-certs comando para girar seus certificados novamente.

2. Verifique se os certificados antigos não são mais válidos usando qualquer kubectl comando. O exemplo a seguir usa o kubectl get nodes comando:

   kubectl get nodes
   

   Se você não atualizou os certificados usados pelo kubectl, você verá um erro semelhante como a seguinte saída de exemplo:

   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")
   

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

   az aks get-credentials --resource-group <resource-group> --name <cluster-name> --overwrite-existing
   

4. Verifique se os certificados são atualizados usando o kubectl get comando.

   kubectl get nodes
   

Se você tiver serviços executados em cima do AKS, talvez seja necessário atualizar seus certificados também.

Renovar o certificado de operação do kubelet

Quando você gira o certificado de serviço do kubelet, o AKS permite a inicialização de TLS (Segurança de Camada de Transporte) do servidor do kubelet para a inicialização e a rotação dos certificados de serviço assinados pela CA do Cluster.

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

• Com suporte 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 uma imagem de nó mais antiga que 202501.12.0.
• Você não pode habilitar manualmente esse recurso. A rotação do certificado de serviço do kubelet é habilitada por padrão nos pools de nós existentes quando eles executam a primeira atualização para qualquer versão do Kubernetes 1.27 ou superior. A rotação do certificado de serviço do Kubelet é habilitada por padrão em pools de nós recém-criados usando o Kubernetes versão 1.27 ou superior. Para ver se a rotação de certificado de serviço kubelet está habilitada em sua região, verifique as versões do AKS.

Verificar se a rotação de certificado de serviço kubelet está habilitada

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

• Verifique se os rótulos estão definidos 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 o rótulo kubernetes.azure.com/kubelet-serving-ca com o valor cluster para cada nó do agente.

Verificar se o kubelet TLS Bootstrapping está funcionando

• Verifique se o processo de inicialização está ocorrendo usando o kubectl get comando.

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

  Na saída, todos os CSRs ativos devem estar no estado Approved,Issued, o que indica que a CSR foi aprovada e um certificado assinado foi emitido. As CSRs de serviço têm o nome de signatário 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
  

Verificar se o kubelet está usando um certificado obtido do servidor TLS Bootstrapping

• Confirme se o kubelet está usando um certificado de serviço assinado pela AC 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
  

  Caso haja um link de simbólico kubelet-server-current.pem, isso significa que o kubelet iniciou ou rotacionou seu próprio certificado de serviço, e a CA do cluster o assinou.

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

• Desabilite a rotação do certificado de serviço do kubelet. Basta atualizar o pool de nós usando o comando az aks nodepool update com a marca 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
  

1. Refaça a imagem dos nós usando uma atualização de imagem de nó ou dimensionando o pool para instâncias zero e, em seguida, aumentando novamente até o valor desejado.

Autorotação de certificado

Tenha as seguintes considerações em mente ao usar a autorotação de certificado:

• Se você tiver um cluster existente, será necessário atualizar esse cluster para habilitar a autorotação de certificado.
• Não desabilite o TLS Bootstrap para manter a autorotação de certificado habilitada.
• Caso o cluster esteja em um estado parado durante a rotação automática do certificado, apenas os certificados do plano de controle serão rotacionados. Nesse caso, você deve recriar o pool de nós após o giro do certificado para iniciar o giro do certificado do pool de nós.
• Para todos os clusters do AKS criados ou atualizados depois de março de 2022, o AKS rotacionará automaticamente os certificados não CA nos nós do agente e do plano de controle dentro de 80% do tempo válido do certificado do cliente, antes de expirarem sem tempo de inatividade do cluster.

Verificar se o TLS Bootstrapping está habilitado no pool de nós do agente atual

1. Verifique se o cluster tem o TLS Bootstrapping habilitado navegando até um dos seguintes caminhos:

   • Em um nó do 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 Conecte os nós de cluster do AKS (Azure Kubernetes Service) para manutenção ou solução de problemas.

   Observação

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

2. Depois que uma região for configurada, crie um novo cluster ou atualize um cluster existente para definir a autorotação de certificado para o certificado do cluster. Você precisa atualizar o painel de controle e o pool de nós para habilitar esse recurso.

Conteúdo relacionado

• Práticas recomendadas para segurança de cluster e atualizações no AKS (Serviço de Kubernetes do Azure).