Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Segurança de rede

    Central de documentação

    Container Service for Kubernetes:Segurança de rede

    Última atualização: Jun 27, 2026

    Restrinja o tráfego de pods com políticas de rede e criptografe dados em trânsito para proteger clusters ACK.

    Políticas de rede versus grupos de segurança

    Políticas de rede e grupos de segurança operam em níveis diferentes. Use ambos em conjunto para garantir defesa em profundidade.

    Mecanismo

    Escopo

    Mais indicado para

    Políticas de rede

    Tráfego pod a pod (tráfego leste-oeste) e comunicação entre pods e serviços externos

    Restringir a comunicação entre microsserviços, namespaces ou pods específicos

    Grupos de segurança

    Tráfego no nível do nó e da Virtual Private Cloud (VPC) entre nós, outros recursos da VPC e endereços IP externos

    Controlar o acesso de entrada e saída do cluster na camada de infraestrutura

    Use grupos de segurança para restringir o acesso no nível da infraestrutura e políticas de rede para impor isolamento granular no nível dos pods dentro do cluster.

    Restrinja o tráfego pod a pod com políticas de rede

    Por padrão, todos os pods em um cluster Kubernetes podem se comunicar livremente, o que gera riscos de segurança. As políticas de rede restringem o tráfego entre pods (tráfego leste-oeste) e entre pods e serviços externos.

    Essas políticas usam seletores de pod e rótulos para identificar os pods de source e destino. Cada política pode filtrar por endereço IP, porta, protocolo ou qualquer combinação desses elementos.

    Com o plug-in de rede Terway, use políticas de rede para controlar o tráfego no nível de endereço IP ou porta. Consulte também Kubernetes Network Policy Recipes.

    Importante

    Apenas clusters Terway suportam políticas de rede do Kubernetes. Em clusters com mais de 100 nós, o proxy de políticas pode aumentar a carga no plano de controle. Consulte Melhorar o desempenho do recurso NetworkPolicy para um cluster ACK grande no modo Terway.

    Abordagem recomendada: negar por padrão e permitir depois

    Aplique o princípio do menor privilégio: bloqueie todo o tráfego por padrão e adicione regras para permitir apenas o que cada carga de trabalho necessita.

    1. Crie uma política de negação padrão -- Bloqueie todo o tráfego de entrada e saída no namespace.

    2. Permita consultas DNS -- Os pods precisam de resolução dns para funcionar.

    3. Libere tráfego específico -- Abra apenas os caminhos exigidos por cada carga de trabalho.

    Etapa 1: Crie uma política de negação padrão

    Crie uma política de rede para negar todo o tráfego de entrada e saída em um namespace ou use o Calico para aplicar uma política global.

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

    Etapa 2: Permita consultas DNS

    Com uma política de negação padrão ativa, os pods não conseguem resolver nomes DNS. Crie uma política para permitir consultas dns ao CoreDNS.

    1. Adicione um rótulo ao namespace kube-system:

         kubectl label namespace kube-system name=kube-system

    2. Crie uma política de rede para permitir o tráfego de saída (egress) para o CoreDNS na porta UDP 53:

         apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-dns-access
     namespace: default
   spec:
     podSelector:
       matchLabels: {}
     policyTypes:
     - Egress
     egress:
     - to:
       - namespaceSelector:
           matchLabels:
             name: kube-system
       ports:
       - protocol: UDP
         port: 53
    Importante

    Consulte Network Policies.

    Etapa 3: Permita tráfego de pods específicos

    Com as políticas de negação e dns configuradas, libere o tráfego apenas de pods autorizados. Casos de uso comuns incluem:

    • Permitir que apenas microsserviços específicos acessem uma aplicação.

    • Restringir o acesso a um banco de dados para aplicações específicas.

    Este exemplo cria um pod e restringe o tráfego de entrada (ingress) aos pods com o rótulo app: bookstore.

    1. Crie um pod com os rótulos app=bookstore e role=api:

         kubectl run apiserver --image=nginx --labels="app=bookstore,role=api" --expose --port=80

    2. Aplique uma política de rede que permita entrada apenas de pods com o rótulo app: bookstore:

         kind: NetworkPolicy
   apiVersion: networking.k8s.io/v1
   metadata:
     name: api-allow
   spec:
     podSelector:
       matchLabels:
         app: bookstore
         role: api
     ingress:
     - from:
         - podSelector:
             matchLabels:
               app: bookstore

    3. Verifique se os pods sem o rótulo app=bookstore têm o acesso negado:

         kubectl run test-$RANDOM --rm -i -t --image=alpine -- sh
         / # wget -qO- --timeout=2 http://apiserver
   wget: download timed out

    4. Confirme que os pods com o rótulo app=bookstore conseguem acessar o servidor:

         kubectl run test-$RANDOM --rm -i -t --image=alpine --labels="app=bookstore,role=frontend" -- sh
         / # wget -qO- --timeout=2 http://apiserver
   <!DOCTYPE html>
   <html><head>

    Adicione regras personalizadas entre pods em um namespace

    Após permitir a comunicação entre pods dentro de um namespace, use o repositório Kubernetes Network Policy Recipes para adicionar regras personalizadas e obter um controle mais granular.

    Controle o tráfego no nível do nó com grupos de segurança

    O ACK usa grupos de segurança para gerenciar o tráfego entre nós mestre e worker, bem como entre nós worker, outros recursos da VPC e endereços IP externos.

    O ACK cria automaticamente um grupo de segurança para a comunicação entre nós durante a criação do cluster. Para aplicar o princípio do menor privilégio, adicione as regras de entrada e saída recomendadas.

    Consulte Configurar grupos de segurança em diferentes cenários e Configurar um grupo de segurança.

    Monitore e analise o tráfego com logs de fluxo

    Os logs de fluxo da VPC registram o tráfego de entrada e saída das interfaces de rede elástica (ENIs). Use esses logs para:

    • Validar regras de lista de controle de acesso (ACL)

    • Monitorar o tráfego de rede

    • Solucionar problemas de conectividade

    • Identificar tráfego anômalo entre recursos (incluindo pods) em uma VPC

    Consulte Visão geral dos logs de fluxo.

    Criptografe dados em trânsito

    • Service Mesh (ASM)

      O Service Mesh (ASM) criptografa dados trocados entre serviços. O ASM oferece suporte a:

      • Autenticação Mutual Transport Layer Security (mTLS) entre serviços

      • Envoy Secret Discovery Service (SDS) para HTTPS e carregamento dinâmico de certificados em gateways de serviço

      • Gerenciamento de tráfego para aplicações em instâncias do ASM, integrado ao Application High Availability Service (AHAS)

      • Rastreamento distribuído integrado ao Tracing Analysis para mapeamento de traces, contagem de chamadas, topologia e análise de dependências

    • TLS for Ingress

      Ative HTTPS para serviços expostos via Ingress. Use um Secret para configurar TLS.