O kubectl funciona pela VPN, mas o AKS deixa de escalar: porquê

Você adiciona o endereço público da VPN do escritório à lista de permitidos do servidor de API do AKS, e o kubectl funciona. Uma semana depois, o escalonamento de um pool de nós falha, um job de CI não consegue acessar o cluster, e o portal mostra um erro que não menciona nada sobre intervalos de IP. Ninguém alterou a lista de permitidos. O controle que você ativou é um filtro de IP público na frente do servidor de API, e ele não sabe quem está chamando, apenas de qual endereço a chamada veio. A VPN é um endereço entre vários que o cluster precisa, e raramente é o que quebra primeiro.

A lista de permitidos corresponde a um endereço, não a uma pessoa

--api-server-authorized-ip-ranges aceita blocos CIDR, não usuários ou grupos. Quando a solicitação de um desenvolvedor sai do servidor VPN para o Azure, o endereço de origem no servidor de API é a saída pública do servidor VPN. Cada pessoa nessa VPN, portanto, compartilha uma única entrada, e quem está fora da VPN é recusado antes mesmo de a autenticação acontecer.

Isso também significa que a entrada admite mais pessoas do que você talvez pretenda. Um prestador de serviço com acesso à VPN, um notebook pessoal no mesmo concentrador e uma conta comprometida chegam todos do mesmo endereço. A autorização do cluster não muda, então o controle de acesso baseado em funções ainda decide o que o chamador pode fazer, mas a lista de permitidos não é um controle de identidade e nunca deveria ser descrita como tal.

O que quebra primeiro normalmente não é o kubectl

A lista de permitidos se aplica ao endpoint público do servidor de API, então tudo o que estiver fora dos endereços listados para de funcionar de imediato. As vítimas óbvias são o segundo escritório sem rota VPN, um executor de CI em um pipeline hospedado e um notebook que esqueceu de se conectar. Eles são fáceis de reconhecer porque há uma pessoa esperando.

O caso menos óbvio é a automação conduzida pelo Azure ou pelas suas próprias ferramentas. Algumas operações iniciadas pela plataforma chegam ao servidor de API de endereços que não são a sua VPN, e quando uma delas começa a falhar logo após o endurecimento da lista, o momento é a pista. Não presuma que a lista está completa porque o acesso interativo funciona; verifique o que o recurso exige para a sua região e as suas assinaturas antes de concluir que o cluster está quebrado.

A assinatura da falha ajuda. Se a solicitação nunca chega à autenticação, é o filtro. Se ela se autentica e depois recebe um erro de permissão, o filtro fez o seu trabalho e o problema é o controle de acesso baseado em funções, que a lista de permitidos nunca toca.

Monte a lista inteira em um único comando

O parâmetro de atualização substitui a lista inteira em vez de adicionar uma entrada, então um comando que leva apenas o endereço da VPN descarta silenciosamente todo o resto que estava lá. Leia o valor atual primeiro, mantenha-o e envie a união:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

Use um IP público reservado para o servidor VPN antes de depender disso. Um endereço dinâmico muda ao reconectar, e cada mudança tranca a equipe para fora do cluster em silêncio até que alguém atualize a lista a partir de uma rede ainda permitida. Se você tem dois pontos de saída VPN para redundância, liste os dois, porque o filtro não tem qualquer noção de caminho preferido.

Ordene a mudança para que a primeira tentativa permitida seja também o teste. Anuncie a nova lista, aplique-a e conecte-se pela VPN imediatamente; fazer na ordem inversa deixa uma janela em que ninguém consegue chegar ao servidor de API para corrigir um erro de digitação em um bloco CIDR.

O que a lista de permitidos nunca cobriu

Ela não torna o servidor de API privado. Um cluster privado usa um endpoint privado e DNS privado, e a lista de intervalos autorizados não é o controle que o substitui. Ela também não muda o que um chamador admitido pode fazer, então um kubeconfig de administrador vazado ainda funciona a partir de qualquer endereço permitido. Trate a credencial como a fronteira de segurança e a lista como uma conveniência de rede.

Ela não tem nada a ver com cargas de trabalho. Os pods e os serviços continuam funcionando com a lista ativada, e chegar a uma aplicação pela VPN é um problema separado: um serviço que só tem um IP de cluster ainda precisa de um balanceador de carga interno, de um ingress ou de um port-forward antes de um notebook conseguir abri-lo. Misturar esses dois desenhos produz um ticket de mudança que alega restringir desenvolvedores e na verdade não restringe nada das aplicações.

Verifique dos dois lados e depois execute uma operação real

Teste com um cliente novo na VPN e com um cliente fora dela. A tentativa de fora deve ser recusada no servidor de API, não na resolução de nomes; se o nome não resolver, você está testando DNS e não aprendeu nada sobre o filtro. Em seguida, execute uma operação que não seja uma chamada interativa do kubectl, como escalar um pool de nós ou uma verificação de atualização, e confirme que ela termina em vez de presumir que sim.

Registre o valor anterior da lista junto à mudança e releia o valor efetivo após a atualização em vez de confiar no comando digitado. A documentação dos intervalos de IP autorizados do AKS lista os parâmetros suportados e os requisitos de plataforma que pertencem à mesma lista, que é a parte que a maioria das descrições de ticket omite.