🥇Compreendendo as opções de política de rede com Calico

O plugin de rede Calico fornece uma ampla gama de políticas de rede com uma sintaxe unificada para proteger hosts de hardware, máquinas virtuais e pods. Essas políticas podem ser aplicadas dentro de um namespace ou ser políticas de rede global que se aplicam a ponto final do host (para proteger aplicativos executados diretamente no host - o host pode ser um servidor ou uma máquina virtual) ou ponto final da carga de trabalho (para proteger aplicativos executados em contêineres ou máquinas virtuais hospedadas). As políticas do Calico permitem que você aplique medidas de segurança em vários pontos do caminho de um pacote usando opções como preDNAT, unracked e applyOnForward. Compreender como essas opções funcionam pode ajudar a melhorar a segurança e o desempenho de seu sistema geral. Este artigo explica a essência dessas opções de política Calico (preDNAT, unraracked e applyOnForward) aplicadas a endpoints de host, com ênfase no que acontece nos caminhos de processamento de pacotes (cadeias iptabels).

Este artigo pressupõe que você tenha um conhecimento básico de como funcionam as políticas de rede Kubernetes e Calico. Se não, recomendamos tentar tutorial básico de política de rede и tutorial de proteção de host usando Calico antes de ler este artigo. Também esperamos que você tenha uma compreensão básica do trabalho iptables em linux.

Chita política de rede global permite aplicar um conjunto de regras de acesso por rótulos (a grupos de hosts e cargas de trabalho/pods). Isso é muito útil se você usar sistemas heterogêneos juntos - máquinas virtuais, um sistema diretamente no hardware ou uma infraestrutura Kubernetes. Além disso, você pode proteger seu cluster (nós) usando um conjunto de políticas declarativas e aplicar políticas de rede ao tráfego de entrada (por exemplo, por meio do serviço NodePorts ou IPs externos).

Em um nível fundamental, quando o Calico conecta um pod à rede (veja o diagrama abaixo), ele o conecta ao host usando uma interface Ethernet virtual (veth). O tráfego enviado pelo pod chega ao host a partir dessa interface virtual e é processado da mesma forma como se viesse de uma interface de rede física. Por padrão, o Calico chama essas interfaces de caliXXX. Como o tráfego passa pela interface virtual, ele passa pelo iptables como se o pod estivesse a um salto de distância. Portanto, quando o tráfego chega/de um pod, ele é encaminhado do ponto de vista do host.

Em um nó do Kubernetes executando o Calico, é possível mapear uma interface virtual (veth) para uma carga de trabalho da seguinte maneira. No exemplo abaixo, você pode ver que veth#10 (calic1cbf1ca0f8) está conectado a cnx-manager-* no namespace calico-monitoring.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

Dado que o Calico cria uma interface veth para cada carga de trabalho, como ele aplica políticas? Para fazer isso, o Calico cria ganchos em várias cadeias do caminho de processamento de pacotes usando iptables.

O diagrama abaixo mostra as cadeias envolvidas no processamento de pacotes no iptables (ou no subsistema netfilter). Quando um pacote chega através de uma interface de rede, ele primeiro passa pela cadeia PREROUTING. Uma decisão de roteamento é então tomada e, com base nisso, o pacote passa por INPUT (direcionado aos processos host) ou FORWARD (direcionado a um pod ou outro nó na rede). A partir do processo local, o pacote passa pela cadeia OUTPUT e depois POSTROUTING antes de ser enviado pelo cabo.

Observe que o pod também é uma entidade externa (conectada ao veth) em termos de processamento de iptables. Vamos resumir:

O tráfego encaminhado (nat, roteado ou de/para um pod) passa pelas cadeias PREROUTING - FORWARD - POSTROUTING.
O tráfego para o processo host local passa pela cadeia PREROUTING - INPUT.
O tráfego do processo host local passa pela cadeia OUTPUT - POSTROUTING.

Calico oferece opções de políticas que permitem aplicar políticas em todas as cadeias. Com isso em mente, vejamos as diferentes opções de configuração de política disponíveis no Calico. Os números na lista de opções abaixo correspondem aos números do diagrama acima.

Política de endpoint de carga de trabalho (pod)
Política de endpoint do host
Opção ApplyOnForward
Política Pré-DNAT
Política não rastreada

Vamos começar observando como as políticas são aplicadas aos endpoints de carga de trabalho (pods Kubernetes ou VMs OpenStack) e, em seguida, examinar as opções de política para endpoints de host.

Terminais de carga de trabalho

Política de endpoint de carga de trabalho (1)

Esta é uma opção para proteger seus pods do Kubernetes. Calico oferece suporte para trabalhar com Kubernetes NetworkPolicy, mas também fornece políticas adicionais - Calico NetworkPolicy e GlobalNetworkPolicy. Calico cria uma cadeia para cada pod (carga de trabalho) e conecta as cadeias INPUT e OUTPUT da carga de trabalho à tabela de filtros da cadeia FORWARD.

Pontos finais de host

Política de endpoint de host (2)

Além da CNI (interface de rede de contêineres), as políticas do Calico fornecem a capacidade de proteger o próprio host. No Calico, você pode criar um endpoint de host especificando uma combinação da interface do host e, se necessário, números de porta. A aplicação de políticas para esta entidade é obtida usando uma tabela de filtros nas cadeias INPUT e OUTPUT. Como você pode ver no diagrama, (2) eles se aplicam a processos locais no nó/host. Ou seja, se você criar uma política que se aplique ao endpoint do host, isso não afetará o tráfego de/para seus pods. Mas fornece uma interface/sintaxe única para bloquear o tráfego para seu host e pods usando políticas do Calico. Isto simplifica muito o processo de gerenciamento de políticas para uma rede heterogênea. Configurar políticas de endpoint de host para aprimorar a segurança do cluster é outro caso de uso importante.

Política ApplyOnForward (3)

A opção ApplyOnForward está disponível na política de rede global do Calico para permitir que políticas sejam aplicadas a todo o tráfego que passa pelo endpoint do host, incluindo o tráfego que será encaminhado pelo host. Isso inclui o tráfego encaminhado para o pod local ou para qualquer outro lugar da rede. O Calico exige que essa configuração seja habilitada para políticas que usam PreDNAT e não rastreadas. Consulte as seções a seguir. Além disso, ApplyOnForward pode ser usado para monitorar o tráfego do host nos casos em que um roteador virtual ou software NAT é usado.

Observe que se você precisar aplicar a mesma política de rede aos processos de host e aos pods, não será necessário usar a opção ApplyOnForward. Tudo o que você precisa fazer é criar um rótulo para o hostendpoint e o endpoint de carga de trabalho (pod) necessários. O Calico é inteligente o suficiente para aplicar políticas baseadas em rótulos, independentemente do tipo de endpoint (hostendpoint ou carga de trabalho).

Política Pré-DNAT (4)

No Kubernetes, as portas da entidade de serviço podem ser expostas externamente usando a opção NodePorts ou, opcionalmente (ao usar o Calico), anunciando-as usando as opções Cluster IPs ou External IPs. O proxy Kube equilibra o tráfego de entrada vinculado a um serviço para os pods do serviço correspondente usando DNAT. Diante disso, como você aplica políticas para o tráfego que passa por NodePorts? Para garantir que essas políticas sejam aplicadas antes que o tráfego seja processado pelo DNAT (que é um mapeamento entre host:porta e o serviço correspondente), o Calico fornece um parâmetro para globalNetworkPolicy chamado "preDNAT: true".

Quando o pré-DNAT está habilitado, essas políticas são implementadas em (4) no diagrama - na tabela mangle da cadeia PREROUTING - imediatamente antes do DNAT. A ordem usual das políticas não é seguida aqui, uma vez que a aplicação destas políticas ocorre muito mais cedo no caminho de processamento do tráfego. Contudo, as políticas pré-DNAT respeitam a ordem de aplicação entre si.

Ao criar políticas com pré-DNAT, é importante ter cuidado com o tráfego que se deseja processar e permitir que a maioria seja rejeitada. O tráfego marcado como 'permitir' na política pré-DNAT não será mais verificado pela política hostendpoint, enquanto o tráfego que falhar na política pré-DNAT continuará pelas cadeias restantes.
A Calico tornou obrigatória a habilitação da opção applyOnForward ao usar o preDNAT, pois por definição o destino do tráfego ainda não foi selecionado. O tráfego pode ser direcionado para o processo host ou encaminhado para um pod ou outro nó.

Política não rastreada (5)

Redes e aplicativos podem ter grandes diferenças de comportamento. Em alguns casos extremos, os aplicativos podem gerar muitas conexões de curta duração. Isso pode fazer com que o conntrack (um componente central da pilha de rede do Linux) fique sem memória. Tradicionalmente, para executar esses tipos de aplicativos no Linux, você teria que configurar ou desabilitar manualmente o conntrack, ou escrever regras de iptables para ignorar o conntrack. A política não rastreada no Calico é uma opção mais simples e eficiente se você deseja processar conexões o mais rápido possível. Por exemplo, se você usar massivo memcache ou como medida adicional de proteção contra DDOS.

Leia isso no blog (ou nossa tradução) para obter mais informações, incluindo testes de desempenho usando política não rastreada.

Quando você define a opção "doNotTrack: true" no Calico globalNetworkPolicy, ela se torna uma política **untracked** e é aplicada bem no início do pipeline de processamento de pacotes do Linux. Observando o diagrama acima, as políticas não rastreadas são aplicadas nas cadeias PREROUTING e OUTPUT na tabela bruta antes que o rastreamento da conexão (conntrack) seja iniciado. Quando um pacote é permitido pela política não rastreada, ele é marcado para desabilitar o rastreamento de conexão desse pacote. Isso significa:

A política não rastreada é aplicada por pacote. Não existe conceito de conexão (ou fluxo). A falta de conexões tem várias consequências importantes:
Se quiser permitir o tráfego de solicitação e resposta, você precisará de uma regra para entrada e saída (já que o Calico normalmente usa conntrack para marcar o tráfego de resposta como permitido).
A política untracked não funciona para cargas de trabalho (pods) do Kubernetes, porque nesse caso não há como rastrear a conexão de saída do pod.
O NAT não funciona corretamente com pacotes não rastreados (já que o kernel armazena o mapeamento NAT no conntrack).
Ao passar pela regra “permitir todos” na política não rastreada, todos os pacotes serão marcados como não rastreados. Quase sempre isso não é o que você deseja, por isso é importante ser muito seletivo quanto aos pacotes permitidos pelas políticas não rastreadas (e permitir que a maior parte do tráfego passe pelas políticas rastreadas normais).
Políticas não rastreadas são aplicadas logo no início do pipeline de processamento de pacotes. É muito importante entender isso ao criar políticas da Calico. Você pode ter uma política de pod com pedido:1 e uma política não rastreada com pedido:1000. Não importa. A política Untracked será aplicada antes da política do pod. As políticas não rastreadas respeitam a ordem de execução apenas entre si.

Como um dos propósitos da política doNotTrack é impor a política muito cedo no pipeline de processamento de pacotes do Linux, o Calico torna obrigatório especificar a opção applyOnForward ao usar doNotTrack. Referindo-se ao diagrama de processamento de pacotes, observe que a política untracked(5) é aplicada antes de qualquer decisão de roteamento. O tráfego pode ser direcionado para o processo host ou encaminhado para um pod ou outro nó.

Resultados de

Analisamos as várias opções de política (endpoint do host, ApplyOnForward, preDNAT e Untracked) no Calico e como elas são aplicadas ao longo do caminho de processamento de pacotes. Compreender como funcionam ajuda no desenvolvimento de políticas eficazes e seguras. Com o Calico você pode usar uma política de rede global que se aplica a um rótulo (um grupo de nós e pods) e aplicar políticas com vários parâmetros. Isso permite que os profissionais de segurança e design de rede protejam convenientemente “tudo” (tipos de endpoint) de uma só vez, usando uma única linguagem de política com as políticas Calico.

Agradecimento: Gostaria de agradecer Sean Crampton и Alexa Pollitta pela sua revisão e informações valiosas.

Fonte: habr.com

Noções básicas sobre opções de política de rede com Calico