Compartilhar via

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

  • Artigo

Ao executar aplicativos modernos baseados em microsserviços no Kubernetes, muitas vezes você deseja controlar quais componentes podem se comunicar uns com os outros. O princípio de privilégios mínimos deve ser aplicado a como o tráfego pode fluir entre pods em um cluster AKS (Serviço de Kubernetes do Azure). Digamos que você queira bloquear o tráfego diretamente para os aplicativos de back-end. O recurso de política de rede no Kubernetes permite definir regras para o tráfego de entrada e de saída entre os 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 do 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 de 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 para as 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 políticas 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 política 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 um serviço.

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

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

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

Diferenças entre motores de Política de Rede: Cilium, Azure NPM e Calico

Funcionalidade Gerenciador de Política de Rede do Azure Calico Cílio
Plataformas compatíveis Linux, Windows Server 2022 (versão prévia). Linux, Windows Server 2019 e 2022. Linux.
Opções de rede com suporte CNI do Azure (Interface de Rede de Contêiner do Azure). CNI do Azure (Linux, Windows Server 2019 e 2022) e kubenet (Linux). CNI do Azure.
Conformidade com a especificação do Kubernetes Todos os tipos de política com suporte Todos os tipos de política são suportados. Todos os tipos de política são suportados.
Outros recursos Nenhum. Modelo de política estendida composto pela Política de Rede Global, Conjunto de Rede Global e Ponto de Extremidade do Host. Para obter mais informações sobre como usar a CLI calicoctl para gerenciar esses recursos estendidos, confira a Referência de usuário do calicoctl. Nenhum.
Suporte Com suporte da equipe de Engenharia e Suporte do Azure. Com suporte da equipe de Engenharia e Suporte do Azure. Com suporte da equipe de Engenharia e Suporte do Azure.

Limitações do Gerenciador de Políticas de Rede do Azure

Observação

Com o Azure NPM para Linux, não permitimos escalar além de 250 nós e 20.000 pods. Se você tentar escalar além desses limites, poderão ocorrer erros por Memória Insuficiente (OOM). Para obter melhor escalabilidade e suporte ao IPv6, e se as limitações a seguir forem preocupantes, recomendamos usar ou atualizar para a CNI do Azure da plataforma Cilium para usar o Cilium como o mecanismo de política de rede.

O NPM do Azure não dá suporte ao IPv6. Caso contrário, ele dá suporte total às especificações de política de rede no Linux.

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

  • Portas nomeadas.
  • Protocolo SCTP.
  • Rótulo de correspondência negativa ou seletores de namespace. Por exemplo, todos os rótulos, exceto debug=true.
  • Blocos de CIDR (Roteamento entre Domínios sem Classificação) except – CIDR com exceções.

Observação

Os logs de pod do Gerenciador de Políticas de Rede do Azure registrarão 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 quaisquer nós afetados 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 NPM do Azure nesse nó entrará em um estado em que ele não poderá 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 NPM do Azure reinicia automaticamente cerca de 15 segundos depois de entrar nesse estado. Enquanto é reinicializado no nó afetado, o NPM do Azure exclui todas as regras de segurança e, em seguida, reaplica as regras de segurança para todas as políticas de rede. Embora todas as regras de segurança estejam 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 política de rede. É mais provável que esse problema ocorra em uma política de rede com várias seções ipBlock. Uma política de rede com quatro ou menos ipBlock seções tem menor probabilidade de atingir o problema.

Antes de começar

Você precisará da CLI do Azure versão 2.0.61 ou posterior instalada e configurada. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

Cria um cluster do AKS e habilita a política de rede

Para ver as políticas de rede em ação, você vai criar um cluster do AKS que dá suporte à política de rede e, em seguida, trabalhar na adição de políticas.

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

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

Observação

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

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, confira Usar identidades gerenciadas.

Criar um cluster do AKS com o Gerenciador de Política de Rede do Azure habilitado – somente Linux

Nesta seção, você criará de um cluster com pools de nós do Linux e o Gerenciador de Políticas de Rede do Azure habilitados.

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

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

Crie o cluster do AKS e especifique o 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 do AKS com o Gerenciador de Políticas de Rede do Azure habilitado – Windows Server 2022 (versão prévia)

Nesta seção, você criará de um cluster com pools de nós do Windows e o Gerenciador de Políticas de Rede do Azure habilitados.

Observação

O Gerenciador de Política de Rede do Azure com nós do Windows está disponível apenas no Windows Server 2022.

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

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Para instalar a extensão aks-preview, 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 de recurso WindowsNetworkPolicyPreview

Registre o sinalizador de recursos WindowsNetworkPolicyPreview usando o comando az feature register, conforme mostrado no seguinte exemplo:

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

Demora alguns minutos para o status exibir Registrado. Verifique o status do registro usando o comando az feature show:

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

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

az provider register --namespace Microsoft.ContainerService

Criar o cluster do AKS

Agora, substitua os valores das variáveis $RESOURCE_GROUP_NAME, $CLUSTER_NAME e $WINDOWS_USERNAME.

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

Crie um nome de usuário para usá-lo como as credenciais de administrador nos contêineres do Windows Server no seu cluster. O comando a seguir solicita seu nome de usuário. Defina-o como $WINDOWS_USERNAME. Lembre-se que os comandos neste artigo são inseridos em um shell do 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

São necessários alguns minutos para criar o cluster. Por padrão, o cluster é criado apenas com um pool de nós do Linux. Caso queira usar pools de nós do Windows, você pode adicionar um. Veja um exemplo:

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

Criar um cluster AKS com Calico habilitado

Crie o cluster AKS e especifique --network-plugin azure, e --network-policy calico. Especificar --network-policy calico habilita o Calico nos pools de nós do Linux e do Windows.

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

Importante

No momento, o uso das políticas de rede do Calico com os 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 exige o uso da rede da CNI do Azure. Os nós do Windows em clusters do AKS com o Calico habilitado também têm o IP flutuante habilitado por padrão.

Para os clusters com apenas pools de nós do Linux que executam o Kubernetes 1.20 com versões anteriores do Calico, a versão do Calico é atualizada automaticamente para 3.17.2.

Crie um nome de usuário para usá-lo como as credenciais de administrador nos contêineres do Windows Server no seu cluster. O comando a seguir solicita seu nome de usuário. Defina-o como $WINDOWS_USERNAME. Lembre-se que os comandos neste artigo são inseridos em um shell do 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

São necessários alguns minutos para criar o cluster. Por padrão, o cluster é criado apenas com um pool de nós do Linux. Caso queira 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

Instale o Azure Network Policy Manager ou o Calico num cluster existente

Também há suporte para a instalação do Azure Network Policy Manager ou do Calico em clusters AKS existentes.

Aviso

O processo de atualização dispara cada pool de nós a ter a imagem recriada simultaneamente. Não há suporte para atualizar cada pool de nós separadamente para Sobreposição. Dentro de cada pool de nós, os nós são reimaginados seguindo o mesmo processo que em uma operação de atualização de versão padrão do Kubernetes, em que nós de buffer são temporariamente adicionados para minimizar a interrupção de aplicativos em execução enquanto o processo de restauração do estado anterior do nó estiver em andamento. Portanto, quaisquer interrupções que possam ocorrer são semelhantes ao que você esperaria durante uma atualização de imagem do nó ou operação de atualização de versão do Kubernetes.

Comando de exemplo 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

Esse aviso se aplica à atualização de clusters Kubenet com Calico habilitado para CNI do Azure Overlay com Calico habilitado.

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

Recomenda-se usar Cilium em vez de Calico para evitar esse problema. Saiba mais sobre o Cilium em CNI do Azure desenvolvido pela Cilium

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

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

Para atualizar um cluster existente que tenha o motor de Política de Rede instalado no CNI do Azure Powered by Cilium, veja Atualizar um cluster existente para 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 as 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 política de rede, você criará um aplicativo de exemplo e definirá 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.

Observação

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

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

Crie um pod server. Esse 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 pod client. O comando a seguir executa o Bash no pod client:

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 assim:

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 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 conectividade com política de rede

Para adicionar políticas 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 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 comando /agnhost a seguir:

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

A conectividade com o tráfego é bloqueada, pois o servidor é rotulado com app=server, mas o cliente não é rotulado. O comando de conexão anterior suspende esta saída:

TIMEOUT

Execute o comando a seguir para rotular o client e verificar a 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 Calico

Requisitos:

  • CLI do Azure, versão 2.63 ou posterior

Observação

  • O processo de desinstalação não remove as Definições de Recursos Personalizados (CRDs) e os Recursos Personalizados (CRs) usados pelo Calico. Todos esses CRDs e CRs têm nomes que terminam com "projectcalico.org" ou "tigera.io". Esses CRDs e CRs associados podem ser excluídos manualmente após a desinstalação bem-sucedida do Calico (excluir os CRDs antes de remover o Calico interrompe o cluster).
  • A atualização não removerá nenhum recurso NetworkPolicy do cluster, mas após a desinstalação essas políticas não serão mais aplicadas.

Aviso

O processo de atualização dispara cada pool de nós a ter a imagem recriada simultaneamente. Não há suporte para atualizar cada pool de nós separadamente para Sobreposição. Todas as interrupções de rede de cluster são semelhantes a uma atualização de imagem de nó ou atualização da versão do Kubernetes, onde cada nó em um pool de nós é recriado.

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

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

Limpar os recursos

Neste artigo, você criou dois namespaces e dois pods e aplicou uma política de rede. Para limpar esses recursos, use o comando kubectl delete e especifique os nomes de recurso:

kubectl delete namespace demo

Próximas etapas

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

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