Ao configurar um cluster AKS, existe a opção de não habilitar o controle de acesso (RBAC), embora a Microsoft recomende utilzar como boa prática. Uma das implicações de desativar o RBAC é que o cluster não realiza a atualização automática dos certificados, e como consequencia, você pode acordar certo dia e ver seu cluster práticamente fora do ar.

Konnectivity Agent

A Microsoft adota o Konnectivity Agent como padrão para promover uma comunicação segura entre o API Server e os Worker Nodes, atuando como um proxy. A configuração desse componente inclui a definição de um certificado TLS.

Ao não utilizar o RBAC, o cluster não vai rotacionar os certificados automaticamente que são usados pelo AKS, podendo levar à expiração do certificado do Konnectivity Agent. Como consequência, ocorre uma perda de controle sobre o cluster, por exemplo:

• Incapacidade do API Server comunicar com os Worker Nodes;
• Falha no funcionamento do Metric Server;
• Interrupção HPA;
• O cluster não consegue escalar;
• Falha do Scheduler em agendar novos Pods;
• Impossibilidade de obter logs das aplicações através do comando kubectl logs.

E o pior ainda está por vir: A detecção desse problema é bem dificil, pois a ausência de logs nos Pods limita a visibilidade do problema. Uma forma de identificar a expiração do certificado é por meio da documentação da Microsoft ou executando comandos específicos. Para clusters que utilizam VM Scale Sets, é possível verificar a validade do certificado com o seguinte comando:

az vmss run-command invoke --resource-group "MC_rg-<CLUSTER_NAME>_<REGION>" --name "<SCALE SET NAME>" --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate" --query "value[0].message"

# "Enable succeeded: \n[stdout]\nnotAfter=Mar 28 23:16:31 2026 GMT\n\n[stderr]\n"

Porém essa data exibe o fim do CRT que foi gerado para o Worker Node, nem sempre é o mesmo do Konnectivity. Para examinar especificamente o certificado do Konnectivity, utilize o comando abaixo:

kubectl get secret konnectivity-certs -n kube-system -o jsonpath="{.data.client\.crt}" | base64 --decode > konnectivity.crt
openssl x509 -in konnectivity.crt -noout -enddate
# notAfter=Mar 28 23:16:32 2026 GMT

Solução Oficial

Ao enfrentar problemas com certificados, e que ocasionem problemas nos pods do Konnectivity, a Microsoft recomenda a atualização dos certificados como a solução definitiva. Para realizar esta atualização, os seguintes comandos devem ser executados:

az aks get-credentials -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
az aks rotate-certs -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME

Embora essa seja a solução oficial e resolva o problema, é importante estar ciente de que este procedimento pode resultar em uma indisponibilidade do cluster de até 30 minutos. Dependendo da criticidade e da natureza do ambiente de produção, essa interrupção pode não ser a melhor abordagem em horários criticos.

Solução 2 - Rotacionar apenas o certificado do Konnectivity

Durante um incidente recente, optamos por uma abordagem alternativa para contornar o problema sem causar interrupções no horário comercial. A solução envolveu a geração de um novo certificado. Porém o grande desafio foi: Se não há acesso a chave de criptografia do API Server, como assinar o certificado?

Bem, por que não pedir para o próprio API Server assinar?

Passo 1: Fazer Backup das chaves atuais

Antes de mais nada, é crucial realizar um backup da secret que contém os certificados do Konnectivity. Isso garante a possibilidade de restauração para o estado anterior, caso necessário.

kubectl get secret konnectivity-certs -n kube-system -o yaml > konnectivity-backup.yaml

Passo 2: Gerar um novo certificado e assinar pelo API Server

Após o backup, execute o script abaixo:

# Obtem a key da secret atual
kubectl get secret konnectivity-certs -n kube-system -o jsonpath="{.data.client\.key}" | base64 --decode > konn.key
# Faz uma nova requisicao de assinatura do certificado do konnectivity
openssl req -new -key konn.key -out new-konnclient.csr -subj "/CN=konnectivity-agent"

# obtem o csr em formato base64
keybase64=$(cat new-konnclient.csr | base64 | tr -d '\n')

# Solicita ao API Server para assinar o certificado do konnectivity
kubectl apply -f - <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: konn-csr
spec:
  request: ${keybase64}
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
EOF

# Aprova a solicitação de certificado
kubectl certificate approve konn-csr

# Novo client.crt
clientcrt=$(kubectl get csr konn-csr -o jsonpath='{.status.certificate}')
# dados da secret que nao serão alterados
cacrt=$(kubectl get csr konn-csr -o jsonpath='{.status.certificate}')
clientkey=#(kubectl get secret konnectivity-certs -n kube-system -o jsonpath="{.data.client\.key}")

# Remove a secret atual
kubectl delete secret konnectivity-certs -n kube-system

# Recria com os valores atualizados
kubectl apply -f - <<EOF
apiVersion: v1
data:
  ca.crt: ${cacrt}
  client.crt: ${clientcrt}
  client.key: ${clientkey}
kind: Secret
metadata:
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/cluster-service: "true"
  name: konnectivity-certs
  namespace: kube-system
type: Opaque
EOF

Agora basta reinicar os pods do Konnectivity e ver a mágica acontecer.

Considerações Importantes

Apesar da eficácia desta solução, o objetivo foi prevenir a indisponibilidade do cluster. Isso não retira a necessidade de realizar a rotação completa dos certificados.

Realizar a rotação dos cretificados não apenas resolve o problema de maneira definitiva mas também previne potenciais vulnerabilidades de segurança.

Veja essa medida como uma carta na manga em momentos criticos. Se precisar de apoio, nos procure que podemos te ajudar!