Controlando o tráfego com políticas de rede

Políticas de rede Calico padrão

Quando um cluster com uma VLAN pública é criado, um recurso HostEndpoint com o rótulo ibm.role: worker_public é criado automaticamente para cada nó do trabalhador e sua interface de rede pública. Este HostEndpoint faz com que todo o tráfego para ou a partir da interface de rede pública seja eliminado, a menos que seja permitido especificamente por uma política do Calico que seleciona rótulo ibm.role: worker_public.

Um recurso HostEndpoint com o rótulo ibm.role: worker_private também é criado automaticamente para cada nó do trabalhador e sua interface de rede privada. Uma política allow-all-private-default padrão é criada para que todo o tráfego seja permitido para e a partir da interface de rede privada. Este HostEndpoint torna fácil para os usuários de cluster restringir ainda mais o tráfego de rede privada criando políticas do Calico que selecionam ibm.role: worker_private e têm um número de ordem inferior ao allow-all-private-default.

Essas políticas de host do Calico padrão permitem todo o tráfego de rede de saída pública e permitem o tráfego de entrada pública para componentes específicos do cluster, como os serviços Kubernetes NodePort, LoadBalancer e Ingress. Todo o tráfego privado é permitido por padrão pela política allow-all-private-default. Qualquer outro tráfego de rede de entrada da Internet para os nós do trabalhador que não esteja especificado nas políticas padrão é bloqueado. As políticas padrão não afetam o tráfego de pod para pod.

Não remova as políticas padrão de seu cluster, pois elas são recriadas na próxima atualização ou atualização do mestre do cluster. Se você deseja restringir ainda mais o tráfego, aplique políticas do Calico de ordem inferior para bloquear o tráfego. Tenha certeza de que você entende completamente o que está bloqueando e que os componentes do cluster não precisam do tráfego que deseja bloquear.

Revise as políticas de host padrão do Calico a seguir que são aplicadas automaticamente ao seu cluster.

Instalando e Configurando o CLI do Calico

Para visualizar, gerenciar e incluir políticas do Calico, instale e configure a CLI do Calico.

1. Configure o contexto para o seu cluster executar comandos do Calico.

   • Red Hat OpenShift versão 4.6 e mais recente:

     1. Faça o download do arquivo de configuração kubeconfig para o seu cluster.

        ibmcloud oc cluster config --cluster <cluster_name_or_ID>
        

     2. Configure a variável de ambiente DATASTORE_TYPE para kubernetes.

        export DATASTORE_TYPE=kubernetes
        

2. Se as políticas de rede corporativa usam proxies ou firewalls para evitar o acesso de seu sistema local a terminais públicos, permita o acesso TCP para comandos do Calico.

3. Siga as etapas para instalar a ferramenta de linha de comandos calicoctl.

   • Linux e OS X

     1. Faça download da versão da CLI do Calico que corresponda ao seu sistema operacional. Para OS X, talvez você precise permitir manualmente que o arquivo transferido por download seja aberto e executado navegando para Preferências do sistema > Segurança e privacidade > Geral.

     2. Mova o arquivo para o diretório /usr/local/bin.

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. Torne o arquivo um arquivo executável.

        chmod +x /usr/local/bin/calicoctl
        

     4. Certifique-se de que não haja um arquivo de configuração antigo do Calico calicoctl.cfg no diretório /etc/calico. Se o arquivo /etc/calico/calicoctl.cfg existir, exclua-o.

   • Windows

     1. Faça download da CLI do Calico. Ao salvar o arquivo, renomeie para calicoctl.exe e salve-o no mesmo diretório da CLI da IBM Cloud. Essa configuração economiza algumas mudanças de caminho de arquivo ao executar comandos posteriormente.

     2. Defina a variável de ambiente KUBECONFIG como o arquivo de configuração de rede que você encontrou na etapa 1.

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/calicoctl.cfg
        

4. Verifique se a configuração do Calico está funcionando corretamente.

   calicoctl get nodes
   

   Saída de exemplo

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

A mudança do plug-in Calico, de componentes ou das configurações padrão do Calico não é suportada. Por exemplo, não implemente uma nova versão de plug-in Calico, nem modifique os conjuntos de daemons ou implementações para os componentes do Calico, recursos padrão IPPool ou nós do Calico. Em vez disso, é possível seguir a documentação para mudar a MTU do Calico ou para desativar o plug-in do mapa da porta para a CNI do Calico se necessário.

Visualizando políticas de rede

Visualize os detalhes para políticas padrão e quaisquer políticas de rede incluídas que são aplicadas a seu cluster.

Antes de iniciar, instale e configure a CLI do Calico e configure o contexto para o seu cluster executar comandos do Calico.

1. Visualize o terminal de host do Calico.

   calicoctl get hostendpoint -o yaml
   

2. Visualize todas as políticas de rede do Calico que foram criadas para o cluster. Esta lista inclui políticas que ainda podem não se aplicar a quaisquer pods ou hosts. Para que uma política do Calico seja aplicada, deve existir um pod do Kubernetes ou um HostEndpoint do Calico que corresponda ao seletor que está na política de rede do Calico.

   As políticas de rede têm o escopo definido para namespaces específicos:

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

   As políticas de rede globais não têm o escopo definido para namespaces específicos:

   calicoctl get GlobalNetworkPolicy -o wide
   

3. Visualize detalhes para uma política de rede.

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. Visualize os detalhes de todas as políticas de rede global para o cluster.

   calicoctl get GlobalNetworkPolicy -o yaml
   

Incluindo políticas de rede

Geralmente, as políticas padrão não exigem mudanças. Somente cenários avançados podem requerer mudanças. É possível criar suas próprias políticas de rede quando você acha necessário fazer mudanças.

Para criar políticas de rede do Kubernetes, consulte a Documentação de política de rede do Kubernetes.

Para criar políticas do Calico, use as etapas a seguir. Antes de iniciar, instale e configure a CLI do Calico e configure o contexto para o seu cluster executar comandos do Calico.

1. Defina a política de rede do Calico ou a política de rede global criando um script de configuração (.yaml) com a sintaxe de política do Calico v3. Esses arquivos de configuração incluem os seletores que descrevem a quais pods, namespaces ou hosts essas políticas se aplicam.

2. Aplique as políticas ao cluster. Se você tiver um sistema Windows, inclua a opção --config=<filepath>/calicoctl.cfg.

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

Note que as políticas de rede do Calico e do Kubernetes bloqueiam somente novas conexões, elas não interrompem conexões que existiam antes da aplicação da política. Portanto, depois de aplicar uma política nova ou mudada, para testar se ela está funcionando e não bloqueando mais do que deveria, faça o seguinte:

1. Reinicie os pods que podem ser afetados pela política. Melhor ainda, reinicie todos os pods, apenas para o caso de você não ter o seletor correto e isso afetar mais do que você pensa.

2. Execute ibmcloud ks cluster master refresh -c CLUSTER-ID para reiniciar seus pods do cluster mestre. Isso interromperá as conexões existentes do kubelet e outros componentes ao principal e forçará a reconexão. Isso mostrará se as políticas novas e mudadas bloqueiam as conexões necessárias aos componentes principais.

3. Tente se conectar ao console do Red Hat OpenShift on IBM Cloud para garantir que as mudanças de políticas não bloqueiem as conexões necessárias para esses componentes.

Controlando o tráfego de entrada para serviços NLB ou NodePort

Por padrão, os serviços NodePort e LoadBalancer do Kubernetes disponibilizem seu app em todas as interfaces de cluster públicas e privadas. No entanto, é possível usar políticas do Calico para bloquear o tráfego recebido para os seus serviços com base na origem ou no destino do tráfego.

As políticas padrão do Kubernetes e do Calico são difíceis de serem aplicadas para proteger os serviços do Kubernetes NodePort e LoadBalancer devido às regras do DNAT Iptables geradas para esses serviços. No entanto, as políticas pré-DNAT impedem o tráfego especificado de alcançar seus apps porque eles geram e aplicam regras de Iptables antes que o Kubernetes use DNAT regular para encaminhar o tráfego para os pods.

Alguns usos comuns para políticas de rede pré-DNAT do Calico:

• Bloquear o tráfego para portas de nó público de um serviço de balanceador de carga de rede (NLB) privada: um serviço NLB disponibiliza seu aplicativo pelo endereço IP e pela porta e, também, pelas portas do nó do serviço. As portas de nó são acessíveis em cada endereço IP (público e privado) para cada nó no cluster.
• Bloquear tráfego para portas de nó público em clusters que estão executando nós do trabalhador de borda: bloquear as portas do nó assegura que os nós do trabalhador de borda sejam os únicos nós do trabalhador que manipulam o tráfego recebido.
• Bloquear o tráfego de determinados endereços IP de origem ou CIDRs
• Permitir tráfego de apenas determinados endereços IP de origem ou CIDRs e bloquear todo o outro tráfego

Para ver como permitir ou bloquear endereços IP de origem, tente o tutorial Usando políticas de rede do Calico para bloquear o tráfego.

Políticas do Calico de exemplo para restringir o tráfego de rede pública ou privada

Nós fornecemos um conjunto de políticas de rede pública do Calico de exemplo que restringe ainda mais o tráfego de rede pública/privada em trabalhadores do cluster. Essas políticas permitem o tráfego necessário para a implantação do cluster e bloqueiam outros tipos de tráfego.

Essas políticas não destinam-se a bloquear tudo, nem necessariamente atendem aos requisitos de conformidade por si só. Elas destinam-se como um ponto de início e devem ser editadas para atender aos seus casos de uso exclusivos. Para obter mais informações, consulte o LEIA-ME.

Sempre que novos locais para o Red Hat OpenShift on IBM Cloud e outros IBM Cloud forem ativados, as sub-redes para esses locais serão incluídas nas políticas do Calico. Certifique-se observar o repositório GitHub quanto às atualizações para essas políticas.

Observe que não recomendamos mais o uso das políticas de amostra allow-egress-pods-public, allow-public-services-pods, allow-openshift-console, allow-kube-system-to-olm, allow-openshift-metrics, allow-egress-pods-private ou allow-private-services-pods nas seções de políticas de rede pública e privada abaixo. Essas políticas controlavam a saída de todos os pods no cluster. Se você quiser controlar o tráfego de/para os pods, deverá usar o Kubernetes NetworkPolicy e direcionar namespaces e pods específicos em vez de usar essas políticas gerais que tratam cada pod da mesma forma.

Controlando o tráfego entre os pods

As políticas do Kubernetes protegem os pods do tráfego de rede interna. É possível criar políticas de rede simples do Kubernetes para isolar os microsserviços do app uns dos outros dentro ou entre espaços de nomes.

Por padrão, qualquer pod tem acesso a qualquer outro pod no cluster. Além disso, qualquer pod tem acesso a qualquer serviço exposto pela rede de pod, como um serviço de métricas, o DNS do cluster, o servidor de API ou qualquer serviço criado manualmente no cluster.

Registrando o tráfego negado

Para registrar as solicitações de tráfego negado para determinados pods em seu cluster, é possível criar uma política de rede de log do Calico.

Quando você configura políticas de rede para limitar o tráfego para os pods de app, as solicitações de tráfego que não são permitidas por essas políticas são negadas e eliminadas. Em alguns cenários, é possível que você queira obter mais informações sobre solicitações de tráfego negado. Por exemplo, você pode observar algum tráfego incomum que está continuamente sendo negado por uma de suas políticas de rede. Para monitorar a potencial ameaça de segurança, é possível configurar a criação de log para registrar cada vez que a política nega uma tentativa de ação em pods de app especificados.

Essa seção mostra como registrar o tráfego negado por uma política de rede do Kubernetes. Para registrar o tráfego negado por uma política de rede do Calico, consulte a Lição 5 do tutorial de política de rede do Calico.

Antes de iniciar, instale e configure a CLI do Calico e configure o contexto para o seu cluster executar comandos do Calico.

1. Crie ou use uma política de rede existente do Kubernetes que bloqueie ou limite o tráfego recebido.

   1. Crie uma política de rede do Kubernetes. Por exemplo, para controlar o tráfego entre os pods, você pode usar o seguinte exemplo de política Kubernetes denominada access-nginx que limita o acesso a um aplicativo NGINX. O tráfego recebido para os pods que são rotulados "run=nginx" é permitido somente de pods com o rótulo "run=access". Todos os outros tráfegos recebidos para os pods de app "run=nginx" são bloqueados.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
       name: access-nginx
      spec:
       podSelector:
         matchLabels:
           run: nginx
       ingress:
         - from:
           - podSelector:
               matchLabels:
                 run: access
      

   2. Aplique a política.

      oc apply -f <policy_name>.yaml
      

2. Para registrar todo o tráfego negado pela política criada na etapa anterior, crie uma NetworkPolicy do Calico denominada log-denied-packets. A política Calico a seguir usa o mesmo seletor de pod que o exemplo de política access-nginx Kubernetes descrito na etapa 1, mas a sintaxe é ligeiramente diferente, pois é uma Calico NetworkPolicy em vez de uma Kubernetes NetworkPolicy. Além disso, como todos os Kubernetes NetworkPolicy são avaliados pelo Calico como ordem 1000, o número do pedido 3000 é incluído para assegurar que ele seja avaliado após o Kubernetes NetworkPolicy. Com essas duas políticas em vigor, aqui está o resultado:

   • As novas conexões que chegam ao pod nginx são avaliadas primeiro com relação à NetworkPolicy do Kubernetes (ordem 1000). As conexões vindas de um pod com o rótulo run=access serão aceitas imediatamente, significando que nenhuma outra política será avaliada.

   • Se a conexão estiver vindo de um pod sem o rótulo run=access (ou de qualquer coisa que não seja um pod), esse Kubernetes NetworkPolicy não fará nada e o Calico avaliará a política log-denied-packets. Essa política registra o pacote no syslog no trabalhador em que o pod nginx está.

   • Em seguida, o Calico verifica outras políticas a serem aplicadas à conexão e, como não encontra nenhuma, o pacote é eliminado. Isso ocorre porque qualquer tráfego para um pod com uma política que não é explicitamente permitida é eliminado.

     apiVersion: projectcalico.org/v3
     kind: NetworkPolicy
     metadata:
       name: log-denied-packets
     spec:
       types:
       - Ingress
       ingress:
       - action: Log
         destination: {}
         source: {}
       selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
       order: 3000
     

   types

   Esta política de Ingress se aplica a todas as solicitações de tráfego recebidas. O valor Ingress é um termo geral para todo o tráfego recebido e não se refere ao tráfego apenas do ALB do Ingress da IBM. | ingress

   : action: a ação Log grava uma entrada de log para quaisquer solicitações que correspondem a essa política para o caminho /var/log/syslog no nó do trabalhador.

   destination: Nenhum destino é especificado porque o selector aplica essa política em todos os pods com um determinado rótulo.

   source: Essa política se aplica às solicitações de qualquer fonte.

   selector

   O seletor deve destinar o mesmo tráfego que a NetworkPolicy do Kubernetes access-nginx original. Como essa é uma política Calico, você deve incluir projectcalico.org/orchestrator == 'k8s' para indicar que ela se aplica a todos os pods no namespace da política, além do run == 'nginx' original.

   order

   As políticas do Calico têm ordens que determinam quando elas são aplicadas a pacotes de solicitações recebidas. As políticas com ordens mais baixas, como 1000, são aplicadas primeiro. As políticas com ordens mais altas são aplicadas após as políticas de ordem mais baixa. Por exemplo, uma política com uma ordem muito alta, como 3000, é efetivamente aplicada por último após todas as políticas de ordem inferior terem sido aplicadas. Os pacotes de solicitações de entrada passam pela cadeia de regras do Iptables e tentam corresponder regras de políticas de ordem mais baixa primeiro. Se um pacote corresponder a qualquer regra, o pacote será aceito. No entanto, se um pacote não corresponder a nenhuma regra, ele chegará à última regra na cadeia de regras de Iptables com a ordem mais alta. Para certificar-se de que essa política seja a última política na cadeia, use um pedido muito mais alto, como 3000, do que a política criada na etapa 1. Observe que Kubernetes NetworkPolicy é aplicado como ordem 1000.

3. Aplique a política. Se você usa um computador Windows, inclua a opção --config=<filepath>/calicoctl.cfg.

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

4. Gere entradas de log enviando solicitações que não são permitidas pela política criada na etapa 1. Por exemplo, tentar fazer ping no pod protegido pela política de rede por meio de um pod ou endereço IP que não é permitido.

5. Verifique as entradas de log que são gravadas no caminho /var/log/syslog. Os endereços IP do DST (destino) ou SRC (origem) na entrada de log podem ser diferentes do esperado devido a proxies, Network Address Translation (NAT) e outros processos de rede. A entrada de log é semelhante à seguinte.

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. Opcional: encaminhe os logs de /var/log/syslog para IBM Cloud Logs.