Partilhar via

Proteja o tráfego entre pods usando políticas de rede no AKS

  • Artigo

Quando você executa aplicativos modernos baseados em microsserviços no Kubernetes, geralmente deseja controlar quais componentes podem se comunicar entre si. O princípio do menor privilégio deve ser aplicado à forma como o tráfego pode fluir entre pods em um cluster do Serviço Kubernetes do Azure (AKS). Digamos que você queira bloquear o tráfego diretamente para aplicativos back-end. O recurso de política de rede no Kubernetes permite definir regras para o tráfego de entrada e saída entre pods em um cluster.

Este artigo mostra como instalar o mecanismo de política de rede e criar políticas de rede do Kubernetes para controlar o fluxo de tráfego entre pods no AKS. As políticas de rede podem ser usadas para nós e pods baseados em Linux ou Windows no AKS.

Visão geral da política de rede

Todos os pods em um cluster AKS podem enviar e receber tráfego sem limitações, por padrão. Para melhorar a segurança, você pode definir regras que controlam o fluxo de tráfego. Os aplicativos back-end geralmente são expostos apenas aos serviços front-end necessários, por exemplo. Ou, os componentes de banco de dados só são acessíveis às camadas de aplicativo que se conectam a eles.

A política de rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre pods. Ao usar diretivas de rede, você define um conjunto ordenado de regras para enviar e receber tráfego. Você aplica as regras a uma coleção de pods que correspondem a um ou mais seletores de rótulo.

As regras de diretiva de rede são definidas como manifestos YAML. As políticas de rede podem ser incluídas como parte de um manifesto mais amplo que também cria uma implantação ou serviço.

Opções de política de rede no AKS

O Azure fornece três mecanismos de Política de Rede para aplicar políticas de rede:

  • Cilium para clusters AKS que usam o Azure CNI Powered by Cilium.
  • Azure Network Policy Manager.
  • Calico, uma solução de segurança de rede e rede de código aberto fundada pela Tigera.

O Cilium é o nosso motor de Política de Rede recomendado. A Cilium aplica a política de rede no tráfego usando o Linux Berkeley Packet Filter (BPF), que geralmente é mais eficiente do que "IPTables". Veja mais detalhes na documentação do Azure CNI Powered by Cilium.
Para impor as políticas especificadas, o Azure Network Policy Manager para Linux usa Linux IPTables. O Azure Network Policy Manager para Windows usa ACLPolicies do Serviço de Rede de Host (HNS). As políticas são convertidas em conjuntos de pares de IP permitidos e não permitidos. Esses pares são então programados como IPTable regras de filtro ou HNS ACLPolicy regras.

Diferenças entre os mecanismos de Diretiva de Rede: Cilium, Azure NPM e Calico

Funcionalidade Azure Network Policy Manager Calico Cílio
Plataformas suportadas Linux, Windows Server 2022 (Pré-visualização). Linux, Windows Server 2019 e 2022. Linux.
Opções de rede suportadas Azure Container Networking Interface (CNI). Azure CNI (Linux, Windows Server 2019 e 2022) e kubenet (Linux). Azure CNI.
Conformidade com a especificação do Kubernetes Todos os tipos de política suportados Todos os tipos de política são suportados. Todos os tipos de política são suportados.
Outras funcionalidades Nenhum. Modelo de política estendida que consiste em Política de Rede Global, Conjunto de Rede Global e Ponto de Extremidade de Host. Para obter mais informações sobre como usar a calicoctl CLI para gerenciar esses recursos estendidos, consulte referência de usuário calicoctl. Nenhum.
Suporte Suportado pela equipa de Suporte e Engenharia do Azure. Suportado pela equipa de Suporte e Engenharia do Azure. Suportado pela equipa de Suporte e Engenharia do Azure.

Limitações do Azure Network Policy Manager

Nota

Com o Azure NPM para Linux, não permitimos dimensionamento além de 250 nós e 20.000 pods. Se você tentar dimensionar além desses limites, você pode enfrentar erros de falta de memória (OOM). Para melhor escalabilidade e suporte a IPv6, e se as limitações a seguir forem preocupantes, recomendamos usar ou atualizar para o Azure CNI Powered by Cilium para usar o Cilium como o mecanismo de diretiva de rede.

O Azure NPM não suporta IPv6. Caso contrário, ele suporta totalmente as especificações de política de rede no Linux.

No Windows, o Azure NPM não oferece suporte aos seguintes recursos das especificações de política de rede:

  • Portas nomeadas.
  • Protocolo de transmissão de controle de fluxo (SCTP).
  • Seletores de rótulo ou namespace de correspondência negativa. Por exemplo, todos os rótulos, exceto debug=true.
  • except blocos de roteamento entre domínios sem classe (CIDR com exceções).

Nota

Os logs de pod do Azure Network Policy Manager registram um erro se uma política de rede sem suporte for criada.

Editar/excluir políticas de rede

Em alguns casos raros, há uma chance de atingir uma condição de corrida que pode resultar em conectividade temporária e inesperada para novas conexões de/para pods em qualquer nó afetado ao editar ou excluir uma política de rede "grande o suficiente". Atingir essa condição de corrida nunca afeta as conexões ativas.

Se essa condição de corrida ocorrer para um nó, o pod do Azure NPM nesse nó entrará em um estado em que não pode atualizar as regras de segurança, o que pode levar a uma conectividade inesperada para novas conexões de/para pods no nó afetado. Para atenuar o problema, o pod do Azure NPM reinicia automaticamente ~15 segundos após entrar nesse estado. Enquanto o Azure NPM está reinicializando no nó afetado, ele exclui todas as regras de segurança e, em seguida, reaplica as regras de segurança para todas as políticas de rede. Enquanto todas as regras de segurança estão sendo reaplicadas, há uma chance de conectividade temporária e inesperada para novas conexões de/para pods no nó afetado.

Para limitar a chance de atingir essa condição de corrida, você pode reduzir o tamanho da diretiva de rede. É mais provável que esse problema aconteça para uma diretiva de rede com várias ipBlock seções. Uma política de rede com quatro ou menos ipBlock seções tem menos probabilidade de afetar o problema.

Antes de começar

Você precisa da CLI do Azure versão 2.0.61 ou posterior instalada e configurada. Executar az --version para localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).

Criar um cluster AKS e ativar a política de rede

Para ver as políticas de rede em ação, crie um cluster AKS que suporte a política de rede e, em seguida, trabalhe na adição de políticas.

Para usar o Gerenciador de Políticas de Rede do Azure, você deve usar o plug-in CNI do Azure. O Calico pode ser usado com o plug-in CNI do Azure ou com o plug-in Kubenet CNI.

O script de exemplo a seguir cria um cluster AKS com identidade atribuída ao sistema e habilita a política de rede usando o Gerenciador de Políticas de Rede do Azure.

Nota

Calico pode ser usado com o --network-plugin azure ou --network-plugin kubenet parâmetros.

Em vez de usar uma identidade atribuída pelo sistema, você também pode usar uma identidade atribuída pelo usuário. Para obter mais informações, consulte Usar identidades gerenciadas.

Criar um cluster AKS com o Azure Network Policy Manager ativado - apenas Linux

Nesta seção, você cria um cluster com pools de nós Linux e o Azure Network Policy Manager habilitado.

Para começar, substitua $RESOURCE_GROUP_NAME os valores das variáveis e $CLUSTER_NAME .

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$LOCATION=canadaeast

Crie o cluster AKS e especifique azure para o network-plugin e network-policy.

Para criar um cluster, use o seguinte comando:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

Criar um cluster AKS com o Azure Network Policy Manager ativado - Windows Server 2022 (pré-visualização)

Nesta seção, você cria um cluster com pools de nós do Windows e o Azure Network Policy Manager habilitado.

Nota

O Azure Network Policy Manager com nós do Windows está disponível apenas no Windows Server 2022.

Instalar a extensão aks-preview da CLI do Azure

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Para instalar a aks-preview extensão, execute o seguinte comando:

az extension add --name aks-preview

Para atualizar para a versão mais recente da extensão lançada, execute o seguinte comando:

az extension update --name aks-preview

Registrar o sinalizador do recurso WindowsNetworkPolicyPreview

Registre o WindowsNetworkPolicyPreview sinalizador de recurso usando o comando az feature register , conforme mostrado no exemplo a seguir:

az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Leva alguns minutos para que o status mostre Registrado. Verifique o status do registro usando o comando az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Quando o status refletir Registrado, atualize o Microsoft.ContainerService registro do provedor de recursos usando o comando az provider register :

az provider register --namespace Microsoft.ContainerService

Criar o cluster do AKS

Agora, você substitui os valores para as $RESOURCE_GROUP_NAMEvariáveis , $CLUSTER_NAMEe $WINDOWS_USERNAME .

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$WINDOWS_USERNAME=myWindowsUserName
$LOCATION=canadaeast

Crie um nome de usuário para usar como credenciais de administrador para seus contêineres do Windows Server no cluster. O comando a seguir solicita um nome de usuário. Defina-o como $WINDOWS_USERNAME. Lembre-se de que os comandos neste artigo são inseridos em um shell Bash.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

Para criar um cluster, use o seguinte comando:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

A criação do cluster demora alguns minutos. Por padrão, o cluster é criado apenas com um pool de nós Linux. Se quiser usar pools de nós do Windows, você pode adicionar um. Eis um exemplo:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Crie um cluster AKS com o Calico ativado

Crie o cluster AKS e especifique --network-plugin azure, e --network-policy calico. A especificação --network-policy calico habilita o Calico em pools de nós Linux e Windows.

Se você planeja adicionar pools de nós do Windows ao cluster, inclua os windows-admin-username parâmetros e windows-admin-password que atendem aos requisitos de senha do Windows Server.

Importante

No momento, o uso de políticas de rede do Calico com nós do Windows está disponível em novos clusters usando o Kubernetes versão 1.20 ou posterior com o Calico 3.17.2 e requer que você use a rede CNI do Azure. Os nós do Windows em clusters AKS com o Calico ativado também têm o IP flutuante ativado por padrão.

Para clusters com apenas pools de nós Linux executando o Kubernetes 1.20 com versões anteriores do Calico, a versão do Calico atualiza automaticamente para 3.17.2.

Crie um nome de usuário para usar como credenciais de administrador para seus contêineres do Windows Server no cluster. O comando a seguir solicita um nome de usuário. Defina-o como $WINDOWS_USERNAME. Lembre-se de que os comandos neste artigo são inseridos em um shell Bash.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy calico \
    --generate-ssh-keys

A criação do cluster demora alguns minutos. Por padrão, o cluster é criado apenas com um pool de nós Linux. Se quiser usar pools de nós do Windows, você pode adicionar um. Por exemplo:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Instalar o Azure Network Policy Manager ou o Calico em um cluster existente

A instalação do Azure Network Policy Manager ou do Calico em clusters AKS existentes também é suportada.

Aviso

O processo de atualização aciona cada pool de nós para ser recriado simultaneamente. Não há suporte para a atualização de cada pool de nós separadamente. Dentro de cada pool de nós, os nós são recriados seguindo o mesmo processo de uma operação de atualização de versão padrão do Kubernetes, na qual nós de buffer são adicionados temporariamente para minimizar a interrupção dos aplicativos em execução enquanto o processo de recriação de imagens do nó está em andamento. Portanto, quaisquer interrupções que possam ocorrer são semelhantes ao que você esperaria durante uma atualização de imagem de nó ou operação de atualização de versão do Kubernetes.

Exemplo de comando para instalar o Azure Network Policy Manager:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy azure

Exemplo de comando para instalar o Calico:

Aviso

Este aviso aplica-se à atualização de clusters Kubenet com o Calico ativado para a Sobreposição CNI do Azure com o Calico ativado.

  • Em clusters Kubenet com o Calico habilitado, o Calico é usado como um mecanismo de política de rede e CNI.
  • Nos clusters CNI do Azure, o Calico é usado apenas para imposição de política de rede, não como CNI. Isso pode causar um pequeno atraso entre quando o pod inicia e quando o Calico permite o tráfego de saída do pod.

Recomenda-se usar Cilium em vez de Calico para evitar este problema. Saiba mais sobre o Cilium no Azure CNI Powered by Cilium

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy calico

Atualizar um cluster existente que tenha o Azure NPM ou o Calico instalado para o Azure CNI Powered by Cilium

Para atualizar um cluster existente que tenha o mecanismo de Política de Rede instalado no Azure CNI Powered by Cilium, consulte Atualizar um cluster existente para o Azure CNI Powered by Cilium

Verificar a configuração da política de rede

Quando o cluster estiver pronto, configure kubectl para se conectar ao cluster do Kubernetes usando o comando az aks get-credentials . Este comando baixa credenciais e configura a CLI do Kubernetes para usá-las:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Para iniciar a verificação da diretiva de rede, crie um aplicativo de exemplo e defina regras de tráfego.

Primeiro, crie um namespace chamado demo para executar os pods de exemplo:

kubectl create namespace demo

Agora crie dois pods no cluster chamado client e server.

Nota

Se você quiser agendar o cliente ou servidor em um nó específico, adicione o seguinte bit antes do --command argumento no comando pod creation kubectl run :

--overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'

Crie um server pod. Este pod serve na porta TCP 80:

kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"

Crie um client pod. O comando a seguir executa Bash no client pod:

kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash

Agora, em uma janela separada, execute o seguinte comando para obter o IP do servidor:

kubectl get pod --output=wide -n demo

A saída deve ser semelhante a:

NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>

Testar a conectividade sem política de rede

No shell do cliente, execute o seguinte comando para verificar a conectividade com o servidor. Substitua server-ip usando o IP encontrado na saída da execução do comando anterior. Se a conexão for bem-sucedida, não haverá saída.

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

Testar a conectividade com a política de rede

Para adicionar diretivas de rede, crie um arquivo chamado demo-policy.yaml e cole o seguinte manifesto YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: demo-policy
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: client
    ports:
    - port: 80
      protocol: TCP

Especifique o nome do seu manifesto YAML e aplique-o usando kubectl apply:

kubectl apply –f demo-policy.yaml

Agora, no shell do cliente, verifique a conectividade com o servidor executando o seguinte /agnhost comando:

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

A conectividade com o tráfego é bloqueada porque o servidor está rotulado com app=server, mas o cliente não está rotulado. O comando connect anterior produz esta saída:

TIMEOUT

Execute o seguinte comando para rotular e verificar a client conectividade com o servidor. A saída não deve retornar nada.

kubectl label pod client -n demo app=client

Desinstalar o Azure Network Policy Manager ou o Calico

Requisitos:

  • Azure CLI versão 2.63 ou posterior

Nota

  • O processo de desinstalação não remove Custom Resource Definitions (CRDs) e Custom Resources (CRs) usados pelo Calico. Todos esses CRDs e CRs têm nomes terminados com "projectcalico.org" ou "tigera.io". Esses CRDs e CRs associados podem ser excluídos manualmente depois que o Calico é desinstalado com êxito (excluir os CRDs antes de remover o Calico quebra o cluster).
  • A atualização não removerá nenhum recurso NetworkPolicy no cluster, mas após a desinstalação essas políticas não serão mais aplicadas.

Aviso

O processo de atualização aciona cada pool de nós para ser recriado simultaneamente. Não há suporte para a atualização de cada pool de nós separadamente. Quaisquer interrupções na rede de cluster são semelhantes a uma atualização de imagem de nó ou atualização de versão do Kubernetes, em que cada nó em um pool de nós é recriado.

Para remover o Azure Network Policy Manager ou o Calico de um cluster, execute o seguinte comando:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy none

Clean up resources (Limpar recursos)

Neste artigo, você criou um namespace e dois pods e aplicou uma diretiva de rede. Para limpar esses recursos, use o comando kubectl delete e especifique o nome do recurso:

kubectl delete namespace demo

Próximos passos

Para obter mais informações sobre recursos de rede, consulte Conceitos de rede para aplicativos no Serviço Kubernetes do Azure (AKS).

Para saber mais sobre políticas, consulte Políticas de rede do Kubernetes.