Coloque a API do EKS atrás de uma VPN: ordem das operações

Ative o endpoint privado, prove que o kubectl chegou a ele e só então feche o público. Um runbook por etapas com os comandos e as verificações entre cada passo.

A versão perigosa desta mudança é um único comando que inverte o endpoint e bloqueia todos os administradores ao mesmo tempo. A versão segura mantém os dois caminhos abertos, prova que o privado funciona a partir da VPN e só então retira o endpoint público. Considere um cluster existente, um túnel aprovado para a sua VPC e um kubeconfig que já funciona; a tarefa é o acesso privado à API do Kubernetes, não os nós privados e não um novo modelo de permissões. Cada passo abaixo tem uma verificação na qual você pode falhar com segurança.

1. Inventarie o endpoint e mantenha um caminho de volta

Registre o estado atual antes de alterá-lo, incluindo a lista CIDR pública de endereços permitidos e o grupo de segurança do cluster. São esses dois que você vai comparar quando algo parar de funcionar, e a lista de permitidos também é o seu caminho de reversão se a rota privada se revelar errada.

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

REGION e CLUSTER são aqui marcadores de posição. Observe o que o indicador privado lê agora, porque um cluster criado com o acesso privado já ativado precisa de um primeiro passo diferente de um que nunca o teve. Mantenha aberto pelo menos um caminho administrativo aprovado durante a transição; uma VPN que depende de o mesmo cluster estar acessível não é um caminho de recuperação.

2. Ative o acesso privado com o caminho de rede pronto

Ligar o indicador é a metade fácil. O túnel precisa de uma rota para os endereços privados do endpoint, e o grupo de segurança do cluster precisa de TCP 443 a partir da origem que a VPN realmente apresenta. Uma associação de Client VPN, um gateway site-to-site e uma VPC emparelhada podem todos apresentar endereços de origem diferentes, então use o modelo que você implantou em vez de um intervalo privado genérico.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

A atualização é assíncrona. Consulte o id da atualização até que ela informe sucesso em vez de esperar um número fixo de segundos e presumir. Deixe o tráfego dos nós e do plano de controle em paz enquanto faz isso: substituir todo o grupo de segurança do cluster por uma regra para o seu portátil é a forma como um plano de dados que funciona se torna um segundo incidente.

A documentação dos endpoints do EKS merece uma leitura completa, porque diz que o acesso apenas privado pode vir da VPC ou de uma rede conectada. Essa frase é toda a razão pela qual esta migração é possível, e também é a razão pela qual o passo seguinte existe.

3. Prove que a estação de trabalho usou o caminho privado

Com os dois endpoints ativados, um kubectl get ns bem-sucedido não prova nada sobre qual respondeu. Resolva o nome de host do endpoint e verifique se o endereço obtido pertence ao intervalo privado ou ao público. Se a sua rede conectada não recebe a visão privada através de DNS, o comando terá sucesso pelo endpoint público e você retirará o caminho público com base em provas falsas. É a forma mais comum de esta migração correr mal, e parece exatamente um sucesso.

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

Mantenha o nome de host e a validação do certificado exatamente como estão. Substituir por um IP privado no kubeconfig e ignorar a verificação TLS não é a migração que você descreveu no registo de alterações, e ela voltará a falhar no momento em que o endpoint rodar.

4. Retire o acesso público deliberadamente

Depois de demonstrado o caminho privado e aprovado o fluxo de recuperação, feche o endpoint público. Esta é uma alteração real e não uma pré-visualização, por isso execute-a na conta e nas configurações que realmente pretende.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

No modo apenas privado, o nome DNS público é resolvido para os endereços privados do endpoint a partir de dentro da VPC, por isso a resolução e a acessibilidade deixam de ser a mesma coisa. Tudo o que dependia do endereço público, incluindo executores de CI ou um portátil noutra rede, agora precisa do seu próprio caminho de entrada.

5. Mantenha a política de rede e a política de identidade separadas

A lista CIDR de acesso público rege apenas o endpoint público. Não restringe o endpoint privado, que, em vez disso, é limitado pelo grupo de segurança do cluster e pela política da rede conectada. Se mantiver o endpoint público, a sua lista de permitidos tem de corresponder à saída pública que os seus clientes de API e nós realmente utilizam; um endereço de conjunto de VPN raramente é essa origem.

Nada disto altera o IAM nem o Kubernetes RBAC. As definições do endpoint são uma ação administrativa, e os utilizadores comuns não devem receber permissão para relaxar o limite só para chegar à API. Escreva o estado final, a data e o caminho de recuperação no runbook e depois teste o caminho de recuperação uma vez enquanto ainda é fácil.

Artigos relacionados