Compartilhar via

Criptografia no trânsito com WireGuard (pré-visualização pública)

À medida que as organizações dependem cada vez mais do AKS (Serviço de Kubernetes do Azure) para executar cargas de trabalho em contêineres, garantir que a segurança do tráfego de rede entre aplicativos e serviços se torne essencial especialmente em ambientes regulamentados ou sensíveis à segurança. A criptografia em trânsito com WireGuard protege os dados enquanto se movem entre pods e nós, reduzindo os riscos de interceptação ou adulteração. O WireGuard é conhecido por sua simplicidade e criptografia robusta, oferece uma solução poderosa para proteger a comunicação dentro de clusters do AKS.

A criptografia WireGuard para AKS faz parte do conjunto de recursos de ACNS (Serviços Avançados de Rede de Contêiner) e sua implementação é baseada no Cilium.

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Escopo de criptografia do WireGuard

A criptografia em trânsito do WireGuard no AKS foi projetada para proteger fluxos de tráfego específicos no cluster do Kubernetes. Esta seção descreve quais tipos de tráfego são criptografados e que atualmente não têm suporte por meio de ACNS (Serviços Avançados de Rede de Contêiner).

Fluxos de tráfego com suporte/criptografados:

  • Tráfego de pod entre nós: tráfego que sai de um pod de um nó com destino a um pod em outro nó.

Fluxos de tráfego sem suporte/não criptografados

  • Tráfego de pod no mesmo nó: tráfego entre pods no mesmo nó
  • Tráfego de rede de nó: tráfego gerado pelo próprio nó destinado a outro nó

Visão geral da arquitetura

A criptografia WireGuard depende da CNI do Azure da plataforma Cilium para proteger as comunicações entre nós em um sistema distribuído. A arquitetura usa um agente dedicado do WireGuard que orquestra o gerenciamento de chaves, a configuração da interface e as atualizações dinâmicas de pares. Esta seção tenta fornecer uma explicação detalhada

Diagrama do design do WireGuard.

Agente WireGuard

Após a inicialização, o agente do Cilium avalia sua configuração para determinar se a criptografia está habilitada. Quando o WireGuard é selecionado como o modo de criptografia, o agente inicializa um subsistema WireGuard dedicado. O agente wireguard é responsável por configurar e inicializar componentes necessários para impor a criptografia WireGuard.

Geração de chave

Um requisito fundamental para proteger a comunicação é a geração de pares de chaves criptográficas. Cada nó no cluster do Kubernetes gerará automaticamente um par de chaves exclusivo do WireGuard durante a fase de inicialização e distribuirá sua chave pública por meio da anotação "network.cilium.io/wg-pub-key" no objeto de recurso personalizado Kubernetes CiliumNode. Os pares de chaves são armazenados na memória e girados a cada 120 segundos. A chave privada serve como identidade confidencial do nó. A chave pública é compartilhada com os nós pares no cluster para descriptografar e criptografar o tráfego de e para os pontos de extremidade gerenciados pelo Cilium em execução nesse nó. Essas chaves são totalmente gerenciadas pelo Azure, não pelo cliente, garantindo o tratamento seguro e automatizado sem a necessidade de intervenção manual. Esse mecanismo garante que somente nós com credenciais validadas possam participar da rede criptografada.

Criação de interface

Depois que o processo de geração de chave for concluído, o agente WireGuard configurará um adaptador de rede dedicado (cilium_wg0). Esse processo envolve a criação e a configuração da interface com a chave privada gerada anteriormente.

Comparação com a criptografia de rede virtual

O Azure oferece várias opções para proteger o tráfego em trânsito no AKS, incluindo criptografia em nível de rede virtual e criptografia baseada em WireGuard. Embora ambas as abordagens aprimorem a confidencialidade e a integridade do tráfego de rede, elas diferem nos requisitos de escopo, flexibilidade e implantação. Esta seção ajuda você a entender quando usar cada solução.

Usar criptografia de rede virtual quando

  • Você precisa de criptografia de camada de rede completa para todo o tráfego na rede virtual: A criptografia de rede virtual garante que todo o tráfego, independentemente da carga de trabalho ou da camada de orquestração, seja criptografado automaticamente à medida que atravessa a Rede Virtual do Azure.

  • Você precisa de uma sobrecarga mínima de desempenho: A criptografia de rede virtual usa aceleração de hardware em SKUs de VM compatíveis, descarregando a criptografia do sistema operacional para o hardware subjacente. Esse design fornece alta taxa de transferência com baixo uso da CPU.

  • Todas as máquinas virtuais dão suporte à criptografia de rede virtual: A criptografia de rede virtual depende de SKUs de VM que dão suporte à aceleração de hardware necessária. Se sua infraestrutura consistir inteiramente em SKUs com suporte, a criptografia de rede virtual poderá ser habilitada perfeitamente.

  • As configurações de rede do AKS dão suporte à criptografia de rede virtual: A criptografia de rede virtual tem algumas limitações quando se trata de rede de pod do AKS. Para obter mais informações, consulte cenários com suporte de criptografia de rede virtual

Quando usar a criptografia WireGuard

  • Você deseja garantir que o tráfego do aplicativo seja criptografado em todos os nós; a criptografia de rede virtual não criptografa tráfego entre nós no mesmo host físico.

  • Você deseja unificar a criptografia em ambientes híbridos ou de várias nuvens: O WireGuard oferece uma solução independente de nuvem, permitindo criptografia consistente entre clusters em execução em diferentes provedores de nuvem ou localmente.

  • Você não precisa ou deseja criptografar todo o tráfego dentro da rede virtual: O WireGuard permite uma estratégia de criptografia mais direcionada ideal para proteger cargas de trabalho confidenciais sem incorrer na sobrecarga de criptografar todo o tráfego.

  • Algumas de suas SKUs de VM não dão suporte à criptografia de rede virtual: O WireGuard é implementado em software e funciona independentemente do suporte a hardware de VM, tornando-o uma opção prática para ambientes heterogêneos.

Considerações e limitações

• O WireGuard não é compatível com FIPS . • A criptografia WireGuard não se aplica a pods que usam a rede do host (spec.hostNetwork: true) porque esses pods usam a identidade do host em vez de possuírem identidades individuais.

Importante

A criptografia WireGuard opera no nível de software, o que pode introduzir latência e afetar o desempenho da taxa de transferência. A extensão desse impacto depende de vários fatores, incluindo o tamanho da VM (SKU do nó), a configuração de rede e os padrões de tráfego do aplicativo. Nosso benchmarking indica que a taxa de transferência é limitada a 1,5 Gbps com uma MTU de 1500; no entanto, os resultados podem variar dependendo das características da carga de trabalho e da configuração do cluster. O uso de uma SKU que dá suporte à MTU 3900 resultou em uma taxa de transferência aproximadamente 2,5x maior. Embora a criptografia WireGuard possa ser usada junto com as políticas de rede, isso pode levar a uma degradação de desempenho adicional, com taxa de transferência reduzida e maior latência. Para aplicativos sensíveis à latência ou à taxa de transferência, é altamente recomendável avaliar o WireGuard em um ambiente de não produção primeiro. Como sempre, os resultados podem variar com base nas características da carga de trabalho e na configuração do cluster.

Pricing

Importante

Os Serviços Avançados de Rede de Contêineres são uma oferta paga. Para obter mais informações sobre preços, consulte Serviços Avançados de Rede de Contêineres – Preços.

Próximas etapas

  • Last updated on