O que você precisa saber sobre a política de rede do Kubernetes

Compreender a NetworkPolicy do Kubernetes é um dos requisitos fundamentais a serem aprendidos antes de implantar um aplicativo no Kubernetes.

Com um número crescente de aplicações nativas da nuvem entrando em produção por meio da adoção do Kubernetes, a segurança é um ponto de verificação importante que você deve considerar no início do processo. Ao projetar um aplicativo nativo da nuvem, é muito importante incorporar antecipadamente uma estratégia de segurança. Não fazer isso leva a problemas de segurança persistentes que podem causar atrasos no projeto e, em última análise, custar-lhe estresse e dinheiro desnecessários.

Durante anos, as pessoas deixaram a segurança no final – até que a sua implantação estivesse prestes a entrar em produção. Essa prática causa atrasos nas entregas porque cada organização tem padrões de segurança a seguir, que são ignorados ou não seguidos com muitos riscos aceitos para fazer as entregas.

Compreender a NetworkPolicy do Kubernetes pode ser assustador para as pessoas que estão começando a aprender os detalhes da implementação do Kubernetes. Mas este é um dos requisitos fundamentais que você deve aprender antes de implantar um aplicativo em seu cluster Kubernetes. Ao aprender Kubernetes e padrões de aplicativos nativos da nuvem, crie seu slogan “Não deixe a segurança para trás!”

O conceito de Política de Rede

NetworkPolicy substitui dispositivos de firewall no contexto de data center que você conhece, como pods para instâncias de computação, plug-ins de rede para roteadores e switches e volumes para rede de área de armazenamento (SAN).

Por padrão, a NetworkPolicy do Kubernetes permite que os pods recebam tráfego de qualquer lugar. Se você não está preocupado com a segurança de seus pods, tudo bem. Mas se você estiver executando uma carga de trabalho crítica, precisará proteger seus pods. A maneira de controlar o fluxo de tráfego dentro do cluster (incluindo tráfego de entrada e saída) é por meio de NetworkPolicies.

Para ativar o NetworkPolicy, você precisa de um plug-in de rede compatível com NetworkPolicy. Caso contrário, quaisquer regras aplicadas tornar-se-ão inúteis.

Existem diferentes plug-ins de rede listados em Kubernetes.io:

Plug-ins CNI: aderem à especificação Container Network Interface (CNI), projetada para interoperabilidade.
- O Kubernetes segue a versão v0.4.0 da especificação CNI.
Plug-in Kubernetes: implementa cbr0 básico usando os plug-ins bridge e host-local CNI.

Aplicando uma política de rede

Para aplicar uma política de rede, você precisa de um cluster Kubernetes funcional com um plug-in de rede que suporte NetworkPolicy.

Mas primeiro você precisa entender como usar NetworkPolicy no contexto do Kubernetes. A NetworkPolicy do Kubernetes permite que os pods recebam tráfego de qualquer lugar. Isso não é o ideal. Para proteger os pods, você deve entender os endpoints que os pods podem se comunicar dentro da construção do Kubernetes.

Comunicação entre pods usando podSelector.

- namespaceSelector:
    matchLabels:
      project: myproject

Comunicação de namespace para namespace e comunicação de namespace para pod usando namespaceSelector e/ou uma combinação de podSelector e namespaceSelector.
```
- namespaceSelector:
    matchLabels:
      project: myproject
- podSelector:
    matchLabels:
      role: frontend
```
O IP bloqueia a comunicação dos pods usando ipBlock para definir quais blocos IP CIDR determinam a origem e o destino.
```
- ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
```

Observe a diferença entre pod, namespace e política baseada em IP. Para NetworkPolicy baseada em pod e namespace, você usa o seletor para controlar o tráfego, enquanto para NetworkPolicy baseada em IP, os controles são definidos usando blocos de IP (intervalos CIDR).

Juntando tudo, uma NetworkPolicy deve se parecer com o seguinte:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 192.168.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Fazendo referência à NetworkPolicy acima, observe a seção spec . Nesta seção, podSelector com rótulo app=backend é o alvo de nossa NetworkPolicy. Resumindo, a NetworkPolicy protege o aplicativo chamado backend dentro de um determinado namespace.

Esta seção também possui a definição de policyTypes. Este campo indica se a política fornecida se aplica ou não ao tráfego de entrada para o pod selecionado, ao tráfego de saída dos pods selecionados ou a ambos.

spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress

Agora, veja a seção entrada e egress . Esta definição determina o controle da NetworkPolicy.

Primeiro, examine a seção entrada de .

A NetworkPolicy nesta instância permite a conexão de pod de:

ipBlock
- Permitir 172.17.0.0/16
- Negar192.168.1.0/24
namespaceSelector
- myproject: permite todos os pods deste namespace e com os mesmos rótulos project=myproject.
podSelector
- frontend: permite pods que correspondem ao rótulo role=frontend

ingress:
- from:
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 192.168.1.0/24
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend

Agora, examine a seção saída para . Isso determina a conexão do pod para:

ipBlock
- 10.0.0.0/24: A conexão com este CIDR é permitida
- Portas: permissão para conexão usando TCP e porta 5978

egress:
- to:
  - ipBlock:
      cidr: 10.0.0.0/24
  ports:
  - protocol: TCP
    port: 5978

Limitações da política de rede

A NetworkPolicy por si só não pode proteger totalmente seus clusters Kubernetes. Você pode usar os componentes do sistema operacional ou as tecnologias da Camada 7 para superar as limitações conhecidas. Você precisa lembrar que NetworkPolicy só pode abordar a segurança para endereço IP e nível de porta – camada 3 ou 4 do Open Systems Interconnection (OSI).

Para atender aos requisitos de segurança que o NetworkPolicy não consegue atender, você precisa usar outras soluções de segurança. Aqui estão alguns casos de uso que você precisa saber onde o NetworkPolicy precisa ser aprimorado por outras tecnologias.

Resumo

Compreender a NetworkPolicy do Kubernetes é importante porque é uma maneira de cumprir (mas não substituir) a função de firewall que você normalmente usa em uma configuração de datacenter, mas para Kubernetes. Pense nisso como a primeira camada de segurança do seu contêiner, sabendo que o NetworkPolicy por si só não é uma solução de segurança total.

NetworkPolicy aplica segurança em pod e namespace usando seletores e rótulos. Além disso, o NetworkPolicy também pode reforçar a segurança por meio de intervalos de IP.