Limitar o tráfego do pod com políticas de rede do Kubernetes - Amazon EKS
Visão geralPolítica de rede padrãoPolítica de rede do administrador (ou do cluster)Observações importantesConsiderações

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Limitar o tráfego do pod com políticas de rede do Kubernetes

Visão geral

Por padrão, não há restrições no Kubernetes para endereços IP, portas ou conexões entre os pods do cluster ou entre os pods e os recursos de qualquer outra rede. Você pode usar uma política de rede do Kubernetes para restringir o tráfego de rede que entra e sai dos pods. Para obter mais informações, consulte Políticas de rede na documentação do Kubernetes.

Política de rede padrão

Você pode usar a política NetworkPolicy padrão para segmentar o tráfego entre pods no cluster. Essas políticas de rede operam nas camadas 3 e 4 do modelo de rede OSI, permitindo controlar o fluxo de tráfego no nível de endereço IP ou de porta dentro do cluster do Amazon EKS. As políticas de rede padrão têm escopo definido no nível do namespace.

Casos de uso

  • Realize a segmentação do tráfego de rede entre as workloads para assegurar que a comunicação ocorra apenas entre aplicações relacionadas.

  • Realize o isolamento dos locatários por namespace, usando políticas para garantir a separação de rede.

Exemplo

Na política abaixo, o tráfego de saída proveniente dos pods webapp no namespace sun é restrito.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-egress-policy
  namespace: sun
spec:
  podSelector:
    matchLabels:
      role: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: moon
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - namespaceSelector:
        matchLabels:
          name: stars
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

A política é aplicada aos pods com o rótulo role: webapp no namespace sun.

  • Tráfego permitido: pods com o rótulo role: frontend no namespace moon na porta TCP 8080

  • Tráfego permitido: pods com o rótulo “role: frontend” no namespace stars na porta TCP 8080

  • Tráfego bloqueado: todo o restante do tráfego de saída proveniente dos pods webapp é negado implicitamente

Política de rede do administrador (ou do cluster)

Ilustração da ordem de avaliação das políticas de rede no EKS

É possível usar a política ClusterNetworkPolicy para impor um padrão de segurança de rede válido para todo o cluster. Em vez de criar e gerenciar uma política diferente para cada namespace de forma repetitiva, é possível usar uma política única para o controle centralizado do acesso à rede de diversas workloads no cluster, independentemente do namespace em que estejam.

Casos de uso

  • Gerencie de forma centralizada o acesso à rede de todas as workloads (ou de um grupo específico delas) no seu cluster do EKS.

  • Defina uma postura de segurança de rede padrão em todo o cluster.

  • Amplie os padrões de segurança organizacionais ao escopo do cluster com maior eficiência operacional.

Exemplo

Na política abaixo, é possível bloquear explicitamente o tráfego do cluster proveniente de outros namespaces para impedir o acesso de rede a um namespace da workload sensível.

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

Observações importantes

As políticas de rede no plug-in CNI da Amazon VPC para Kubernetes são compatíveis com as configurações listadas abaixo.

  • Versão 1.21.0 (ou versões posteriores) do plug-in CNI da Amazon VPC para políticas de rede padrão e de administração.

  • Cluster configurado para endereços IPv4 ou IPv6.

  • Você pode usar políticas de rede com grupos de segurança para Pods. Com as políticas de rede, você pode controlar toda a comunicação dentro do cluster. Com os grupos de segurança para pods, você pode controlar o acesso aos serviços da AWS de aplicações em um pod.

  • Você pode usar políticas de rede com rede personalizada e delegação de prefixo.

Considerações

Arquitetura do

  • Ao aplicar as políticas de rede do plug-in CNI da Amazon VPC para Kubernetes ao cluster com o plug-in CNI da Amazon VPC para Kubernetes, você só poderá aplicar as políticas aos nós do Linux do Amazon EC2. Você não pode aplicar as políticas aos nós do Fargate ou do Windows.

  • As políticas de rede se aplicam somente a endereços IPv4 ou IPv6, mas não a ambos. Em um cluster IPv4, a VPC CNI atribui endereços IPv4 aos pods e aplica políticas de IPv4. Em um cluster IPv6, a VPC CNI atribui endereços IPv6 aos pods e aplica políticas de IPv6. Todas as regras de política de rede IPv4 aplicadas a um cluster IPv6 são ignoradas. Todas as regras de política de rede IPv6 aplicadas a um cluster IPv4 são ignoradas.

Políticas de rede

  • As políticas de rede são aplicadas somente a pods que fazem parte de uma implantação. Os pods autônomos que não têm um conjunto metadata.ownerReferences não podem ter políticas de rede aplicadas a eles.

  • Você pode aplicar várias políticas de rede ao mesmo pod. Quando duas ou mais políticas que selecionam o mesmo pod estão configuradas, todas as políticas são aplicadas ao pod.

  • O número máximo de combinações de portas e protocolos para um único intervalo de endereços IP (CIDR) é 24 em todas as suas políticas de rede. Seletores como namespaceSelector resolvem para um ou mais CIDRs. Se vários seletores forem resolvidos para um único CIDR ou você especificar o mesmo CIDR direto várias vezes na mesma política de rede ou em políticas de rede diferentes, todos eles contarão para esse limite.

  • Para qualquer serviço do Kubernetes, a porta de serviço deve ser a mesma que porta de contêiner. Se você estiver usando portas nomeadas, use o mesmo nome na especificação do serviço.

Políticas de rede de administração

  1. Políticas do nível de Administrador (avaliadas primeiro): todas as ClusterNetworkPolicies do nível de Administrador são avaliadas antes de quaisquer outras políticas. No nível de Administrador, o processamento das políticas segue a ordem de prioridade (o menor número de prioridade tem precedência). O tipo de ação determina o que acontece em seguida no processamento.

    • Ação de negação (maior precedência): quando uma política de Administrador com uma ação de negação corresponde ao tráfego, esse tráfego é bloqueado imediatamente, independentemente de quaisquer outras políticas. O processamento de quaisquer outras regras de ClusterNetworkPolicy ou NetworkPolicy é interrompido. Isso garante que os controles de segurança de nível organizacional não possam ser substituídos por políticas de nível de namespace.

    • Ação de permissão: uma vez avaliadas as regras de negação, as políticas de Administrador com a ação de permissão entram em processamento seguindo a ordem de prioridade (o menor número de prioridade tem precedência). Se o tráfego coincidir com uma regra de permissão, ele é liberado imediatamente e o processo de avaliação de políticas é encerrado. Essas políticas podem conceder acesso entre diversos namespaces com base em seletores de rótulos, oferecendo controle centralizado sobre quais workloads podem acessar recursos específicos.

    • Ação de aprovação: as ações de aprovação nas políticas do nível de Administrador delegam a tomada de decisão para os níveis inferiores. Quando o tráfego corresponde a uma regra de aprovação, a avaliação ignora todas as regras restantes do nível de Administrador para esse tráfego e prossegue diretamente para o nível de NetworkPolicy. Dessa forma, os administradores conseguem transferir formalmente o controle de padrões específicos de tráfego para as equipes responsáveis pelas aplicações. Por exemplo, é possível usar regras de aprovação para delegar o gerenciamento do tráfego interno do namespace aos administradores do namespace, enquanto mantém controles rígidos sobre o acesso externo.

  2. Nível de política de rede: se nenhuma política do nível de Administrador corresponder às ações de negação ou de aprovação, ou se uma ação de aprovação for acionada, os recursos de NetworkPolicy com escopo de namespace são avaliados em seguida. Essas políticas oferecem controle granular nos namespaces individuais e são gerenciadas pelas equipes responsáveis pela aplicação. As políticas com escopo de namespace conseguem apenas aumentar a restrição imposta pelas políticas de Administrador. Eles não podem substituir a decisão de negação de uma política de Administrador, mas podem restringir ainda mais o tráfego que foi permitido ou aprovado pelas políticas de Administrador.

  3. Políticas de Administrador do nível de Linha de Base: se nenhuma política do nível de Administrador ou de escopo de namespace corresponder ao tráfego, as ClusterNetworkPolicies do nível de Linha de Base são avaliadas. Estas políticas fornecem posturas de segurança padrão que podem ser substituídas por políticas com escopo de namespace, permitindo que os administradores definam padrões para toda a organização, enquanto oferecem flexibilidade às equipes para realizar personalizações conforme necessário. A avaliação das políticas de Linha de Base respeita a ordem de prioridade, na qual o menor número de prioridade tem precedência.

  4. Negação padrão (se nenhuma política corresponder): este comportamento de negação por padrão garante que apenas conexões explicitamente permitidas sejam autorizadas, mantendo uma postura de segurança robusta.

Migração

  • Se o cluster estiver usando atualmente uma solução de terceiros para gerenciar as políticas de rede do Kubernetes, você poderá usar essas mesmas políticas com o plug-in CNI da Amazon VPC para Kubernetes. Porém, você deve remover a solução existente para que ela não gerencie as mesmas políticas.

Atenção

Recomendamos que, depois de remover uma solução de política de rede, você substitua todos os nós que tiveram a solução de política de rede aplicada a eles. Isso ocorre porque as regras de tráfego podem ser deixadas para trás por um pod da solução se ele sair repentinamente.

Instalação

  • O atributo de política de rede cria e exige uma definição de atributos personalizados (CRD) de PolicyEndpoint denominada policyendpoints.networking.k8s.aws. Os objetos de PolicyEndpoint do atributo personalizado são gerenciados pelo Amazon EKS. Você não deve modificar nem excluir esses recursos.

  • Se você executar pods que usem as credenciais do IAM do perfil da instância ou se conectar ao IMDS do EC2, tenha o cuidado de verificar as políticas de rede que bloqueariam o acesso ao IMDS do EC2. Pode ser necessário adicionar uma política de rede para permitir o acesso ao IMDS do EC2. Para obter mais informações, consulte Metadados da instância e dados do usuário no Manual do usuário do Amazon EC2.

    Pods que usam perfis do IAM para contas de serviço ou identidade de Pods do EKS não acessam o IDMS do EC2.

  • O plug-in CNI da Amazon VPC para Kubernetes não aplica políticas de rede a interfaces de rede adicionais para cada pod, somente à interface primária para cada pod (eth0). Isso afeta as seguintes arquiteturas:

    • Pods IPv6 com a variável ENABLE_V4_EGRESS definida como true. Essa variável permite que o recurso de saída IPv4 conecte os pods IPv6 a endpoints IPv4, como aqueles fora do cluster. O funcionamento do recurso de saída IPv4 se dá com a criação de uma interface de rede adicional com um endereço IPv4 de loopback local.

    • Ao usar plug-ins de rede encadeados, como o Multus. Como esses plug-ins adicionam interfaces de rede a cada pod, as políticas de rede não são aplicadas aos plug-ins de rede encadeados.