Como fechar lacunas de segurança de protocolos em clusters Kubernetes multi-tenant, segundo a AWS

O problema de fundo é simples: ADB, VNC e protocolos parecidos guardam credenciais localmente, sem caminho até um repositório central de identidade, e o ADB trafega sem criptografia. Num cluster multi-tenant, isso se agrava porque os pods alcançam portas abertas de outros tenants por padrão, a menos que existam network policies restringindo o tráfego entre namespaces. A AWS descreve uma arquitetura com três peças reutilizáveis: Envoy Gateway com escopo de namespace e mTLS, certificados de curta duração emitidos pelo AWS Private CA via cert-manager, e o Kinesis Video Streams como relay TURN gerenciado.

Os números do caso Cuttlefish: os certificados duram 12 horas, com janela de renovação de 4 horas. Assim, um certificado comprometido expira rápido, sem exigir infraestrutura de CRL ou OCSP. A latência de comandos ADB ficou abaixo de 100 ms, e instalações de app abaixo de 30 segundos, contra 1 a 2 segundos por comando e 3 a 4 minutos por instalação na arquitetura antiga com port forward duplo. Há limites explícitos: o trecho entre Envoy e o pod não é criptografado por mTLS (a NetworkPolicy restringe o acesso à porta ADB), o caminho de dados do ADB não tem proteção de WAF, e o certificado não carrega identificador de usuário. Para ambientes regulados, a AWS sugere sidecar ou certificados por pod e certificados por usuário. A cadeia de identidade JWT exige trabalho customizado e não é diretamente transferível.

Para quem opera Kubernetes multi-tenant, a leitura prática é que o gateway mTLS só vale se a NetworkPolicy de default-deny estiver aplicada antes, porque sem ela o tráfego contorna o gateway. Também vale avaliar a lacuna entre Envoy e pod contra a classificação de dados da empresa. O padrão tende a servir para VNC, RDP, MQTT e SIP, segundo o próprio post.