Visão geral do gerenciamento e rotação de certificados no AKS (Serviço de Kubernetes do Azure)

AKS (Serviço de Kubernetes do Azure) clusters usam certificados para autenticação entre vários componentes, incluindo componentes do plano de controle gerenciado do AKS e componentes do plano de dados. Este artigo fornece uma visão geral do gerenciamento e rotação de certificados no AKS.

Importante

A partir de 01 de abril de 2027, o AKS (Serviço de Kubernetes do Azure) não dá mais suporte à tag de aks-disable-kubelet-serving-certificate-rotation=true pool de nós para desativar a rotação do certificado de atendimento do Kubelet (KSCR). Você pode criar novos pools de nós usando essa marcação, mas o AKS não a respeitará. Esse comportamento significa que os pools de nós serão criados com o KSCR habilitado. Para pools de nós existentes, o KSCR será habilitado automaticamente na próxima operação de reimagem. Antes desta data, você pode atualizar os pools de nós usando o comando az aks nodepool update com a tag aks-disable-kubelet-serving-certificate-rotation=true. Para se preparar para a remoção, atualize suas cargas de trabalho com o caminho do certificado correto. Para saber mais, consulte o problema de desativação do GitHub. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de lançamento do AKS.

Observação

A autorotação de certificado para clientes de nó e certificados de serviço é habilitada por padrão para clusters que habilitam o RBAC do Kubernetes.

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

O que é rotação de certificado?

A rotação de certificados é o processo de substituição de certificados digitais por novos para manter a segurança e evitar interrupções. É uma prática de segurança crucial executada para substituir certificados expirados, reduzir riscos de chaves comprometidas e responder a novos requisitos de segurança. Esse processo pode envolver a renovação automática de certificados ou a substituição manual deles. Geralmente, requer uma janela de manutenção programada para substituições complexas, especialmente quando há um certificado raiz envolvido.

Certificados, autoridades de certificação e tokens de conta de serviço no AKS

O AKS gera e usa os seguintes certificados, autoridades de certificação (AC) e tokens de conta de serviço (SA):

Certificate Descrição Método de rotação
Autoridade de certificação do cluster Criado pelo AKS em seu nome e é exclusivo do seu cluster. Esse certificado de AC é usado para emitir tanto certificados de cliente quanto de servidor para os kubelets em execução no seu plano de dados e o certificado usado pelo servidor da API. Manual
Token da conta de serviço JSON Web Tokens (JWT) assinados com o certificado de CA do cluster. Os kubelets em execução nos nós do agente solicitam e renovam automaticamente esses tokens. Para obter mais informações, consulte Iniciar um Pod usando a projeção de token de conta de serviço. Atualizado automaticamente como parte da rotação manual da AC do cluster
Certificado do servidor de API Assinado e emitido pelo certificado de AC do cluster. Esse certificado é usado sempre que estabelece conexões baseadas em TLS com o servidor de API, como com kubectl. Atualizado automaticamente como parte da rotação manual da AC do cluster
Certificado de servidor do kubelet Em clusters que habilitam a rotação do certificado de servidor do kubelet, o certificado da AC do cluster emite e assina esse certificado. Caso contrário, o nó do agente gera e autoassina este certificado. Este certificado estabelece conexões baseadas em TLS com componentes que precisam se conectar a qualquer um dos endpoints de atendimento do kubelet, como metrics-server. Automático para clusters habilitados com kubelet servindo rotação de certificado
Certificado do cliente Kubelet Assinado e emitido pelo certificado de AC do cluster. Esse certificado usa um protocolo de inicialização TLS específico do AKS que fornece ao kubelet seu certificado de cliente e kubeconfig correspondente antes do kubelet ser iniciado. O protocolo TLS do AKS só está habilitado nos clusters do Kubernetes versão 1.32 ou superior. Atualizado automaticamente por padrão usando a inicialização TLS padrão e também como parte da rotação manual da CA do cluster
kubectl certificado do cliente Usado para autenticação baseada em certificado com o servidor de API. Girar manualmente após a rotação manual da AC do cluster

Observação

O AKS não gerencia nenhum certificado criado ou específico para a carga de trabalho de um cliente.

Rotação automática de certificados no AKS

O AKS rotaciona automaticamente os seguintes certificados:

  • Os clusters criados após março de 2022 com o RBAC do Kubernetes habilitado habilitam a autorotação do certificado do cliente kubelet por padrão.

Observação

Talvez seja necessário rotacionar manualmente esses certificados periodicamente 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. Por padrão, a autorotação do certificado do cliente kubelet ocorre manualmente.

Limitações para a autorotação de certificado

As seguintes limitações se aplicam à autorotação de certificado:

  • O cluster deve usar inicialização TLS de baunilha ou inicialização TLS segura do AKS, que está sendo distribuída por padrão para todas as regiões Azure.
  • Para clusters existentes, você precisa atualizar o cluster para habilitar a autorotação de certificado.

Rotação manual de certificados no AKS

Você deve fazer a rotação manualmente dos seguintes certificados:

Quando você faz a rotação do certificado da AC do cluster, os seguintes certificados derivados também são atualizados:

  • Tokens de conta de serviço (SA)
  • Certificados de servidor de API
  • Certificados de cliente kubelet
  • Certificados do servidor Kubelet (se a rotação de certificado de serviço kubelet estiver habilitada no cluster)

Depois de renovar o certificado da CA do cluster, você também deve renovar manualmente os certificados de cliente kubectl para garantir o acesso contínuo ao servidor da API.

Inicialização de TLS para o certificado de cliente kubelet

O Kubelet usa um protocolo de inicialização TLS específico do AKS e depende da identidade do nó no Entra ID. Essa identidade fornece ao kubelet seu certificado de cliente e kubeconfig correspondente antes do kubelet ser iniciado. Essa alteração visa reforçar a postura de segurança do nó do AKS, eliminando a dependência do kubelet em um segredo estático de token de inicialização para que ele se registre no servidor de API. Se o protocolo de inicialização TLS seguro falhar por qualquer motivo, o kubelet ainda poderá se registrar no servidor de API usando um token de inicialização e, eventualmente, o nó ficará pronto. Você vê aksService (em vez de system:bootstrap:<>) como o campo solicitante nos objetos CSR (solicitação de assinatura de certificado) criados pelo protocolo.

O certificado do cliente kubelet ainda está localizado em /var/lib/kubelet/pki/kubelet-client-current.pem em nós do Linux e C:\k\pki\kubelet-client-current.pem em nós Windows. O bootstrap-kubeconfig ainda está localizado no mesmo local. O AKS continua a girar automaticamente esse certificado como parte de seu processo de rotação de certificados.

Rotação de certificado de serviço do kubelet

A rotação de certificados de serviço do kubelet permite que o AKS use o TLS bootstrapping do servidor kubelet tanto para a inicialização quanto para a rotação dos certificados de serviço do kubelet assinados pela AC do cluster.

Para obter mais informações, consulte Gerenciar e girar certificados em AKS (Serviço de Kubernetes do Azure).

Limitações da rotação do certificado de servidor 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. Os pools de nós existentes têm a rotação do certificado de servidor do kubelet habilitada por padrão após a primeira atualização para qualquer versão 1.27 ou superior do Kubernetes. Novos pools de nós com a versão 1.27 do Kubernetes ou superior têm a rotação do certificado de serviço do kubelet habilitada por padrão. Para verificar se a rotação do certificado de atendimento do kubelet está habilitada em sua região, consulte AKS Releases.
  • O RBAC do Kubernetes deve ser habilitado no cluster para habilitar a rotação do certificado de servidor do kubelet. Se você tiver um cluster existente, deverá atualizar esse cluster para habilitar o RBAC do Kubernetes.

Próxima etapa