Recentemente, durante uma consultoria, o cliente mandou a clássica:
"Preciso acessar um recurso privado. O que é melhor: uma VM como bastion ou uma VPN?"

Legal. Só mais uma segunda-feira na vida de quem trabalha com cloud.

O cliente estava no Azure. Se optasse por VPN, teria que provisionar um VPN Gateway, configurar a GatewaySubnet, ajustar rotas e, claro, distribuir e gerenciar certificados ou credenciais para quem fosse usar.

Já a opção da VM traria um custo constante, obviamente bem baixo, mas ainda assim teria a necessidade de atualizar o sistema operacional, aplicar hardening e ainda integrar tudo com a infra atual dele. Tudo isso... pra “dar uma olhadinha” em alguns recursos internos.

Só que nessa história tinha um detalhe importante: ele já usava AKS.

E aí vem aquele momento em que a gente lembra que, muitas vezes, está tão acostumado a fazer algo do mesmo jeito, que esquece de pensar no por que fazer daquele jeito.

Conceito antes da Tecnologia

A ideia do bastion ou jumpbox é simples: prover um ponto de acesso controlado para dentro de uma rede privada. Estamos tão acostumados em associar lé com cré que nem pensamos mais, basta criar uma VM exposta por um IP público.

Porém ele já possuia um serviço, um cluster Kubernetes (AKS), com toda uma malha de segurança, autenticação, tudo já integrado com os requisitos de segurança que a empresa dele requer. Então porque não usar um POD como Bastion?

POD como Bastion

Ao invés de provisionar uma nova VM, criamos um Deployment bem simples no cluster. Um Pod rodando Ubuntu com OpenSSH, com uma chave pública montada via Secret e acesso controlado por NetworkPolicy.

O manifesto ficou super simples:

  • O Deployment fica com 0 réplicas e só sobe quando você quiser
  • Uma Imagem Ubuntu com SSH: acesso à moda antiga, mas com controle moderno
  • Secret com chave SSH: sem precisar rebuildar imagem ou expor credenciais
  • Service com LoadBalancer: acesso externo, mas com portas customizadas
  • NetworkPolicy: acesso restrito a determinados ip

Veja como ficou simples:

O acesso é feito por um Service com tipo LoadBalancer, expondo a porta 3500 para acesso externo. E o controle era feito via kubectl scale:

kubectl scale deployment bastion -n tools --replicas=1

E para desligar:

kubectl scale deployment bastion -n tools --replicas=0

Gerando as Chaves SSH e Criando a Secret

Para gerar as chaves SSH e a Secret siga os passos abaixo:

ssh-keygen -t rsa -b 4096 -f id_rsa_bastion -N ""

Esse comando vai gerar dois arquivos:

  • id_rsa_bastion: chave privada
  • id_rsa_bastion.pub: chave pública

Agora basta criar a secret no kubernetes:

kubectl create secret generic bastion-ssh-key \
  --from-file=id_rsa.pub=id_rsa_bastion.pub \
  -n tools

Conclusão

O Resultado? Menos Infra, Mais Controle

No final, entregamos uma solução que:

  • Usava os recursos já existentes no cluster
  • Não exigia VMs adicionais ou configurações extras
  • Versionável, auditável e segura

Mais do que economizar recursos, a abordagem valorizou o conceito: não se trata de usar a ferramenta A ou B, mas de resolver o problema com clareza, segurança e simplicidade.

E mais uma vez venceu entender conceitos e desapegar de ferramentas.