Como Kubernetes e sistemas nativos de nuvem se tornam o padrão de fato para implantação e gerenciamento de aplicativos modernos, sua expansão para ambientes restritos ou com firewall traz desafios únicos.
Esses ambientes são frequentemente motivados por conformidade regulatória, preocupações com segurança ou políticas organizacionais, que apresentam obstáculos arquitetônicos, operacionais e relacionados à segurança. Este artigo se aprofunda nas complexidades da implantação de clusters Kubernetes atrás de firewalls, oferecendo soluções e estratégias para superar esses obstáculos.
Desafios da implantação do Kubernetes em ambientes com firewall
Gerenciamento e distribuição de imagens
Os aplicativos Kubernetes exigem que imagens de contêiner sejam servidas de registros de contêiner, como Docker Hub, gcr.io ou quay.io. Em ambientes com firewall, o acesso a esses registros geralmente é restrito ou completamente bloqueado. Isso pode impedir a extração de imagens, dificultando a capacidade de implantar e atualizar aplicativos.
Solução: Para resolver isso, as empresas podem usar registros que tenham replicação de repositório ou recursos de cache pull-through para hospedar imagens de contêiner localmente dentro do firewall. Esses registros podem replicar ou extrair imagens de registros externos de forma controlada, garantindo que as imagens de contêiner necessárias estejam disponíveis sem acesso constante à Internet. Registros como o Harbor fornecem repositórios de imagens internos seguros para esses ambientes. Além disso, utilizar fluxos de trabalho de promoção de imagens garante que apenas imagens verificadas de fontes externas entrem no registro seguro.
Outra abordagem que usei é copiar as imagens por meio de um gateway ou servidor proxy com conectividade aos registros de origem e destino. Essa solução pode funcionar onde os recursos dos registros de origem e destino são desconhecidos. Ferramentas como imgpkg, crane ou skopeo podem copiar imagens entre registros que cruzam os limites do firewall. Por exemplo, o formato de pacote imgpkg agrupa o helm chart de um aplicativo e suas imagens de contêiner como uma única unidade. Um pacote imgpkg pode ser exportado como um arquivo tar do registro de origem para o sistema de arquivos local do servidor proxy. Esse arquivo tar pode então ser enviado para o registro em execução atrás do firewall, e o imgpkg garante que as referências de registro no helm chart do aplicativo dentro do pacote sejam atualizadas automaticamente para apontar para o registro de destino.
Gerenciamento de cluster e acesso ao plano de controle
O plano de controle do Kubernetes (servidor de API, etc.) deve se comunicar com os nós de trabalho e APIs de nuvem externas para gerenciar o cluster. No entanto, em ambientes com firewall, o acesso externo a essas APIs ou componentes do plano de controle geralmente é bloqueado ou limitado, apresentando desafios significativos para o monitoramento, dimensionamento e controle do cluster.
Solução: As organizações podem estabelecer técnicas de proxy reverso e tunelamento VPN para superar isso. Um proxy reverso implantado em uma zona desmilitarizada (DMZ) pode manipular solicitações de API de dentro do firewall enquanto fornece um ponto de entrada seguro. Além disso, hosts bastion e gateways VPN podem permitir acesso controlado e seguro ao plano de controle do Kubernetes. Esses hosts residem fora da rede interna, mas agem como uma ponte entre o ambiente restrito e os serviços externos, permitindo que os administradores interajam com o cluster sem violar as políticas de firewall.
Por exemplo, o Azure permite a criação de clusters AKS "privados" que são implantados na rede privada de uma empresa. O acesso ao plano de controle de clusters AKS privados é restrito por padrão por motivos de segurança. Mas o Azure também fornece soluções como o Azure Bastion, que fornece acesso seguro a um cluster privado do mundo externo. O usuário se conecta ao Azure Bastion via RDP ou SSH de seu computador local e pode acessar o cluster privado por proxy. O Bastion cuida de proteger o tráfego para o cluster privado.
Dependências externas e resolução de DNS
Às vezes, um aplicativo em execução em um cluster Kubernetes com air-gapped pode precisar extrair uma dependência externa para a qual pode precisar resolver um nome de host fora do firewall. O acesso ao DNS público, como Google DNS ou Cloudflare DNS, pode não estar disponível diretamente de dentro do pod, e o aplicativo pode não conseguir extrair a dependência e falhar ao iniciar. Isso forçará a organização ou o desenvolvedor do aplicativo a resolver a dependência dentro do firewall, o que pode ser viável apenas algumas vezes.
Solução: Use o encaminhamento de DNS no CoreDNS. O CoreDNS é o resolvedor de DNS padrão em clusters do Kubernetes e pode ser configurado para resolver consultas de DNS externas de dentro do firewall. O CoreDNS pode ser modificado para encaminhar consultas de DNS para nomes de host específicos (como www.example.com) para resolvedores externos e resolver todas as outras consultas dentro do firewall. Isso é feito usando o plugin CoreDNS "forward" para encaminhar a consulta para www.example.com para o Google ou CloudFlare DNS e encaminhar todo o resto (representado por um '.') para o resolvedor local apenas apontando-os para /etc/resolv.conf. Isso garante que a resolução de DNS crítica não seja bloqueada por políticas de firewall e também permite que o administrador do firewall mantenha sua rede segura permitindo apenas consultas externas específicas.
Atualizações, patches e componentes do Kubernetes
Atualizações e patches regulares para componentes do Kubernetes são essenciais para manter a segurança, a conformidade e o desempenho. No entanto, atualizações automatizadas podem ser bloqueadas em ambientes com firewall, deixando os clusters vulneráveis a riscos de segurança.
Solução: Use espelhos locais e registros de contêineres internos para atualizar o cluster. Ferramentas de instalação do Kubernetes como o Kubespray permitem o gerenciamento de cluster em ambientes offline. Instalar e aplicar patches no Kubernetes via Kubespray requer acesso a arquivos estáticos como kubectl e kubeadm, pacotes do SO e algumas imagens de contêiner para os principais componentes do Kubernetes. Arquivos estáticos podem ser servidos executando um servidor nginx/HAproxy dentro do firewall. Pacotes do SO podem ser obtidos implantando um espelho local de um repositório yum ou Debian. E as imagens de contêiner exigidas pelo Kubespray podem ser servidas executando instâncias locais de um registro 'kind' ou docker com imagens pré-preenchidas.
Além disso, as empresas podem usar pipelines de integração contínua/entrega contínua (CI/CD) para lidar com atualizações de forma controlada, com testes e validação locais em clusters de preparação antes de implementar alterações em clusters de produção. GitOps é uma subcategoria de CI/CD que implementa automaticamente alterações em um ambiente de destino acionado por confirmações em um repositório Git. Clusters de preparação e produção podem ser mapeados para diferentes ramificações do Git e atualizações e patches podem ser implementados estrategicamente, confirmando alterações na ramificação de preparação primeiro, testando-a completamente e somente então confirmando a mesma alteração na ramificação de produção. Isso garante que o cluster esteja atualizado com os patches de segurança mais recentes, apesar de não ter atualizações automáticas.
Integrações e monitoramento de terceiros
Os aplicativos modernos do Kubernetes geralmente dependem de integrações de terceiros, como Datadog, e soluções de armazenamento externo, como AWS S3 ou Google Cloud Storage. Em um ambiente com firewall, o tráfego de saída é restrito, impedindo a comunicação direta com esses serviços hospedados na nuvem.
Solução: As organizações podem implementar alternativas auto-hospedadas dentro de seu ambiente com firewall para manter a observabilidade e o monitoramento. Por exemplo, Prometheus e Grafana podem ser implementados internamente para lidar com métricas e visualização, enquanto soluções de armazenamento distribuído como Ceph ou MinIO podem substituir o armazenamento externo em nuvem. Essas ferramentas podem replicar a funcionalidade de serviços externos, garantindo que todos os dados permaneçam seguros dentro do firewall. Imagens de contêiner e gráficos de helm para alternativas auto-hospedadas podem ser puxadas para o ambiente com air-gapped usando a técnica de gerenciamento e distribuição de imagens descrita anteriormente.
Políticas de segurança e conformidade
Preocupações com segurança e conformidade são frequentemente o principal motivo para implementar o Kubernetes em ambientes de firewall. Setores como saúde e finanças exigem adesão estrita a regulamentações como HIPAA e PCI-DSS, que determinam o uso de ambientes seguros com acesso restrito a dados confidenciais.
Solução: Os recursos nativos do Kubernetes, como Pod Security Policies (PSPs), Role-Based Access Control (RBAC) e Network Policies, podem ser aproveitados para aprimorar a segurança do cluster do Kubernetes em um ambiente com firewall. Além disso, a implantação de service meshes como Istio ou Linkerd pode fornecer controle de tráfego e segurança refinados, garantindo que apenas serviços autorizados se comuniquem. Essas meshes também oferecem TLS mútuo (mTLS) para criptografar o tráfego entre microsserviços, aprimorando ainda mais a segurança e a conformidade.
Controle de entrada e balanceamento de carga
Em ambientes com firewall, serviços de balanceamento de carga externos (como AWS ELB ou balanceadores de carga do GCP) podem não estar disponíveis, causando dificuldades no roteamento de tráfego para serviços em execução no cluster do Kubernetes. Os serviços do tipo NodePort integrados do Kubernetes não são seguros, pois exigem que uma porta não padrão seja aberta em todos os nós do Kubernetes. Cada serviço que precisa ser exposto fora do cluster requer um serviço NodePort separado, complicando assim a administração do firewall.
Solução: Para expor serviços fora do cluster, um gateway de entrada como Istio ou Contour pode servir como um proxy que roteia o tráfego para esses serviços. Eles protegem o acesso aos serviços internos, pois podem encerrar o tráfego TLS e servir como o único ponto de entrada para todos os serviços que precisam ser expostos.
Soluções de balanceamento de carga privadas como MetalLB podem ser implantadas para fornecer alta disponibilidade do IP/nome do host para o gateway de entrada. Usar uma combinação de MetalLB e um gateway de entrada melhora a segurança. Haveria apenas um endereço IP/nome do host para proteger, e todo o tráfego de rede para todos os serviços expostos seria criptografado.
Conclusão
A implantação e o gerenciamento do Kubernetes em ambientes com firewall apresentam desafios únicos, desde o gerenciamento de imagens e acesso ao plano de controle até a resolução de DNS e integrações de terceiros. No entanto, com as estratégias e ferramentas certas, as organizações podem aproveitar o poder do Kubernetes enquanto mantêm a segurança, a conformidade e a estabilidade operacional exigidas por sua infraestrutura com firewall. Técnicas como replicação de imagem de registro de contêiner, encaminhamento de DNS para consultas específicas, túneis VPN, gateways de entrada e ferramentas de monitoramento auto-hospedadas garantem que o Kubernetes continue sendo uma solução viável mesmo nos ambientes mais restritos.
Organizações que pretendem adotar tecnologias nativas de nuvem por trás de firewalls devem projetar sua infraestrutura cuidadosamente, garantindo que os requisitos de segurança sejam atendidos sem sacrificar a escalabilidade e a flexibilidade que o Kubernetes oferece. Ao aproveitar as soluções acima, os clusters do Kubernetes podem operar efetivamente, mesmo em ambientes altamente restritos.
