Get best of the week

Noções básicas sobre diretivas de rede com o Calico



O Calico Network Plugin fornece uma ampla variedade de políticas de rede com uma sintaxe unificada para proteger hosts em hardware, máquinas virtuais e pods. Essas políticas podem ser aplicadas no espaço de nomes ou políticas globais de rede aplicáveis ​​ao terminal de host (para proteger aplicativos em execução diretamente no host - o servidor ou a máquina virtual pode ser o host diretamente) ou para o terminal de carga de trabalho(para proteger aplicativos em execução em contêineres ou máquinas virtuais hospedadas). As políticas do Calico permitem aplicar medidas de segurança a vários pontos no caminho do pacote usando parâmetros como preDNAT, não rastreados e applyOnForward. Compreender como essas opções funcionam pode ajudar a melhorar a segurança e o desempenho do sistema como um todo. Este artigo explica a essência dessas configurações de política do Calico (preDNAT, unraracked e applyOnForward) aplicadas aos pontos de extremidade do host, com ênfase no que acontece nos caminhos de processamento de pacotes (cadeias de iptabels).

Este artigo pressupõe que você entenda como as políticas de rede Kubernetes e Calico funcionam. Caso contrário, recomendamos que você tente o tutorial básico de diretiva de rede e o tutorial de proteção de host usando o Calico antes de ler este artigo. Também esperamos que você tenha um entendimento básico de iptables no Linux. Política de rede global da

chitapermite aplicar um conjunto de regras de acesso a rótulos (para 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 na infraestrutura do 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, através do serviço NodePorts ou IPs externos).

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

No nó Kubernetes em que o Calico está em execução, é possível mapear a interface virtual (veth) para a carga de trabalho da seguinte maneira. No exemplo abaixo, você pode ver que o veth # 10 (calic1cbf1ca0f8) está conectado ao cnx-manager- * no espaço de nome de monitoramento de chita.

[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
...



Como 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 o 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. Em seguida, é tomada uma decisão de roteamento e, com base nisso, o pacote passa pelo INPUT (direcionado aos processos do host) ou FORWARD (direcionado ao pod ou outro nó na rede). No processo local, o pacote passa pela cadeia OUTPUT e depois POSTROUTING antes de enviá-lo pelo cabo.

Observe que o pod também é um objeto externo (conectado ao veth) em termos de manipulação de iptables. Para resumir:

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



O Calico fornece opções de política para aplicar políticas a todas as cadeias. Com isso em mente, vejamos as várias configurações de política disponíveis no Calico. Os números na lista de opções abaixo correspondem aos números no diagrama acima.

  1. Política de terminal de carga de trabalho (pod)
  2. Política de terminal do host
  3. Opção ApplyOnForward
  4. Política PreDNAT
  5. Política não rastreada

Vamos começar examinando como as políticas se aplicam aos pontos de extremidade de carga de trabalho (pods de VMs Kubernetes ou OpenStack) e, em seguida, examinamos as opções de política para pontos de extremidade do host.

Pontos de extremidade de carga de trabalho


Política de Terminal de Carga de Trabalho (1)


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

Pontos de extremidade do host


Política de ponto final de host (2)


Além da CNI (interface de rede de contêiner), as políticas do Calico oferecem a capacidade de proteger diretamente o host. No Calico, você pode criar um terminal 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 essa entidade é alcançada usando a tabela de filtros nas cadeias INPUT e OUTPUT. Como pode ser visto no diagrama, (2) eles são aplicados aos processos locais no nó / host. Ou seja, se você criou uma política que se aplica ao ponto de extremidade do host, ela 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. Isso simplifica bastante o processo de gerenciamento de políticas para uma rede heterogênea. A configuração de políticas de terminal do host para aprimorar a proteção de cluster é outro caso de uso importante.

Política ApplyOnForward (3)


A opção ApplyOnForward está disponível na política de rede global Calico para permitir que as políticas se apliquem a todo o tráfego que passa pelo terminal do host, incluindo o tráfego que será encaminhado pelo host. Esse tráfego inclui o envio a um pod local ou a qualquer outro lugar da rede. O Calico exige que essa configuração seja ativada para políticas que usam PreDNAT e não rastreadas, consulte as seções a seguir. Além disso, o ApplyOnForward pode ser usado para rastrear o tráfego do host ao usar um roteador virtual ou NAT de software.

Observe que, se você precisar aplicar a mesma política de rede aos processos e pods do host, não precisará usar a opção ApplyOnForward. Você só precisa criar um rótulo para o ponto de host e o ponto de extremidade de carga de trabalho (pod) desejados. O Calico é inteligente o suficiente para aplicar políticas baseadas em rótulos, independentemente do tipo de terminal (terminal de host ou carga de trabalho).

Política PreDNAT (4)


No Kubernetes, as portas da entidade de serviço podem ser lançadas para fora usando a opção NodePorts ou, opcionalmente (ao usar o Calico), declarando-as pelas opções IPs de cluster ou IPs externos. O proxy Kube equilibra o tráfego recebido vinculado ao serviço para os pods do serviço correspondente usando DNAT. Diante disso, como você aplica políticas ao tráfego proveniente dos NodePorts? Para que essas políticas sejam aplicadas antes do processamento do tráfego pelo DNAT (que é um mapeamento entre host: porta e serviço correspondente), o Calico fornece um parâmetro para globalNetworkPolicy chamado "preDNAT: true".

Quando o pré-DNAT é ativado, essas políticas são implementadas em (4) no diagrama - na tabela mangle da cadeia PREROUTING - imediatamente antes do DNAT. A política de pedidos usual não é respeitada aqui, pois a aplicação dessas políticas ocorre muito antes no caminho do processamento do tráfego. No entanto, as políticas preDNAT respeitam a ordem de aplicação entre si.

Ao criar políticas com pré-DNAT, é importante estar atento ao tráfego que você deseja processar e permitir que a maioria seja rejeitada. O tráfego marcado como 'allow' na política pré-DNAT não será mais verificado pela política de ponto de extremidade, enquanto o tráfego quando a política pré-DNAT falhar continuará a fluir pelo restante das cadeias.
O Calico tornou obrigatório ativar a opção applyOnForward ao usar o preDNAT, porque, por definição, o destino do tráfego ainda não foi selecionado. O tráfego pode ser direcionado para o processo host ou pode ser redirecionado para um pod ou para 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 curto prazo. Isso pode levar à falta de memória para o conntrack (o principal componente da pilha de rede Linux). Tradicionalmente, para executar esse tipo de aplicativo no Linux, você precisa configurar ou desativar manualmente o conntrack ou escrever regras do iptables para ignorar o conntrack. A política não acompanhada no Calico é uma opção mais simples e mais eficiente se você deseja processar as conexões o mais rápido possível. Por exemplo, se você usar o memcache maciço ou como uma medida adicional de proteção contra o DDOS .

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

Quando você define a opção “doNotTrack: true” como Calico globalNetworkPolicy, ela se torna uma política ** não rastreada ** e é aplicada no estágio inicial do pipeline de processamento de pacotes do Linux. Se você observar o diagrama acima, as políticas não rastreadas serão aplicadas nas cadeias PREROUTING e OUTPUT na tabela bruta antes de o rastreamento de conexão (conntrack) ser iniciado. Quando um pacote é permitido por uma política não rastreada, é sinalizado para desativar o rastreamento de conexão para este pacote. Isso significa:

  • Uma política não rastreada é aplicada para cada pacote. Não há conceito de conexão (ou fluxo). A falta de conexões acarreta várias consequências importantes:
  • , , , ( Calico conntrack, ).
  • untracked workload Kubernetes (pod’), pod’.
  • NAT ( ​​ NAT conntrack).
  • « » untracked- . , , untracked- ( ).
  • As políticas não rastreadas são aplicadas no início do pipeline de processamento de pacotes. Isso é muito importante para entender ao criar políticas do Calico. Você pode ter uma política para um pod com o pedido: 1 e uma política não rastreada com o pedido: 1000. Isso não importa. A política não rastreada será aplicada antes da política para o pod. Políticas não rastreadas respeitam a ordem de execução apenas entre si.

Como um dos objetivos da política doNotTrack é impor a política no estágio inicial do 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 não rastreada (5) é aplicada antes de qualquer decisão de roteamento. O tráfego pode ser direcionado para o processo host ou pode ser redirecionado para um pod ou para outro nó.

Sumário


Examinamos as várias opções de política (ponto de extremidade do host, ApplyOnForward, preDNAT e Untracked) no Calico e como elas se aplicam ao processamento de pacotes. Compreender a essência de seu trabalho ajuda no desenvolvimento de políticas eficazes e seguras. Com o Calico, você pode usar a política de rede global, que se aplica ao rótulo (um grupo de nós e pods) e aplicar políticas com vários parâmetros. Isso permite que os especialistas em segurança e design de rede protejam convenientemente imediatamente "tudo" (tipos de terminais) usando o mesmo idioma de política das políticas do Calico.


Agradecimento: Gostaria de agradecer a Sean Crampton e Alex Pollitt pela revisão e pelas informações valiosas.

More articles:


All Articles