Práticas recomendadas para políticas de rede no AKS (Serviço de Kubernetes do Azure)

O Kubernetes, por padrão, opera como uma rede simples em que todos os pods podem se comunicar livremente entre si. Essa conectividade irrestrita pode ser conveniente para os desenvolvedores, mas representa riscos de segurança significativos à medida que os aplicativos são dimensionados. Imagine uma organização implantando vários microsserviços, cada um tratando dados confidenciais, transações de clientes ou operações de back-end. Sem restrições, qualquer pod comprometido poderia potencialmente acessar dados não autorizados ou interromper serviços.

Para resolver essas preocupações de segurança, as Políticas de Rede no Kubernetes permitem que os administradores controlem e restrinjam o tráfego entre cargas de trabalho. Eles fornecem uma maneira declarativa de impor regras de tráfego, garantindo um comportamento de rede seguro e controlado em um cluster.

O que é a Política de Rede do Kubernetes?

Uma Política de Rede no Kubernetes é um conjunto de regras que controlam como os pods se comunicam entre si e com serviços externos. Ele fornece controle refinado sobre o tráfego de rede, permitindo que os administradores imponham a segurança e a segmentação no nível do namespace. Implementando políticas de rede, você obtém:

• Postura de segurança mais forte: impedir a movimentação lateral não autorizada dentro do cluster.
• Conformidade e governança: imponha requisitos regulatórios controlando caminhos de comunicação.
• Raio de explosão reduzido: limite o impacto de uma carga de trabalho comprometida restringindo seu acesso à rede.

Inicialmente, as Políticas de Rede foram projetadas para operar na Camada 3 (IP) e na Camada 4 (TCP/UDP) do modelo OSI, permitindo o controle básico sobre comunicações entre pods e comunicações externas. No entanto, mecanismos avançados de política de rede, como o Cilium, estenderam as Políticas de Rede para a Camada 7 (Camada de Aplicativo), permitindo um controle mais profundo sobre o tráfego de aplicativos para aplicativos nativos de nuvem modernos.

As políticas de rede são definidas no nível do namespace, o que significa que cada política se aplica a cargas de trabalho em um namespace específico. Os principais componentes de uma Política de Rede incluem:

• Seletor de pod: define a quais pods a política se aplica com base em rótulos.
• Regras de entrada: especifique as conexões de entrada permitidas.
• Regras de saída: especifique as conexões de saída permitidas.
• Tipos de política: defina se a política se aplica à entrada (entrada), saída (saída) ou ambos.

Fundamentos da criação de políticas de rede eficazes

Criar políticas de rede eficazes no Kubernetes não se trata apenas de escrever configurações do YAML, mas de uma compreensão profunda da arquitetura do aplicativo, dos padrões de tráfego e dos requisitos de segurança. Sem uma visão clara de como as cargas de trabalho se comunicam, a imposição de políticas de segurança pode levar a interrupções ou lacunas não intencionais na proteção. As seções a seguir abordam como abordar sistematicamente o design de política de rede.

Noções básicas sobre a conectividade de carga de trabalho

Antes de implementar políticas de rede, você precisa ter visibilidade de como as cargas de trabalho se comunicam entre si e com os serviços externos. Esta etapa garante que as políticas não bloqueiem inadvertidamente o tráfego crítico, limitando efetivamente a exposição desnecessária.

• Aproveite as Ferramentas de Visibilidade: além dos requisitos de rede fornecidos pela equipe de aplicativos, você pode usar ferramentas como o Cilium Hubble e o Retina ajudam a analisar o tráfego pod a pod, identificar quais serviços precisam se comunicar e definir as dependências de entrada e saída. Por exemplo, um front-end pode precisar acessar uma API de back-end, mas não deve falar diretamente com um banco de dados. Identifique quais serviços precisam se comunicar e definir suas dependências de entrada e saída. Por exemplo, um front-end pode precisar acessar uma API de back-end, mas não deve falar diretamente com um banco de dados.

• A importância dos rótulos nas políticas de rede: Tradicionalmente, as políticas de segurança de rede dependem de endereços IP estáticos para definir regras de tráfego. Essa abordagem é problemática no Kubernetes porque os pods são efêmeros — criados e destruídos com frequência, muitas vezes com endereços IP atribuídos dinamicamente. Manter regras de segurança com base em IPs em constante alteração exigiria atualizações contínuas, tornando o gerenciamento de políticas ineficiente e propenso a erros.

Os rótulos resolvem esse desafio fornecendo uma maneira estável de agrupar cargas de trabalho. Em vez de depender de IPs fixos, as políticas de rede do Kubernetes usam rótulos para definir regras de segurança que permanecem consistentes mesmo quando os pods reiniciam ou mudam entre nós. Por exemplo, uma política pode permitir a comunicação entre pods rotulados app: frontend e app: backend, garantindo fluxos de tráfego conforme pretendido, independentemente das alterações de IP do pod. Essa abordagem baseada em rótulo é essencial para alcançar a segurança de rede escalonável e orientada por intenção em ambientes nativos de nuvem.

Uma estratégia de rotulagem bem definida simplifica o gerenciamento de políticas, reduz configurações incorretas e aprimora a imposição de segurança entre clusters.

• Definir micro segmentação: Organizar cargas de trabalho em zonas de segurança (por exemplo, front-end, back-end, banco de dados) ajuda a impor o princípio do privilégio mínimo. Por exemplo, os microsserviços que lidam com transações de clientes devem ser isolados de aplicativos de uso geral.

Abordagem de segurança em camadas para Kubernetes

Depender apenas de políticas básicas de rede do Kubernetes pode não ser suficiente para todas as necessidades de segurança. Uma abordagem em camadas garante uma proteção abrangente em diferentes níveis de comunicação de rede.

• Políticas (L3/L4): a base da segurança de rede, controlando o tráfego com base em rótulos de pod e namespaces no nível de IP, porta e protocolo.
• Políticas baseadas em FQDN: restrinja o tráfego de saída a domínios externos específicos, garantindo que as cargas de trabalho só possam alcançar serviços externos aprovados (por exemplo: permitindo apenas o acesso a microsoft.com para chamadas à API).
• Políticas de camada 7: introduz um controle refinado sobre o tráfego filtrando solicitações com base em métodos HTTP, cabeçalhos e caminhos. Isso é útil para proteger APIs e impor políticas de segurança de camada de aplicativo.

Gerenciamento de políticas de rede

Quem deve gerenciar políticas de rede? Isso geralmente depende dos requisitos de estrutura e segurança de uma organização. Uma abordagem bem equilibrada permite que as equipes de segurança e os desenvolvedores de aplicativos colaborem com eficiência.

• Administração de segurança centralizada: as equipes de segurança ou de rede devem definir políticas de linha de base para impor requisitos de segurança globais, como regras padrão de negação ou restrições controladas por conformidade.
• Autonomia do desenvolvedor com guardrails: as equipes de aplicativos devem ser capazes de definir políticas de rede específicas do serviço em seus namespaces, habilitando a segurança e mantendo a agilidade.
• Gerenciamento do ciclo de vida da política: revisar e atualizar políticas regularmente garante que a segurança permaneça alinhada com arquiteturas de aplicativos em evolução. As ferramentas de observabilidade podem ajudar a detectar configurações incorretas de política e regras ausentes.

Exemplo: Proteger um aplicativo Web de várias camadas com políticas de rede

Etapa 1: Noções básicas sobre a conectividade de carga de trabalho

• Ferramentas de visibilidade: use o Cilium Hubble para observar como os pods se comunicam.

• Mapeamento da conectividade

  Fonte	Destino	Protocolo	Porto
  Front-end	Back-end	TCP	8080
  Back-end	Base de dados	TCP	5432
  Back-end	Gateway de Pagamento Externo	TCP	443

Etapa 2: Aplicar rótulos para imposição de política

Rotulando as cargas de trabalho corretamente, as políticas podem permanecer estáveis mesmo se os IPs do pod forem alterados.

• app: frontend para pods de interface do usuário.
• app: backend para pods de API.
• app: database para pods de BD.

Etapa 3: Implementando políticas de rede no nível do aplicativo

Neste exemplo, usamos duas camadas de políticas de rede: uma política básica L3/L4 para controlar o tráfego entre microsserviços e uma política de FQDN (nome de domínio totalmente qualificado) para controlar o tráfego de saída com gateway de pagamento externo.

Permitir que o front-end se comunique com o back-end	Permitir que o back-end acesse o banco de dados	Permitir que o back-end alcance a API de pagamento externo
Política 1: Saída de front-end to: - podSelector: matchLabels: app: backend ports: - protocol: TCP port: 8080 Política 2: Entrada de back-end from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080	Política 1: Saída de back-end to: - podSelector: matchLabels: app: database ports: - protocol: TCP port: 5432 Política 2: Entrada de banco de dados from: - podSelector: matchLabels: app: backend ports: - protocol: TCP port: 5432	Política 1: Back-end spec: endpointSelector: matchLabels: app: backend egress: - toFQDNs: - matchName: payments.example.com ports: - protocol: TCP port: 443

Etapa 4: Gerenciamento e manutenção de políticas

• As equipes de segurança e plataforma impõem regras de negação de linha de base.

  Política de linha de base	Política de plataforma	Segurança
  - Negar todo o tráfego por padrão	- Permitir DNS - Permitir logs	- Bloquear o tráfego para IPs e domínios maliciosos conhecidos

• Garantindo que as políticas de rede do aplicativo estejam em conformidade com os requisitos de plataforma e segurança, evitando violações de política.

  Linha de base	Política de plataforma	Política de segurança	Permitir que o front-end se comunique com o back-end	Permitir que o back-end acesse o banco de dados	Permitir que o back-end alcance a API de pagamento externo
  - Negar todo o tráfego por padrão	- Permitir DNS - Permitir logs	- Bloquear o tráfego para IPs e domínios mal-intencionados conhecidos	Política 1: Saída de front-end: - para:   - podSelector:     matchLabels:       aplicativo: back-end     Portas:     - protocolo: TCP       porta: 8080 Política 2: Entrada de back-end: - de:   - podSelector:     matchLabels:       aplicativo: front-end     Portas:     - protocolo: TCP       porta: 8080	Política 1: Saída de back-end: - para:   - podSelector:     matchLabels:       app: banco de dados     Portas:     - protocolo: TCP       porta: 5432 Política 2: Entrada de banco de dados: - de:   - podSelector:     matchLabels:       aplicativo: back-end     Portas:     - protocolo: TCP       porta: 5432	Política 1: Back-end Especificação: endpointSelector:   matchLabels:     aplicativo: back-end saída: - toFQDNs:   - matchName: payments.example.com Portas: - protocolo: TCP   porta: 443

  Essa abordagem estruturada garante a segurança sem interromper a funcionalidade do aplicativo.

Azure Powered by Cilium

A CNI (Interface de Rede de Contêiner do Azure) alimentada pelo Cilium aproveita o eBPF (filtro de pacote de Berkeley estendido) para fornecer rede, observabilidade e segurança de alto desempenho para cargas de trabalho do Kubernetes. Ao contrário das CNIs tradicionais que dependem da filtragem de pacotes baseada em iptables, a CNI do Azure alimentada pelo Cilium usa o eBPF para operar no nível do kernel, permitindo a imposição de política de rede eficiente e escalonável. No AKS (Serviço de Kubernetes do Azure), o Cilium é o único mecanismo de política de rede com suporte, refletindo o investimento do Azure em desempenho, escalabilidade e segurança. O Serviço de Kubernetes do Azure integra o Cilium como um componente gerenciado, simplificando a imposição de segurança de rede. Os administradores podem definir políticas de rede do Cilium diretamente em seus clusters do AKS sem a necessidade de controladores externos.

O Cilium estende o uso de rótulos com identidades. Os clusters grandes com muitos pods podem enfrentar problemas de escala em que a atualização constante de filtros IP ocorre com uma alta rotatividade de pods. Nos bastidores, as identidades são mapeadas para rótulos e permitem que as conexões sejam iniciadas assim que a identidade for resolvida, em vez da necessidade de atualizar as regras em nós.

Com o CNI do Azure alimentado pelo Cilium, você não precisa instalar um mecanismo de política de rede separado, como o Azure Network Policy Manager ou o Calico.

Use o comando a seguir para criar um cluster com o CNI do Azure alimentado por cilium

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium \
  --generate-ssh-keys

Anatomia da política de rede do Cilium

Com o CNI do Azure alimentado pelo Cilium, você pode configurar políticas de rede nativamente no Kubernetes usando dois formatos disponíveis:

• O recurso padrãoNetworkPolicy, que dá suporte a políticas L3 e L4 na entrada ou saída do Pod.
• O formato CiliumNetworkPolicy estendido, que está disponível como CustomResourceDefinition que dá suporte à especificação de políticas nas Camadas 3-7 para entrada e saída.

Com esses CRDs, podemos definir políticas de segurança e o Kubernetes distribui automaticamente essas políticas para todos os nós no cluster.

Uma Política de Rede consiste em vários componentes principais:

• Seletor de pod: especifica quais pods a política se aplica ao uso de rótulos.

• Tipos de política: determina se a política se aplica à entrada (tráfego de entrada), saída (tráfego de saída) ou ambos.

• Regras de entrada: define fontes permitidas (pods, namespaces ou intervalos de IP) e portas.

• Regras de saída: define destinos e portas permitidos.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: frontend-egress
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: frontend
    policyTypes:
      - Egress
    egress:
      - to:
          - podSelector:
              matchLabels:
                app: backend
        ports:
          - protocol: TCP
            port: 8080
  

Política de Rede Avançada

Os serviços de Kubernetes do Azure oferecem ao ACNS (Serviço Avançado de Rede de Contêiner) um conjunto de serviços projetado para aprimorar os recursos de rede de clusters do AKS.

Um dos principais recursos do ACNS é a Segurança de Rede de Contêiner, que oferece funcionalidades avançadas de segurança para proteger cargas de trabalho em contêineres. Um aspecto notável é a capacidade de implementar políticas de rede avançadas, incluindo filtragem de FQDN (Nome de Domínio Totalmente Qualificado) e políticas de L7 (Camada 7), permitindo um controle mais granular sobre o tráfego de saída e a comunicação de camada de aplicativo.

Proteger o tráfego de saída com a filtragem de FQDN

Tradicionalmente, as políticas de rede no Kubernetes são baseadas em endereços IP. No entanto, em ambientes dinâmicos em que os IPs de pod mudam frequentemente, o gerenciamento dessas políticas torna-se complicado. A filtragem de FQDN simplifica isso permitindo que as políticas sejam definidas usando nomes de domínio em vez de endereços IP. Essa abordagem fornece um método mais intuitivo e amigável de controlar o tráfego de rede, permitindo que as organizações imponham políticas de segurança com maior precisão e flexibilidade.

Implementar a filtragem de FQDN em clusters do AKS requer habilitar o ACNS e configurar as políticas necessárias para definir domínios permitidos ou bloqueados, aprimorando assim a postura de segurança de seus aplicativos em contêineres.

Para habilitar o ACNS (Advanced Container Networking Services) no AKS (Serviço de Kubernetes do Azure), use o sinalizador --enable-acns

Exemplo: habilitar serviços avançados de rede de contêiner em um cluster existente

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

Exemplo: criar uma política de rede que permita o tráfego para "bing.com"

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-bing-fqdn"
spec:
  endpointSelector:
    matchLabels:
      app: demo-container
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*.bing.com"
    - toFQDNs:
        - matchPattern: "*.bing.com"

Proteção e segurança para APIs com políticas L7

À medida que os aplicativos modernos dependem cada vez mais de APIs para comunicação, proteger essas interações apenas na camada de rede não é mais suficiente. As políticas de rede padrão operam na Camada 3 (IP) e camada 4 (TCP/UDP), controlando quais pods podem se comunicar, mas não têm visibilidade das solicitações reais de API que estão sendo feitas.

As políticas de camada 7 (L7) fornecem os seguintes benefícios e recursos:

• Segurança da API granular: impor políticas com base em dados de solicitação HTTP, gRPC ou Kafka, em vez de apenas endereços IP e portas.
• Superfície de ataque reduzida: evite o acesso não autorizado e reduza ataques baseados em API filtrando o tráfego na camada do aplicativo.
• Conformidade e auditoria: garanta a adesão aos padrões de segurança registrando e controlando interações específicas da API.
• Gerenciamento de política simplificado: evite a carga operacional de proxies de sidecar adicionais aproveitando controles L7 integrados alimentados por Cilium.

As políticas L7 do AKS são habilitadas por meio do ACNS e estão disponíveis para clientes que usam o CNI do Azure alimentado pelo Cilium. Essas políticas dão suporte a protocolos HTTP, gRPC e Kafka.

Para impor políticas L7, os clientes definem recursos CiliumNetworkPolicy, especificando regras para o controle de tráfego de camada de aplicativo.

Exemplo: habilitar o ACNS em um cluster existente

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

Exemplo: permitir apenas solicitações GET para /api do pod de front-end para o serviço de back-end na porta 8080

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Estratégias para políticas de rede

Proteger cargas de trabalho do Kubernetes requer uma abordagem pensada para definir e impor políticas de rede. Uma estratégia bem projetada garante que os aplicativos se comuniquem apenas conforme pretendido, reduzindo o risco de acesso não autorizado, movimentação lateral e possíveis violações. As seções a seguir abordam as principais estratégias para implementar políticas de rede do Kubernetes eficazes.

Adotar um modelo de Confiança Zero

Por padrão, o Kubernetes permite a comunicação irrestrita entre todos os pods em um cluster. Uma abordagem Zero-Trust determina que nenhum tráfego deve ser confiável por padrão e apenas caminhos de comunicação explicitamente permitidos devem ser permitidos. A implementação de uma política de rede que nega tudo por padrão garante que apenas o tráfego necessário flua entre as cargas de trabalho.

Exemplo de uma política de negação:

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

Segmentação de namespace e multilocação

Em ambientes multilocatários, os namespaces ajudam a isolar cargas de trabalho. Equipes diferentes normalmente gerenciam seus aplicativos em namespaces dedicados, garantindo o isolamento lógico entre cargas de trabalho. Essa separação é crítica quando vários aplicativos são executados entre si. A aplicação de políticas de rede no escopo do namespace geralmente é a primeira etapa na proteção de cargas de trabalho, pois impede a movimentação lateral irrestrita entre aplicativos gerenciados por equipes diferentes.

Por exemplo, restrinja todo o tráfego de entrada a um namespace, permitindo apenas o tráfego do mesmo namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: team-a

Microssegmentação para isolamento da carga de trabalho

Embora a segmentação baseada em namespace seja uma primeira etapa essencial para proteger clusters kubernetes multilocatários, a microssegmentação no nível do aplicativo fornece controle refinado sobre como as cargas de trabalho interagem dentro de um namespace. O isolamento de namespace por si só não impede a comunicação não intencional ou não autorizada entre aplicativos diferentes no mesmo namespace. É aí que a segmentação no nível do pod se torna crítica.

Por exemplo, se um serviço de front-end só deve se comunicar com um serviço de back-end no mesmo namespace, uma política usando rótulos de pod poderá impor essa restrição:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: team-a
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080

Isso impede que os pods de front-end façam conexões não intencionais com outros serviços, reduzindo o risco de acesso não autorizado ou movimentação lateral dentro do namespace.

Combinando o isolamento em todo o namespace com políticas de nível de aplicativo refinadas, as equipes podem implementar um modelo de segurança de várias camadas que impede o tráfego não autorizado, permitindo a comunicação necessária para a funcionalidade do aplicativo.

Abordagem de segurança em camadas

A segurança de rede deve ser implementada em camadas, combinando vários níveis de imposição:

• Políticas L3/L4: restringir o tráfego no nível do IP e da porta (por exemplo: permitir o tráfego TCP na porta 443).
• Filtragem baseada em FQDN: restrinja a comunicação externa com base em nomes de domínio em vez de endereços IP.
• Políticas L7: controlar a comunicação com base em atributos de camada de aplicativo (por exemplo: permitir apenas solicitações HTTP GET para caminhos de API específicos).

Por exemplo, uma política Cilium L7 pode restringir os serviços de front-end para emitir apenas solicitações GET para a API de back-end:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Isso impede que o front-end faça solicitações POST ou DELETE, limitando a superfície de ataque.

Integrando o RBAC ao gerenciamento de Política de Rede

O RBAC (controle de acesso baseado em função) desempenha um papel crucial para garantir que somente usuários autorizados ou equipes possam criar, modificar ou excluir políticas de rede. Sem controles de acesso adequados, uma política configurada incorretamente poderia expor cargas de trabalho a acesso não autorizado ou bloquear acidentalmente o tráfego crítico do aplicativo.

Aproveitando o RBAC do Kubernetes em conjunto com políticas de rede, as organizações podem impor a separação de tarefas entre administradores de plataforma, equipes de segurança e desenvolvedores de aplicativos. Uma abordagem típica é:

• As equipes de plataforma ou segurança definem políticas de segurança de linha de base que impõem a conformidade e restringem o acesso externo.
• As equipes de aplicativos recebem permissões limitadas para criar ou atualizar políticas de rede apenas para seus respectivos namespaces.

Por exemplo, a política rbac a seguir permite que os desenvolvedores criem e modifiquem políticas de rede, mas somente dentro de seu namespace atribuído:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: network-policy-editor
  namespace: team-a
rules:
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "create", "update", "delete"]

Em seguida, essa função pode ser associada a uma equipe específica usando um RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-network-policy-binding
  namespace: team-a
subjects:
  - kind: User
    name: developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: network-policy-editor
  apiGroup: rbac.authorization.k8s.io

Ao restringir as modificações de política de rede a equipes e namespaces designados, as organizações podem evitar configurações incorretas acidentais ou alterações não autorizadas, ao mesmo tempo em que permitem flexibilidade para os desenvolvedores implementarem políticas de segurança específicas do aplicativo.

Essa abordagem reforça o princípio do privilégio mínimo, garantindo que as estratégias de segmentação de rede permaneçam consistentes, seguras e alinhadas com as políticas organizacionais.

Soluções herdadas e de terceiros

NPM (Gerenciador de Política de Rede do Azure)

O NPM (Azure Network Policy Manager) é uma solução herdada para impor políticas de rede do Kubernetes no AKS. À medida que continuamos a evoluir nossa pilha de rede, pretendemos preterir o npm em breve.

É altamente recomendável que todos os clientes passem para a Política de Rede do Cilium, que fornece melhor desempenho, escalabilidade e segurança aprimorada por meio da imposição baseada em eBPF. O Cilium é o futuro da política de rede no AKS e oferece uma alternativa mais flexível e rica em recursos para o NPM.

Suporte do NetworkPolicy para nós do Windows

O AKS não dá suporte nativo a NetworkPolicy do Kubernetes para nós do Windows prontos para uso. Para habilitar políticas de rede para cargas de trabalho do Windows, você pode usar o Calico para nós do Windows, que é integrado ao AKS para simplificar a implantação. Você pode habilitá-lo usando o --network-policy calico sinalizador ao criar um cluster.

A Microsoft não mantém as imagens do Calico usadas nessa integração. Nosso suporte é limitado a garantir que o Calico esteja devidamente integrado ao AKS e às funções conforme o esperado na plataforma. Todos os problemas relacionados a bugs upstream do Calico, solicitações de recursos ou solução de problemas além da integração do AKS devem ser direcionados para a comunidade de código aberto do Calico ou do Tigera, os mantenedores do Calico.

Software livre do Calico – solução de terceiros

O software livre calico é uma solução de terceiros amplamente usada para impor políticas de rede do Kubernetes. Ele dá suporte a nós do Linux e do Windows e fornece recursos avançados de rede e segurança, incluindo imposição de política de rede, identidade de carga de trabalho e criptografia.

Embora o Calico esteja integrado às políticas de rede do AKS para Windows (--network-policy calico), ele continua sendo um projeto de software livre mantido pelo Tigera. A Microsoft não mantém imagens Calico e fornece suporte limitado, focado em garantir a integração adequada com o AKS. Para solução de problemas avançada, solicitações de recursos ou problemas além da integração do AKS, recomendamos entrar em contato com a comunidade de software livre do Calico ou o Tigera.

Para nós do Linux, é altamente recomendável usar o Cilium para a imposição da política de rede. Para nós do Windows, é recomendável usar o Calico.

Conclusão

As políticas de rede são uma parte fundamental da segurança do Kubernetes, permitindo que as organizações controlem o fluxo de tráfego, imponham o isolamento da carga de trabalho e reduzam a superfície de ataque. À medida que os ambientes nativos de nuvem evoluem, depender apenas das políticas básicas da Camada 3/4 não é mais suficiente. Soluções avançadas, como filtragem de Camada 7 e políticas baseadas em FQDN, fornecem a segurança granular e a flexibilidade necessárias para proteger aplicativos modernos.

Seguindo as práticas recomendadas, incluindo o modelo de confiança zero, a microssegmentação e a adoção de soluções escalonáveis, como as equipes do Cilium gerenciado do Azure, podem aprimorar a segurança, mantendo a eficiência operacional. À medida que a rede do Kubernetes continua a evoluir, adotar abordagens modernas orientadas à observabilidade será fundamental para proteger cargas de trabalho de forma eficaz.