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 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
O Azure Network Policy Manager não suporta IPv6. Caso contrário, o Azure Network Policy Manager suporta totalmente as especificações de política de rede no Linux.
No Windows, o Azure Network Policy Manager não suporta:
- 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) (um CIDR com exceções).
Nota
Os logs de pod do Gerenciador de Políticas de Rede do Azure registram um erro se uma política sem suporte for criada.
Escala
Com o Azure Network Policy Manager para Linux, não permitimos dimensionamento além de 250 nós e 20.000 pods. Se você tentar dimensionar além desses limites, poderá encontrar erros de "Memória insuficiente" (OOM).
Para melhor dimensionamento e desempenho, considere o uso do Cilium para gerenciar políticas de rede. Para atualizar do Azure NPM para o Cilium, consulte estas instruções.
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_NAME
variáveis , $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 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. 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.
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 (Pré-visualização)
Requisitos:
- aks-preview Azure CLI versão 0.5.166 ou posterior. Consulte Instalar a extensão aks-preview Azure CLI.
- Azure CLI versão 2.54 ou posterior
- API REST AKS versão 2023-08-02-preview 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.
Azure Kubernetes Service