Observabilidade CI/CD: uma nova e rica oportunidade para OpenTelemetry
30 de abril de 2024Como controlar o acesso na autorização distribuída LLM Data Plus
30 de abril de 2024Esteja uma empresa migrando seu aplicativo legado para uma arquitetura nativa em nuvem ou implantando um novo aplicativo nativo em nuvem, ela enfrentará o desafio de integração com ferramentas de segurança, como firewalls, que dependem de uma identidade de rede estável para configuração de segurança. Isso se deve ao fato de que não é garantido que as cargas de trabalho nativas da nuvem tenham uma identidade de rede fixa. A justaposição de cargas de trabalho modernas e dinâmicas com aplicações tradicionais que dependem de identificadores de rede fixa apresenta um conjunto único de desafios.
Isto é particularmente pertinente para equipes de DevOps e de plataforma encarregadas de garantir comunicação e segurança contínuas entre esses ambientes díspares. Torna-se crucial para as equipes de DevOps, plataformas e segurança de rede garantir uma comunicação perfeita e um fluxo de tráfego seguro à medida que as organizações equilibram a inovação (aplicativos nativos da nuvem) e aproveitam os investimentos existentes (firewalls e fontes de dados tradicionais).
Cenários Comuns
Protegendo e identificando o tráfego que sai do cluster
Um dos principais desafios na integração de cargas de trabalho nativas da nuvem com aplicativos legados atrás de um firewall é proteger e identificar o tráfego de cargas de trabalho específicas em execução no cluster. Muitos aplicativos, como bancos de dados, são protegidos por firewalls que exigem um endereço IP estável para permitir o acesso a esses aplicativos. As equipes desejam garantir que apenas o tráfego autorizado de cargas de trabalho específicas possa acessar aplicativos como bancos de dados por meio da regra de firewall implementada, reduzindo assim a área de superfície de ataque.
Integração com aplicativos de terceiros
Além de preencher a lacuna entre aplicativos legados e nativos da nuvem, é necessária uma integração perfeita com aplicativos externos de terceiros. Esses aplicativos externos podem exigir identificadores de rede fixos para permitir o acesso a serviços protegidos por seus próprios firewalls.
Qual é o desafio para DevOps e equipes de plataforma?
Um desafio significativo que surge em ambos os cenários acima é manter um endereço IP estável para o tráfego de carga de trabalho que sai do cluster Kubernetes. Isso se deve ao fato de que qualquer tráfego que sai de um cluster Kubernetes recebe o endereço IP do nó em que o pod está sendo executado pelo processo SNAT (Source Network Address Translation). Como não há garantia de execução de um pod em um nó específico, o endereço IP associado ao tráfego de saída é dinâmico, complicando a identificação por recursos externos.
Vejamos um exemplo, conforme mostrado na Figura 1, em que um proprietário de plataforma ou engenheiro de DevOps precisa estabelecer conectividade entre dois sistemas: uma carga de trabalho de pagamento e um banco de dados de cartão de crédito protegido por um firewall. A carga de trabalho de pagamento está localizada no cluster Kubernetes, enquanto o outro sistema está localizado fora do cluster. Nesse cenário, o firewall requer um endereço IP fixo da carga de trabalho de pagamento para estabelecer conectividade com o data warehouse de cartão de crédito e implementar regras de segurança.
Gateway de saída
Os proprietários de plataformas e DevOps devem ser capazes de atribuir um IP fixo ao tráfego de saída das cargas de trabalho, para que aplicativos e ferramentas tradicionais possam usar essas informações de IP fixo para construir uma comunicação segura de carga de trabalho com cargas de trabalho do Kubernetes, conforme mostrado na figura acima. Um gateway de saída cria um ponto de saída específico para o tráfego de saída e atribui um IP fixo a qualquer tráfego de saída que sai desse ponto de saída. As equipes podem configurar o tráfego de saída de cargas de trabalho específicas para sair por meio de um gateway de saída, garantindo assim um endereço IP fixo associado ao tráfego de saída.
Como funciona
As cargas de trabalho são configuradas para que o tráfego de saída seja direcionado por meio de um gateway de saída. Para maior resiliência, você pode configurar vários gateways de saída para alta disponibilidade ou uma rota especificada com base em uma política. Os gateways de saída são configurados para usar um pool de IP específico e realizar uma tradução de endereço de rede (SNAT) no tráfego que passa por eles. Portanto, qualquer número de cargas de trabalho pode ter suas conexões de saída multiplexadas por meio de um número pequeno e fixo de gateways de saída, e todas essas conexões de saída adquirem um IP de origem do pool de IP do gateway de saída.
Um gateway de saída atua como um pod de trânsito para o tráfego de aplicativos de saída configurado para usá-lo. À medida que o tráfego que sai do cluster passa pelo gateway de saída, seu IP de origem é alterado para o do pod do gateway de saída e o tráfego é então encaminhado.
Benefícios do gateway de saída
-
Melhore a segurança
Ao atribuir endereços IP fixos ao tráfego de saída de uma carga de trabalho, DevOps e engenheiros de plataforma podem reduzir a superfície de ataque e mitigar os riscos associados à exposição de amplos intervalos de IP de nós.
-
Estenda as regras de firewall
Os firewalls agora podem estender suas regras para a carga de trabalho específica no cluster Kubernetes. A regra sempre será aplicada a essa carga de trabalho, independentemente de sua localização no cluster.
-
Integração perfeita
Facilita a comunicação entre cargas de trabalho do Kubernetes e aplicativos tradicionais sem a necessidade de soluções alternativas complicadas.
Principal vantagem
Com uma abordagem de gateway de saída, os engenheiros de DevOps e de plataforma podem garantir uma postura de segurança mais forte para seu cluster Kubernetes, gerenciamento simplificado de segurança de rede e nenhum custo adicional de infraestrutura de rede.
Aprender mais sobre Gateway de saída de chita.
A postagem Gateway de saída: atribuir IPs estáveis ao tráfego que sai dos clusters K8s apareceu pela primeira vez em The New Stack.