Configurar políticas de rede do cluster

A ClusterNetworkPolicy permite definir posturas de segurança globais do GKE em todo o cluster. Este documento é destinado a administradores de cluster que precisam aplicar medidas de segurança obrigatórias ou estabelecer valores de referência de confiança zero.

Esse recurso depende de uma hierarquia de avaliação rigorosa que opera com uma precedência maior do que os recursos NetworkPolicy padrão com escopo de namespace. É possível usar o recurso ClusterNetworkPolicy para implementar ações explícitas Negar, Aceitar, ou Passar. Essas ações permitem configurar políticas globais de permissão ou negação, delegar o controle de tráfego a namespaces específicos e restringir o tráfego de saída a blocos CIDR.

Antes de começar

Antes de configurar uma política de rede de cluster, verifique se você atende aos seguintes requisitos:

  1. Verifique se o cluster do GKE executa a versão 1.36.0-gke.4447000 ou mais recente.
  2. Verifique se o cluster usa o GKE Dataplane V2.

Portas e protocolos compatíveis

As regras da ClusterNetworkPolicy podem corresponder ao tráfego com base nos protocolos TCP, UDP ou SCTP. É possível especificar portas de destino das seguintes maneiras:

  • Número de porta específico: use a configuração destinationPort.number para segmentar uma única porta (por exemplo, 80).
  • Intervalo de portas: use a configuração destinationPort.range para segmentar um intervalo de portas (por exemplo, 8000 a 9000).
  • Porta nomeada: use a configuração destinationNamedPort para segmentar um nome simbólico definido em uma especificação de pod.

Hierarquia de avaliação de políticas

Ao contrário das NetworkPolicies padrão e aditivas, uma ClusterNetworkPolicy (CNP) depende de uma hierarquia de avaliação rigorosa em que a primeira regra correspondente vence. O tráfego flui sequencialmente por um pipeline de três camadas:

  • O nível: as regras de administrador são executadas primeiro, em cascata para NetworkPolicy, e, em seguida, para a linha de base.
  • Prioridade da CNP: em um nível, as políticas são avaliadas com base na prioridade numérica explícita.
  • Ordem das regras da CNP: em uma única política, as regras são processadas de cima para baixo, como uma lista de controle de acesso (ACL).

Diagrama mostrando a hierarquia de avaliação da política de rede do GKE

O diagrama anterior ilustra o fluxo de decisão da hierarquia de avaliação da CNP:

  1. Nível de administrador: o tráfego é avaliado primeiro em relação às regras ClusterNetworkPolicy no nível Admin. Se houver uma correspondência de permissão ou negação, a avaliação será interrompida. Se não houver correspondência ou uma ação de aprovação, o tráfego vai para o nível NetworkPolicy.
  2. Nível de NetworkPolicy: o tráfego é avaliado em relação às políticas de namespace padrão. Se houver uma correspondência, o tráfego será permitido. Se não houver correspondência, o tráfego vai para o nível de linha de base.
  3. Nível de linha de base: o tráfego é avaliado em relação às ClusterNetworkPolicy regras no nível de linha de base. Se houver uma correspondência de permissão ou negação, a avaliação será interrompida. Se não houver correspondência, o tráfego vai para o comportamento padrão.
  4. Comportamento padrão do GKE: se nenhuma política corresponder em qualquer nível, o tráfego será sujeito a um comportamento de permissão implícito.

Ações de veredito: permitir, negar e passar

Ao corresponder a um pacote, cada regra aciona uma das três ações rigorosas:

  • Negar: bloqueia imediatamente o tráfego.
  • Aceitar: permite o tráfego. Ambas as ações interrompem instantaneamente o pipeline, que ignora todas as políticas restantes.
  • Passar: transfere o controle para o próximo nível, permitindo que os engenheiros da plataforma deleguem decisões de tráfego específicas a políticas padrão de nível de namespace sem abrir mão do controle administrativo geral.

Configurar uma política global de negação

Para isolar um namespace sensível de todo o tráfego interno do cluster, aplique uma regra de negação não substituível. Essa política de negação padrão ajuda a garantir que qualquer tráfego de ou para o namespace sensível seja bloqueado no nível administrativo. Essa política atua como uma linha de base de proteção que não pode ser ignorada acidentalmente por regras de nível de namespace.

  1. Salve o seguinte manifesto como global-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: cluster-wide-deny-sensitive
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: sensitive-ns
  ingress:
  - action: Deny
    name: deny-all-ingress
    from:
    - namespaces:
        matchLabels: {}
  egress:
  - action: Deny
    name: deny-all-egress
    to:
    - namespaces:
        matchLabels: {}

  2. Aplique o manifesto ao cluster:

    kubectl apply -f global-deny.yaml

Configurar uma política global de permissão

Uma política global de permissão pode ajudar a garantir que todos os pods possam acessar o serviço de DNS do cluster, independentemente de políticas de rede criadas pelo desenvolvedor.

  1. Salve o seguinte manifesto como global-allow-dns.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-kube-dns-admin
spec:
  tier: Admin
  priority: 20
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-dns-egress
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    protocols:
    - udp:
        destinationPort:
          number: 53
    - tcp:
        destinationPort:
          number: 53

  2. Aplique o manifesto ao cluster:

    kubectl apply -f global-allow-dns.yaml

Delegar tráfego a políticas de namespace

Delegue padrões de tráfego específicos a objetos NetworkPolicy padrão com escopo de namespace.

  1. Salve o seguinte manifesto como delegate-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: delegate-to-netpol
spec:
  tier: Admin
  priority: 30
  subject:
    namespaces: {}
  egress:
  - action: Pass
    name: delegate-web-traffic
    to:
    - namespaces:
        matchLabels:
          app: web-backend
    protocols:
    - tcp:
        destinationPort:
          number: 8080

  2. Aplique o manifesto ao cluster:

    kubectl apply -f delegate-policy.yaml

  3. Para permitir o tráfego delegado no namespace de destino, salve o seguinte manifesto NetworkPolicy padrão como allow-web-backend.yaml :

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-backend
  namespace: backend-ns
spec:
  podSelector:
    matchLabels:
      app: web-backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: web-frontend
    ports:
    - protocol: TCP
      port: 8080

  4. Aplique o manifesto NetworkPolicy padrão ao cluster:

    kubectl apply -f allow-web-backend.yaml

Configurar medidas de segurança de linha de base

Estabeleça uma postura de segurança padrão do GKE que os administradores de namespace possam substituir usando políticas de rede padrão.

  1. Salve o seguinte manifesto de linha de base como baseline-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: default-deny-baseline
spec:
  tier: Baseline
  priority: 100
  subject:
    namespaces: {}
  ingress:
  - action: Deny
    name: baseline-deny-all
    from:
    - namespaces: {}

  2. Aplique o manifesto de linha de base ao cluster:

    kubectl apply -f baseline-deny.yaml

  3. Salve o seguinte manifesto de substituição do desenvolvedor como developer-allow.yaml:

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-access
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

  4. Aplique o manifesto de substituição ao cluster:

    kubectl apply -f developer-allow.yaml

Configurar políticas usando portas nomeadas

Para abstrair números de porta das políticas de segurança, faça referência a portas nomeadas definidas nas especificações do pod.

  1. Salve o seguinte manifesto de implantação como app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
spec:
  template:
    spec:
      containers:
      - name: web-container
        image: nginx
        ports:
        - name: http-web
          containerPort: 8080

  2. Aplique o manifesto de implantação ao cluster:

    kubectl apply -f app-deployment.yaml

  3. Salve o seguinte manifesto de política como named-port-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-web-named-port
spec:
  tier: Admin
  priority: 40
  subject:
    namespaces: {}
  egress:
  - action: Accept
    to:
    - namespaces:
        matchLabels:
          app: my-webapp
    protocols:
    - tcp:
        destinationNamedPort: http-web

  4. Aplique o manifesto de política ao cluster:

    kubectl apply -f named-port-policy.yaml

Restringir a saída a blocos CIDR

Controle o acesso a recursos externos ou intranets corporativas especificando blocos CIDR.

  1. Salve o seguinte manifesto como cidr-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-egress-to-intranet
spec:
  tier: Admin
  priority: 60
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-intranet
    to:
    - networks:
      - 10.0.0.0/8
      - 192.168.0.0/16

  2. Aplique o manifesto ao cluster:

    kubectl apply -f cidr-policy.yaml

Configurar precedência de prioridade

Para controlar a ordem de avaliação quando várias políticas se aplicam aos mesmos pods, especifique uma prioridade. As prioridades variam de 0 a 1000, em que números mais baixos indicam maior precedência. Um único objeto ClusterNetworkPolicy pode conter um máximo de 100 regras de entrada e 100 regras de saída.

  1. Salve o seguinte manifesto como priority-policies.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-beta
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-beta-monitoring
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            team: beta
        podSelector:
          matchLabels:
            app: monitoring
  - action: Deny
    name: deny-all-other-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta
---
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-beta
spec:
  tier: Admin
  priority: 50
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-all-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta

  2. Aplique o manifesto ao cluster:

    kubectl apply -f priority-policies.yaml

Resolver problemas

Para encontrar métodos de diagnóstico e resolução de erros de política, use os comandos a seguir.

Liste todas as políticas de rede de cluster no cluster:

kubectl get clusternetworkpolicies

Descreva uma política específica para inspecionar o status e o nível de avaliação:

kubectl describe clusternetworkpolicy/<policy-name>

O campo status.conditions na saída fornece informações sobre se a política foi reconciliada com sucesso pela implementação de rede do cluster.

Para monitorar fluxos de tráfego e decisões de política, use a observabilidade do GKE Dataplane V2.

A seguir