Usar políticas de rede com o Modo Automático do EKS - Amazon EKS
Visão geralIntroduçãoComo funciona?Consideraçõ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.

Usar políticas de rede com o Modo Automático do EKS

Visão geral

À medida que os clientes escalam os ambientes de aplicação usando o EKS, o isolamento do tráfego de rede torna-se cada vez mais fundamental para evitar o acesso não autorizado a recursos internos e externos ao cluster. Isso é especialmente importante em um ambiente de multilocação, no qual diversas workloads distintas são executadas simultaneamente no mesmo cluster. As políticas de rede do Kubernetes permitem reforçar a postura de segurança de rede das workloads do Kubernetes, incluindo integrações com endpoints externos ao cluster. O modo automático do EKS oferece suporte a diversos tipos de políticas de rede.

Isolamento nas camadas 3 e 4

As políticas de rede padrão do Kubernetes operam nas camadas 3 e 4 do modelo de rede OSI e permitem que você controle o fluxo de tráfego no nível de endereço IP ou de porta dentro do cluster do Amazon EKS.

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.

Aplicação baseada em DNS

É comum que os clientes implementem workloads no EKS integradas a ambientes distribuídos maiores, sendo que algumas delas devem estabelecer comunicação com sistemas e serviços externos ao cluster (tráfego em direção ao norte). Esses sistemas e serviços podem estar localizados na Nuvem AWS ou completamente fora do ambiente da AWS. As políticas baseadas em Sistema de Nomes de Domínio (DNS) permitem que você fortaleça a postura de segurança ao adotar uma abordagem mais estável e previsível a fim de evitar o acesso não autorizado de pods a recursos ou a endpoints externos ao cluster. Este mecanismo elimina a necessidade de rastrear e de permitir manualmente endereços IP específicos nas listas de permissões. Ao proteger os recursos com uma abordagem baseada em DNS, você também tem mais flexibilidade para atualizar a infraestrutura externa sem precisar flexibilizar a postura de segurança ou modificar as políticas de rede devido a mudanças nas versões originais de servidores e hosts. É possível filtrar o tráfego de saída para endpoints externos utilizando um Nome de Domínio Totalmente Qualificado (FQDN, na sigla em inglês) ou um padrão de correspondência de nome de domínio do DNS. Isso proporciona ainda mais flexibilidade ao ampliar o acesso para diversos subdomínios vinculados a um endpoint específico externo ao cluster.

Casos de uso

  • Adote o padrão de abordagem baseada em DNS para filtrar o acesso de um ambiente do Kubernetes a endpoints externos ao cluster.

  • Garanta a segurança do acesso aos serviços da AWS em ambientes com múltiplos locatários.

  • Gerencie o acesso da rede de pods a workloads on-premises em seus ambientes de nuvem híbrida.

Regras administrativas (ou com abrangência de cluster)

Em alguns casos, como em cenários multilocatários, os clientes podem ter o requisito de aplicar um padrão de segurança de rede que seja válido em 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. Esses tipos de políticas permitem que você amplie o escopo de aplicação para as regras de filtragem de rede aplicadas nas camadas 3 e 4 ou por meio de regras de DNS.

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.

Introdução

Pré-requisitos

  • Um cluster do Amazon EKS com o Modo Automático do EKS habilitado

  • kubectl configurado para se conectar ao cluster

Etapa 1: habilitar o Network Policy Controller

Para usar políticas de rede com o Modo Automático do EKS, primeiro você precisa habilitar o Network Policy Controller aplicando um ConfigMap ao cluster.

  1. Crie um arquivo chamado enable-network-policy.yaml com o seguinte conteúdo:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

  2. Aplicar o ConfigMap ao cluster:

    kubectl apply -f enable-network-policy.yaml

Etapa 2: habilitar políticas de rede na classe de nó

Antes de usar políticas de rede, você precisa garantir que sua classe de nó esteja configurada para que seja compatível com elas. Siga estas etapas:

  1. Crie ou edite um arquivo YAML da classe de nó (por exemplo, nodeclass-network-policy.yaml) com o seguinte conteúdo:

    apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-enabled
spec:
  # Enables network policy support
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

  2. Aplique a configuração da classe de nó ao cluster:

    kubectl apply -f nodeclass-network-policy.yaml

  3. Verifique se a classe de nó foi criada:

    kubectl get nodeclass network-policy-enabled

  4. Atualize o grupo de nós para usar essa classe de nó. Para obter mais informações, consulte Criar um grupo de nós para o Modo Automático do EKS.

Depois que os nós estiverem usando essa classe de nó, eles poderão aplicar políticas de rede. Agora você pode prosseguir para criar e aplicar políticas de rede para controlar o tráfego no cluster. Para todas as opções de configuração da classe de nó, consulte Criar uma classe de nó para o Amazon EKS.

Etapa 3: criar e testar políticas de rede

O cluster do Modo Automático do EKS agora está configurado para ser compatível com as políticas de rede do Kubernetes. Você pode testar isso com Demonstração Stars da política de redes do Amazon EKS.

Como funciona?

Política de rede baseada em DNS

Ilustração do fluxo de trabalho quando uma política baseada em DNS é aplicada no modo automático do EKS
Ilustração do fluxo de trabalho quando uma política baseada em DNS é aplicada no modo automático do EKS

  1. A equipe responsável pela plataforma aplica uma política baseada em DNS ao cluster do EKS.

  2. O Network Policy Controller é responsável por monitorar a criação de políticas no cluster e, em seguida, reconciliar os endpoints das políticas. Neste caso de uso, o Network Policy Controller orienta o agente do nó a realizar a filtragem das solicitações de DNS, seguindo a lista de domínios autorizados na política correspondente. Os nomes de domínio são incluídos na lista de permissões usando o FQDN ou um nome de domínio que corresponda a um padrão definido na configuração de recursos do Kubernetes.

  3. A Workload A faz uma tentativa de resolução de IP para um endpoint externo ao cluster. A solicitação de DNS é enviada primeiro a um proxy, que realiza a filtragem das solicitações com base na lista de permissões aplicada por meio da política de rede.

  4. Uma vez que a solicitação de DNS é aprovada pela lista de permissões do filtro, ela é encaminhada ao CoreDNS.

  5. O CoreDNS, por sua vez, envia a solicitação ao resolvedor de DNS externo (Amazon Route 53 Resolver) para obter a lista de endereços IP associados ao nome de domínio.

  6. Os endereços IP resolvidos, juntamente com o TTL, são enviados de volta como resposta à solicitação de DNS. Em seguida, esses IPs são gravados em um mapa eBPF, que é utilizado na etapa seguinte para a aplicação da política na camada de IP.

  7. As sondas eBPF anexadas à interface Veth do pod filtrarão o tráfego de saída da Workload A para o endpoint externo ao cluster, com base nas regras em vigor. Isso garante que os pods possam enviar tráfego externo ao cluster apenas para os IPs dos domínios incluídos na lista de permissões. O tempo de validade desses endereços IP baseia-se no TTL retornado pelo resolvedor de DNS externo (Amazon Route 53 Resolver).

Uso da Application Network Policy

A ApplicationNetworkPolicy combina as funcionalidades das políticas de rede padrão do Kubernetes com a filtragem baseada em DNS no nível do namespace, utilizando uma única definição de recurso personalizado (CRD, na sigla em inglês). Portanto, a ApplicationNetworkPolicy pode ser usada para:

  1. Definir restrições nas camadas 3 e 4 da pilha de rede usando blocos de IP e números de porta.

  2. Definir regras que operam na camada 7 da pilha de rede e permitem filtrar o tráfego com base em FQDNs.

Observação importante: as regras baseadas em DNS, definidas por meio da ApplicationNetworkPolicy, são aplicáveis somente a workloads executadas em instâncias do EC2 iniciadas pelo modo automático do EKS.

Exemplo

Você tem uma workload em seu cluster no modo automático do EKS que precisa se comunicar com uma aplicação on-premise, a qual usa um balanceador de carga com um nome de DNS. É possível implementar essa configuração usando a seguinte política de rede:

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

No nível de rede do Kubernetes, isso permitiria a saída de quaisquer pods no namespace “galaxy” rotulados com role: backend para se conectarem ao nome de domínio myapp.mydomain.com na porta TCP 8080. Além disso, seria necessário estabelecer a conectividade de rede para que o tráfego seja enviado da VPC em direção ao data center corporativo.

Ilustração de uma workload no modo automático do EKS se comunicando com aplicações on-premises

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

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

Uso da Cluster Network Policy

Quando se usa uma ClusterNetworkPolicy, as políticas da camada Administrador têm prioridade na avaliação e não podem ser sobrescritas. Após a avaliação das políticas do nível de Administrador, as políticas padrão com escopo de namespace são utilizadas para executar as regras de segmentação de rede aplicadas. Você pode fazer isso usando a ApplicationNetworkPolicy ou NetworkPolicy. Por fim, as regras do nível Linha de Base, que definem as restrições de rede padrão para as workloads do cluster, serão aplicadas. Essas regras do nível de Linha de Base podem ser substituídas pelas políticas com escopo de namespace, se necessário.

Exemplo

Imagine que você tem uma aplicação no cluster e deseja isolá-la das workloads pertencentes a outros locatários. É possível bloquear explicitamente o tráfego do cluster proveniente de outros namespaces para impedir o acesso de rede ao 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

Considerações

Compreensão da ordem de avaliação das políticas

As funcionalidades da política de rede disponíveis no EKS seguem uma ordem de avaliação específica, garantindo que o gerenciamento do tráfego seja sempre seguro e previsível. Dessa forma, compreender o fluxo de avaliação é essencial para projetar uma estratégia de segurança de rede eficiente em seu ambiente.

  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 ApplicationNetworkPolicy com escopo de namespace e as NetworkPolicy tradicionais 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.

Aplicação do princípio de privilégio mínimo

  • Comece com políticas restritivas e adicione permissões gradualmente conforme necessário: inicie implementando políticas de negação por padrão no nível do cluster e, em seguida, adicione regras de permissão incrementalmente à medida que validar os requisitos legítimos de conectividade. Essa abordagem obriga as equipes a justificarem explicitamente cada conexão externa, criando um ambiente mais seguro e auditável.

  • Audite regularmente e remova regras de política não utilizadas: as políticas de rede podem se acumular com o tempo à medida que as aplicações evoluem, deixando para trás regras obsoletas que expandem desnecessariamente a superfície de ataque. Implemente um processo de análise regular para identificar e remover regras de política que não são mais necessárias, garantindo que sua postura de segurança permaneça rígida e sustentável.

  • Use nomes de domínio específicos em vez de padrões abrangentes sempre que possível: embora padrões com caracteres curinga, como *.amazonaws.com, ofereçam conveniência, eles também concedem acesso a uma ampla variedade de serviços. Sempre que viável, especifique nomes de domínio exatos, como s3.us-west-2.amazonaws.com, para limitar o acesso apenas aos serviços específicos que suas aplicações exigem, reduzindo o risco de movimentação lateral caso uma workload seja comprometida.

Uso de políticas baseadas em DNS no EKS

  • As regras baseadas em DNS, definidas por meio da ApplicationNetworkPolicy, são aplicáveis somente a workloads executadas em instâncias do EC2 iniciadas pelo modo automático do EKS. Se você estiver operando um cluster em modo misto (composto por nós de processamento do modo automático do EKS e sem ser nós do modo automático do EKS), as regras baseadas em DNS serão eficazes apenas nos nós de processamento do modo do EKS (instâncias gerenciadas do EC2).

Validação das políticas de DNS

  • Use clusters de preparação que espelhem a topologia de rede da produção para testes: o ambiente de preparação deve replicar a arquitetura de rede, as dependências externas e os padrões de conectividade da produção para garantir testes de política precisos. Isso inclui configurações de VPC compatíveis, comportamento de resolução de DNS e acesso aos mesmos serviços externos que as workloads de produção exigem.

  • Implemente testes automatizados para caminhos de rede críticos: desenvolva testes automatizados que validem a conectividade com serviços externos essenciais como parte do pipeline de CI/CD. Esses testes devem verificar se os fluxos de tráfego legítimos são permitidos enquanto as conexões não autorizadas são bloqueadas, fornecendo validação contínua de que as políticas de rede mantêm a postura de segurança correta à medida que sua infraestrutura evolui.

  • Monitore o comportamento da aplicação após alterações de política: após implantar políticas de rede novas ou modificadas em ambientes de produção, monitore minuciosamente os logs da aplicação, as taxas de erro e as métricas de performance para identificar rapidamente quaisquer problemas de conectividade. Estabeleça procedimentos claros de reversão para que você possa reverter rapidamente as alterações de política caso elas causem comportamento inesperado da aplicação ou interrupções de serviço.

Interação com o firewall de DNS do Amazon Route 53

A avaliação das políticas de Administrador e de rede do EKS ocorre primeiro no nível do pod, assim que o tráfego é gerado. Se uma política de rede do EKS permitir a saída para um domínio específico, o pod realiza então uma consulta ao DNS que é encaminhada ao Route 53 Resolver. Nesse ponto, as regras do firewall de DNS do Route 53 são avaliadas. Se o firewall de DNS bloquear a consulta do domínio, a resolução de DNS falha e a conexão não pode ser estabelecida, mesmo que a política de rede do EKS a tenha permitido. Isso cria camadas de segurança complementares. As políticas de rede baseadas em DNS do EKS fornecem controle de saída em nível de pod para requisitos de acesso específicos da aplicação e limites de segurança multilocatários, enquanto o firewall de DNS oferece proteção em toda a VPC contra domínios mal-intencionados conhecidos e aplica listas de bloqueio em toda a organização.