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

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 utilizadas para nodes 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 utilizam 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 ao tráfego usando o Linux Berkeley Packet Filter (BPF), que é mais eficiente do que o 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 regras de filtro IPTable ou HNS ACLPolicy.

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

Limitações do Azure Network Policy Manager

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 namespace ou rótulo 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).

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 menosipBlock seções tem menos probabilidade de afetar o problema.

Filtrando o balanceador de carga ou o tráfego de serviço

O encaminhamento de serviços Kubernetes, tanto para serviços de entrada como de saída, frequentemente envolve a reescrita dos IPs de origem e de destino do tráfego processado, incluindo o tráfego que entra no cluster a partir de um serviço LoadBalancer. Este comportamento de reescrita significa que o tráfego recebido ou enviado para um serviço externo pode não ser devidamente processado pelas políticas de rede (consulte a documentação das Políticas de Rede Kubernetes para mais detalhes).

Para restringir quais fontes podem enviar tráfego para um serviço de balanceador de carga, use o spec.loadBalancerSourceRanges para configurar o bloqueio de tráfego que é aplicado antes que ocorra qualquer reescrita. Mais informações estão disponíveis na documentação do balanceador de carga padrão do AKS .

Antes de começar

Você precisa da CLI do Azure versão 2.0.61 ou posterior instalada e configurada. Para localizar a versão, execute az --version. 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.

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, cria-se um cluster com pools de nós Linux e com o Azure Network Policy Manager ativado.

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 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 parte, você cria um cluster com pools de nós do Windows e o Azure Network Policy Manager ativado.

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

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

Registar o sinalizador de funcionalidade WindowsNetworkPolicyPreview

Registe a WindowsNetworkPolicyPreview feature flag 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 estado 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 planear adicionar pools de nós do Windows ao cluster, inclua os parâmetros windows-admin-username e windows-admin-password que cumprem os requisitos de senha do Windows Server .

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.

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:

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.

--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 correr bem, não terá saída.

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

Testar a conectividade com a política de rede

Para adicionar políticas de rede, crie um ficheiro com nome 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 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

Mudança para Calico autogerida

Como mostrado nas outras funcionalidades da tabela, o AKS só suporta Calico para políticas de rede padrão do Kubernetes e não testa outras funcionalidades. Se quiser mudar para a Calico autogerida, siga as instruções da Tigera em Migrar de Calico gerida pela Azure para Calico autogerida. A documentação da Tiegra menciona que, para o Calico autogerido, terás de definir --network-policy none como na secção de desinstalação.

Desinstalar o Azure Network Policy Manager ou o Calico

Requirements:

• Azure CLI versão 2.63 ou posterior

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

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.