Controlo de tráfego de nós de cluster em Azure Kubernetes Service (AKS)

Este artigo fornece os detalhes necessários que lhe permitem proteger o tráfego de saída do seu Azure Kubernetes Service (AKS). Contém os requisitos de cluster para uma implantação de AKS base, e requisitos adicionais para addons e funcionalidades opcionais. No final, será dado um exemplo sobre a forma de configurar estes requisitos com Azure Firewall. No entanto, pode aplicar estas informações a qualquer método ou aparelho de restrição de saída.

Fundo

Os clusters AKS são implantados numa rede virtual. Esta rede pode ser gerida (criada por AKS) ou personalizada (pré-configurada previamente pelo utilizador). Em qualquer dos casos, o cluster tem dependências de saída de serviços fora dessa rede virtual (o serviço não tem dependências de entrada).

Para fins de gestão e operacional, os nódes num cluster AKS precisam de aceder a determinadas portas e nomes de domínio totalmente qualificados (FQDNs). Estes pontos finais são necessários para que os nós comuniquem com o servidor API, ou para descarregar e instalar componentes de cluster de Kubernetes e atualizações de segurança de nó. Por exemplo, o cluster precisa de retirar imagens de contentores do sistema de base do Microsoft Container Registry (MCR).

As dependências de saída da AKS são quase totalmente definidas com FQDNs, que não têm endereços estáticos por trás deles. A falta de endereços estáticos significa que os Grupos de Segurança da Rede não podem ser usados para bloquear o tráfego de saída de um cluster AKS.

Por padrão, os clusters AKS têm acesso ilimitado à internet de saída (saída). Este nível de acesso à rede permite que nós e serviços que você execute para aceder a recursos externos conforme necessário. Se desejar restringir o tráfego de saídas, um número limitado de portos e endereços deve ser acessível para manter tarefas saudáveis de manutenção do cluster. A solução mais simples para proteger endereços de saída reside na utilização de um dispositivo de firewall que pode controlar o tráfego de saída com base em nomes de domínio. Azure Firewall, por exemplo, pode restringir o tráfego http e HTTPS de saída com base na FQDN do destino. Também pode configurar as suas regras de firewall e segurança preferidas para permitir as portas e endereços necessários.

Importante

Este documento abrange apenas como bloquear o tráfego que sai da sub-rede AKS. AKS não tem requisitos de entrada por defeito. O bloqueio do tráfego interno da sub-rede utilizando grupos de segurança de rede (NSGs) e firewalls não é suportado. Para controlar e bloquear o tráfego dentro do cluster, utilize as Políticas de Rede.

Regras de rede de saída necessárias e FQDNs para clusters AKS

São necessárias as seguintes regras de rede e FQDN/aplicação para um cluster AKS, pode usá-las se desejar configurar uma solução que não Azure Firewall.

  • As dependências do endereço IP destinam-se ao tráfego não-HTTP/S (tráfego TCP e UDP)
  • Os pontos finais FQDN HTTP/HTTPS podem ser colocados no seu dispositivo de firewall.
  • Os pontos finais wildcard HTTP/HTTPS são dependências que podem variar com o seu cluster AKS com base em uma série de qualificações.
  • A AKS usa um controlador de admissão para injetar o FQDN como uma variável ambiental para todas as implementações no sistema kube e sistema de gatekeeper, que garante que toda a comunicação do sistema entre nós e servidor API utiliza o servidor API FQDN e não o IP do servidor API.
  • Se tiver uma aplicação ou solução que precise de falar com o servidor API, tem de adicionar uma regra de rede adicional para permitir que a comunicação TCP seja a porta 443 do IP do seu servidor API.
  • Em raras ocasiões, se houver uma operação de manutenção, o seu IP do servidor API pode mudar. As operações de manutenção planeadas que podem alterar o IP do servidor API são sempre comunicadas com antecedência.

Azure Global exigiu regras de rede

As regras de rede exigidas e as dependências de endereços IP são:

Ponto final de destino Protocolo Porta Utilização
*:1194
Ou
ServiceTag - AzureCloud.<Region>:1194
Ou
CIDRs Regionais - RegionCIDRs:1194
Ou
APIServerPublicIP:1194 (only known after cluster creation)
UDP 1194 Para uma comunicação segura entre os nós e o avião de controlo. Isto não é necessário para clusters privados, ou para clusters com o agente konnectivity habilitado.
*:9000
Ou
ServiceTag - AzureCloud.<Region>:9000
Ou
CIDRs Regionais - RegionCIDRs:9000
Ou
APIServerPublicIP:9000 (only known after cluster creation)
TCP 9000 Para uma comunicação segura entre os nós e o avião de controlo. Isto não é necessário para clusters privados, ou para clusters com o agente konnectivity habilitado.
*:123ou ntp.ubuntu.com:123 (se utilizar Azure Firewall regras de rede) UDP 123 Requerido para sincronização de tempo do Protocolo de Tempo de Rede (NTP) nos nós Linux. Isto não é necessário para os nós previstos após março de 2021.
CustomDNSIP:53 (if using custom DNS servers) UDP 53 Se estiver a utilizar servidores DNS personalizados, deve certificar-se de que estão acessíveis pelos nós do cluster.
APIServerPublicIP:443 (if running pods/deployments that access the API Server) TCP 443 Necessários se as cápsulas/implementações de execução que acedam ao Servidor API, essas cápsulas/implementações utilizariam o IP API. Esta porta não é necessária para aglomerados privados.

Azure Global exigiu regras FQDN / aplicação

São necessárias as seguintes regras de aplicação fQDN/ aplicação:

Destino FQDN Porta Utilização
*.hcp.<location>.azmk8s.io HTTPS:443 Obrigatório para comunicação de servidores API -> Nó<. Substitua <a localização> pela região onde o seu cluster AKS está implantado. Isto é necessário para clusters com agente konnectivity-activado . A Konnectivity também usa Application-Layer Negociação de Protocolo (ALPN) para comunicar entre o agente e o servidor. Bloquear ou reescrever a extensão ALPN causará uma falha. Isto não é necessário para agrupamentos privados.
mcr.microsoft.com HTTPS:443 Obrigado a aceder a imagens no Microsoft Container Registry (MCR). Este registo contém imagens/gráficos de primeira parte (por exemplo, coreDNS, etc.). Estas imagens são necessárias para a correta criação e funcionamento do cluster, incluindo operações de escala e upgrade.
*.data.mcr.microsoft.com HTTPS:443 Necessário para armazenamento MCR apoiado pela rede de entrega de conteúdos Azure (CDN).
management.azure.com HTTPS:443 Necessário para as operações de Kubernetes contra a Azure API.
login.microsoftonline.com HTTPS:443 Requerido para a autenticação do Azure Ative Directory.
packages.microsoft.com HTTPS:443 Este endereço é o repositório de pacotes da Microsoft utilizado para operações em cache apt-get . Os pacotes de exemplo incluem Moby, PowerShell e Azure CLI.
acs-mirror.azureedge.net HTTPS:443 Este endereço destina-se ao repositório necessário para descarregar e instalar binários necessários, como kubenet e Azure CNI.

Azure China 21Vianet exigiu regras de rede

As regras de rede exigidas e as dependências de endereços IP são:

Ponto final de destino Protocolo Porta Utilização
*:1194
Ou
ServiceTag - AzureCloud.Region:1194
Ou
CIDRs Regionais - RegionCIDRs:1194
Ou
APIServerPublicIP:1194 (only known after cluster creation)
UDP 1194 Para uma comunicação segura entre os nós e o avião de controlo.
*:9000
Ou
ServiceTag - AzureCloud.<Region>:9000
Ou
CIDRs Regionais - RegionCIDRs:9000
Ou
APIServerPublicIP:9000 (only known after cluster creation)
TCP 9000 Para uma comunicação segura entre os nós e o avião de controlo.
*:22
Ou
ServiceTag - AzureCloud.<Region>:22
Ou
CIDRs Regionais - RegionCIDRs:22
Ou
APIServerPublicIP:22 (only known after cluster creation)
TCP 22 Para uma comunicação segura entre os nós e o avião de controlo.
*:123ou ntp.ubuntu.com:123 (se utilizar Azure Firewall regras de rede) UDP 123 Requerido para sincronização de tempo do Protocolo de Tempo de Rede (NTP) nos nós Linux.
CustomDNSIP:53 (if using custom DNS servers) UDP 53 Se estiver a utilizar servidores DNS personalizados, deve certificar-se de que estão acessíveis pelos nós do cluster.
APIServerPublicIP:443 (if running pods/deployments that access the API Server) TCP 443 Necessários se as cápsulas/implementações que acedam ao Servidor API, essas cápsulas/implementações utilizariam o IP API.

Azure China 21Vianet exigiu regras FQDN /aplicação

São necessárias as seguintes regras de aplicação fQDN/ aplicação:

Destino FQDN Porta Utilização
*.hcp.<location>.cx.prod.service.azk8s.cn HTTPS:443 Obrigatório para comunicação de servidores API -> Nó<. Substitua <a localização> pela região onde o seu cluster AKS está implantado.
*.tun.<location>.cx.prod.service.azk8s.cn HTTPS:443 Obrigatório para comunicação de servidores API -> Nó<. Substitua <a localização> pela região onde o seu cluster AKS está implantado.
mcr.microsoft.com HTTPS:443 Obrigado a aceder a imagens no Microsoft Container Registry (MCR). Este registo contém imagens/gráficos de primeira parte (por exemplo, coreDNS, etc.). Estas imagens são necessárias para a correta criação e funcionamento do cluster, incluindo operações de escala e upgrade.
.data.mcr.microsoft.com HTTPS:443 Necessário para armazenamento MCR apoiado pela Rede de Entrega de Conteúdos Azure (CDN).
management.chinacloudapi.cn HTTPS:443 Necessário para as operações de Kubernetes contra a Azure API.
login.chinacloudapi.cn HTTPS:443 Requerido para a autenticação do Azure Ative Directory.
packages.microsoft.com HTTPS:443 Este endereço é o repositório de pacotes da Microsoft utilizado para operações em cache apt-get . Os pacotes de exemplo incluem Moby, PowerShell e Azure CLI.
*.azk8s.cn HTTPS:443 Este endereço destina-se ao repositório necessário para descarregar e instalar binários necessários, como kubenet e Azure CNI.

Governo dos EUA exigiu regras de rede

As regras de rede exigidas e as dependências de endereços IP são:

Ponto final de destino Protocolo Porta Utilização
*:1194
Ou
ServiceTag - AzureCloud.<Region>:1194
Ou
CIDRs Regionais - RegionCIDRs:1194
Ou
APIServerPublicIP:1194 (only known after cluster creation)
UDP 1194 Para uma comunicação segura entre os nós e o avião de controlo.
*:9000
Ou
ServiceTag - AzureCloud.<Region>:9000
Ou
CIDRs Regionais - RegionCIDRs:9000
Ou
APIServerPublicIP:9000 (only known after cluster creation)
TCP 9000 Para uma comunicação segura entre os nós e o avião de controlo.
*:123ou ntp.ubuntu.com:123 (se utilizar Azure Firewall regras de rede) UDP 123 Requerido para sincronização de tempo do Protocolo de Tempo de Rede (NTP) nos nós Linux.
CustomDNSIP:53 (if using custom DNS servers) UDP 53 Se estiver a utilizar servidores DNS personalizados, deve certificar-se de que estão acessíveis pelos nós do cluster.
APIServerPublicIP:443 (if running pods/deployments that access the API Server) TCP 443 Necessários se as cápsulas/implementações de execução que acedam ao Servidor API, essas cápsulas/implementações utilizariam o IP API.

O Governo dos EUA exigiu regras de FQDN / aplicação

São necessárias as seguintes regras de aplicação fQDN/ aplicação:

Destino FQDN Porta Utilização
*.hcp.<location>.cx.aks.containerservice.azure.us HTTPS:443 Obrigatório para comunicação de servidores API -> Nó<. Substitua <a localização> pela região onde o seu cluster AKS está implantado.
mcr.microsoft.com HTTPS:443 Obrigado a aceder a imagens no Microsoft Container Registry (MCR). Este registo contém imagens/gráficos de primeira parte (por exemplo, coreDNS, etc.). Estas imagens são necessárias para a correta criação e funcionamento do cluster, incluindo operações de escala e upgrade.
*.data.mcr.microsoft.com HTTPS:443 Necessário para armazenamento MCR apoiado pela rede de entrega de conteúdos Azure (CDN).
management.usgovcloudapi.net HTTPS:443 Necessário para as operações de Kubernetes contra a Azure API.
login.microsoftonline.us HTTPS:443 Requerido para a autenticação do Azure Ative Directory.
packages.microsoft.com HTTPS:443 Este endereço é o repositório de pacotes da Microsoft utilizado para operações em cache apt-get . Os pacotes de exemplo incluem Moby, PowerShell e Azure CLI.
acs-mirror.azureedge.net HTTPS:443 Este endereço destina-se ao repositório necessário para instalar binários necessários, como kubenet e Azure CNI.

As seguintes regras de FQDN/aplicação são opcionais, mas recomendadas para clusters AKS:

Destino FQDN Porta Utilização
security.ubuntu.com, azure.archive.ubuntu.com, changelogs.ubuntu.com HTTP:80 Este endereço permite que os nós do cluster Linux descarreguem os patches e atualizações de segurança necessários.

Se optar por bloquear/não permitir estes FQDNs, os nós só receberão atualizações de SO quando fizer uma atualização de imagem de nó ou atualização do cluster.

GPU habilitado clusters AKS

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de aplicação FQDN/aplicação para clusters AKS que tenham GPU habilitado:

Destino FQDN Porta Utilização
nvidia.github.io HTTPS:443 Este endereço é utilizado para a correta instalação e funcionamento do condutor nos nós baseados em GPU.
us.download.nvidia.com HTTPS:443 Este endereço é utilizado para a correta instalação e funcionamento do condutor nos nós baseados em GPU.
download.docker.com HTTPS:443 Este endereço é utilizado para a correta instalação e funcionamento do condutor nos nós baseados em GPU.

Piscinas de nó baseados no Windows Server

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de FQDN /aplicação para a utilização de conjuntos de nó baseados no Windows Server:

Destino FQDN Porta Utilização
onegetcdn.azureedge.net, go.microsoft.com HTTPS:443 Para instalar binários relacionados com janelas
*.mp.microsoft.com, www.msftconnecttest.com, ctldl.windowsupdate.com HTTP:80 Para instalar binários relacionados com janelas

Addons e integrações AKS

Microsoft Defender para Contentores

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de aplicação FQDN /aplicação para clusters AKS que tenham o Microsoft Defender para contentores ativados.

FQDN Porta Utilização
login.microsoftonline.com HTTPS:443 Requerido para autenticação ativa do diretório.
*.ods.opinsights.azure.com HTTPS:443 É necessário que o Microsoft Defender carreque eventos de segurança para a nuvem.
*.oms.opinsights.azure.com HTTPS:443 Necessário para autenticar com espaços de trabalho LogAnalytics.

Loja Secreta CSI

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de aplicação FQDN /aplicação para clusters AKS que tenham a CSI Secret Store ativada.

FQDN Porta Utilização
vault.azure.net HTTPS:443 É necessário que os addon pods da CSI Secret Store falem com o servidor Azure KeyVault.

Azure Monitor para contentores

Existem duas opções para fornecer acesso ao Azure Monitor para contentores, pode permitir o Azure Monitor ServiceTagou fornecer acesso às regras de FQDN/Aplicação necessárias.

Regras de rede exigidas

São necessárias as seguintes regras de aplicação fQDN/ aplicação:

Ponto final de destino Protocolo Porta Utilização
ServiceTag - AzureMonitor:443 TCP 443 Este ponto final é utilizado para enviar dados de métricas e registos para Azure Monitor e Log Analytics.

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de FQDN/aplicação para os clusters AKS que tenham o Monitor Azure para contentores habilitados:

FQDN Porta Utilização
dc.services.visualstudio.com HTTPS:443 Este ponto final é utilizado para métricas e telemetria de monitorização utilizando o Azure Monitor.
*.ods.opinsights.azure.com HTTPS:443 Este ponto final é utilizado pelo Azure Monitor para ingerir dados de análise de registo.
*.oms.opinsights.azure.com HTTPS:443 Este ponto final é utilizado pelo omsagent, que é utilizado para autenticar o serviço de análise de registos.
*.monitoring.azure.com HTTPS:443 Este ponto final é utilizado para enviar dados de métricas para o Azure Monitor.

Azure Policy

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de FQDN/aplicação para clusters AKS que tenham a Azure Policy ativada.

FQDN Porta Utilização
data.policy.core.windows.net HTTPS:443 Este endereço é usado para puxar as políticas de Kubernetes e para reportar o estado de conformidade do cluster ao serviço de política.
store.policy.core.windows.net HTTPS:443 Este endereço é usado para retirar os artefactos gatekeeper de políticas incorporadas.
dc.services.visualstudio.com HTTPS:443 Azure Policy addon que envia dados de telemetria para aplicações insights ponto final.

Azure China 21Vianet Requereu regras FQDN / aplicação

São necessárias as seguintes regras de FQDN/aplicação para clusters AKS que tenham a Azure Policy ativada.

FQDN Porta Utilização
data.policy.azure.cn HTTPS:443 Este endereço é usado para puxar as políticas de Kubernetes e para reportar o estado de conformidade do cluster ao serviço de política.
store.policy.azure.cn HTTPS:443 Este endereço é usado para retirar os artefactos gatekeeper de políticas incorporadas.

Governo Azure US Exigido FQDN / regras de aplicação

São necessárias as seguintes regras de FQDN/aplicação para clusters AKS que tenham a Azure Policy ativada.

FQDN Porta Utilização
data.policy.azure.us HTTPS:443 Este endereço é usado para puxar as políticas de Kubernetes e para reportar o estado de conformidade do cluster ao serviço de política.
store.policy.azure.us HTTPS:443 Este endereço é usado para retirar os artefactos gatekeeper de políticas incorporadas.

Extensões de cluster

Regras de aplicação FQDN exigidas

São necessárias as seguintes regras de aplicação FQDN /aplicação para a utilização de extensões de cluster em clusters AKS.

FQDN Porta Utilização
<region>.dp.kubernetesconfiguration.azure.com HTTPS:443 Este endereço é utilizado para obter informações de configuração do serviço de extensões de cluster e reportar o estado de extensão do serviço.
mcr.microsoft.com, *.data.mcr.microsoft.com HTTPS:443 Este endereço é necessário para retirar imagens de contentores para instalar agentes de extensão de cluster no cluster AKS.

Governo Azure US Exigido FQDN / regras de aplicação

São necessárias as seguintes regras de aplicação FQDN /aplicação para a utilização de extensões de cluster em clusters AKS.

FQDN Porta Utilização
<region>.dp.kubernetesconfiguration.azure.us HTTPS:443 Este endereço é utilizado para obter informações de configuração do serviço de extensões de cluster e reportar o estado de extensão do serviço.
mcr.microsoft.com, *.data.mcr.microsoft.com HTTPS:443 Este endereço é necessário para retirar imagens de contentores para instalar agentes de extensão de cluster no cluster AKS.

Restringir o tráfego de saídas usando firewall Azure

Azure Firewall fornece uma Azure Kubernetes Service (AzureKubernetesService) FQDN Tag para simplificar esta configuração.

Nota

A tag FQDN contém todas as FQDNs listadas acima e é mantida automaticamente atualizada.

Recomendamos ter um mínimo de 20 IPs frontend no Azure Firewall para cenários de produção para evitar incorrer em problemas de exaustão portuária SNAT.

Abaixo está um exemplo de arquitetura da implantação:

Topologia bloqueada

  • Public Ingress é forçado a fluir através de filtros de firewall
    • Os nós de agente AKS estão isolados numa sub-rede dedicada.
    • Azure Firewall é implantado na sua própria sub-rede.
    • Uma regra de DNAT traduz o IP público FW no IP frontal LB.
  • Os pedidos de saída começam de nós de agente para o IP interno Azure Firewall usando uma rota definida pelo utilizador
    • Os pedidos dos nós de agente da AKS seguem um UDR que foi colocado na sub-rede em que o cluster AKS foi implantado.
    • Azure Firewall sai da rede virtual a partir de um frontend IP público
    • O acesso à internet pública ou a outros serviços Azure flui de e para o endereço IP frontal de firewall
    • Opcionalmente, o acesso ao plano de controlo AKS está protegido por gamas IP autorizadas do servidor API, que inclui o endereço IP frontal público de firewall.
  • Tráfego Interno

Os passos abaixo utilizam a etiqueta FQDN da AzureKubernetesService Azure Firewall para restringir o tráfego de saída do cluster AKS e fornecem um exemplo de como configurar o tráfego de entrada pública através da firewall.

Definir configuração através de variáveis de ambiente

Defina um conjunto de variáveis ambientais a serem usadas em criações de recursos.

PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"

Criar uma rede virtual com várias sub-redes

Fornecendo uma rede virtual com duas sub-redes separadas, uma para o cluster, uma para a firewall. Opcionalmente, também pode criar um para entrada de serviço interno.

Topologia de rede vazia

Criar um grupo de recursos para deter todos os recursos.

# Create Resource Group

az group create --name $RG --location $LOC

Crie uma rede virtual com duas sub-redes para hospedar o cluster AKS e o Azure Firewall. Cada um terá a sua própria sub-rede. Vamos começar com a rede AKS.

# Dedicated virtual network with AKS subnet

az network vnet create \
    --resource-group $RG \
    --name $VNET_NAME \
    --location $LOC \
    --address-prefixes 10.42.0.0/16 \
    --subnet-name $AKSSUBNET_NAME \
    --subnet-prefix 10.42.1.0/24

# Dedicated subnet for Azure Firewall (Firewall name cannot be changed)

az network vnet subnet create \
    --resource-group $RG \
    --vnet-name $VNET_NAME \
    --name $FWSUBNET_NAME \
    --address-prefix 10.42.2.0/24

Criar e criar um Azure Firewall com uma UDR

Azure Firewall regras de entrada e saída devem ser configuradas. O principal objetivo da firewall é permitir que as organizações configuram a entrada granular e as regras de tráfego para dentro e para fora do Cluster AKS.

Firewall e UDR

Importante

Se o seu cluster ou aplicação criar um grande número de ligações de saída direcionadas para o mesmo ou pequeno subconjunto de destinos, poderá necessitar de mais IPs frontend de firewall para evitar o máximo de portas por IP frontal. Para obter mais informações sobre como criar uma firewall Azure com vários IPs, consulte aqui

Crie um recurso IP público padrão SKU que será usado como o endereço frontend Azure Firewall.

az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"

Registe a pré-visualização da extensão cli para criar uma Azure Firewall.

# Install Azure Firewall preview CLI extension

az extension add --name azure-firewall

# Deploy Azure Firewall

az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true

O endereço IP criado anteriormente pode agora ser atribuído ao frontend de firewall.

Nota

A configuração do endereço IP público para o Azure Firewall pode demorar alguns minutos. Para alavancar o FQDN nas regras de rede precisamos de procuração de DNS ativado, quando ativado a firewall ouvirá na porta 53 e irá encaminhar pedidos DNS para o servidor DNS especificado acima. Isto permitirá que a firewall traduza automaticamente esse FQDN.

# Configure Firewall IP Config

az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME

Quando o comando anterior tiver sido bem sucedido, guarde o endereço IP frontal de firewall para configuração mais tarde.

# Capture Firewall IP Address for Later Use

FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIpAddress" -o tsv)

Nota

Se utilizar acesso seguro ao servidor AKS API com intervalos de endereços IP autorizados, tem de adicionar o IP público de firewall ao intervalo IP autorizado.

Crie uma UDR com um salto para Azure Firewall

O Azure liga automaticamente o tráfego entre sub-redes Azure, redes virtuais e redes no local. Se quiser alterar algum dos roteamentos padrão do Azure, fá-lo criando uma tabela de rotas.

Crie uma tabela de rotas vazia para ser associada a uma determinada sub-rede. A tabela de rotas definirá o próximo salto à medida que o Azure Firewall criado acima. Cada sub-rede pode ter zero ou uma tabela de rotas associada a si.

# Create UDR and add a route for Azure Firewall

az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP
az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet

Consulte a documentação da tabela de rotas de rede virtual sobre como pode sobrepor as rotas do sistema padrão da Azure ou adicionar rotas adicionais à tabela de rotas de uma sub-rede.

Adicionar regras de firewall

Nota

Para aplicações fora do sistema kube ou espaços de nome do sistema de gatekeeper que precisam de falar com o servidor API, é necessária uma regra adicional de rede para permitir a comunicação TCP para a porta 443 para o IP do servidor API, além de adicionar a regra de aplicação para fqdn-tag AzureKubernetesService é necessária.

Abaixo estão três regras de rede que pode usar para configurar na sua firewall, podendo precisar de adaptar estas regras com base na sua implementação. A primeira regra permite o acesso à porta 9000 via TCP. A segunda regra permite o acesso aos portos 1194 e 123 via UDP (se estiver a implantar para a Azure China 21Vianet, poderá precisar de mais). Ambas as regras só permitirão o tráfego destinado à CIDR da Região de Azure que estamos a usar, neste caso, nos EUA. Finalmente, adicionamos uma terceira regra de abertura da porta 123 à ntp.ubuntu.com FQDN via UDP (adicionar um FQDN como regra de rede é uma das características específicas de Azure Firewall, e você precisará adaptá-lo quando usar as suas próprias opções).

Depois de definir as regras de rede, também adicionaremos uma regra de aplicação usando o AzureKubernetesService que cobre todas as FQDNs necessárias acessíveis através da porta TCP 443 e porta 80.

# Add FW Network Rules

az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --action allow --priority 100
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols 'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123

# Add FW Application Rules

az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100

Consulte Azure Firewall documentação para saber mais sobre o serviço Azure Firewall.

Associe a tabela de rotas à AKS

Para associar o cluster à firewall, a sub-rede dedicada para a sub-rede do cluster deve fazer referência à tabela de rotas criada acima. A associação pode ser feita através da emissão de um comando à rede virtual que mantém o cluster e a firewall para atualizar a tabela de rotas da sub-rede do cluster.

# Associate route table with next hop to Firewall to the AKS subnet

az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME

Implementar AKS com tipo de UDR de saída para a rede existente

Agora, um cluster AKS pode ser implantado na rede virtual existente. Também usaremos o tipo userDefinedRoutingde saída , esta funcionalidade garante que qualquer tráfego de saída será forçado através da firewall e não existirão outros caminhos de saída (por padrão, o tipo de saída Balanceador de Carga poderá ser utilizado).

aks-implementar

A sub-rede-alvo a implantar é definida com a variável ambiente, $SUBNETID. Não definimos a $SUBNETID variável nos passos anteriores. Para definir o valor do ID da sub-rede, pode utilizar o seguinte comando:

SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)

Irá definir o tipo de saída para utilizar o UDR que já existe na sub-rede. Esta configuração permitirá que a AKS ignore a configuração e o provisionamento IP para o equilibrador de carga.

Importante

Para obter mais informações sobre o tipo de saída UDR, incluindo limitações, consulte a saída do tipo UDR.

Dica

Podem ser adicionadas funcionalidades adicionais à implantação do cluster, como o Cluster Privado.

A funcionalidade AKS para gamas IP autorizadas pelo servidor API pode ser adicionada para limitar o acesso do servidor API apenas ao ponto final público da firewall. A função de gama IP autorizada é denotada no diagrama como opcional. Ao permitir que a função de gama IP autorizada limite o acesso ao servidor API, as suas ferramentas de desenvolvedor devem utilizar uma caixa de salto da rede virtual da firewall ou deve adicionar todos os pontos finais do desenvolvedor à gama IP autorizada.

Criar um cluster AKS com identidades atribuídas ao sistema

Nota

A AKS criará uma identidade de kubelet atribuída ao sistema no grupo de recursos Node se não especificar a sua própria identidade gerida por kubelet.

Para o encaminhamento definido pelo utilizador (UDR), a identidade atribuída ao sistema suporta apenas o plugin de rede CNI. Porque para o plugin de rede kubelet, o cluster AKS precisa de permissão na tabela de rotas, uma vez que o fornecedor de nuvem kubernetes gere as regras.

Pode criar um cluster AKS utilizando uma identidade gerida atribuída pelo sistema com plugin de rede CNI executando o seguinte comando CLI.

az aks create -g $RG -n $AKSNAME -l $LOC \
  --node-count 3 \
  --network-plugin azure \
  --outbound-type userDefinedRouting \
  --vnet-subnet-id $SUBNETID \
  --api-server-authorized-ip-ranges $FWPUBLIC_IP

Criar um cluster AKS com identidades atribuídas ao utilizador

Criar identidades geridas atribuídas pelo utilizador

Se não tiver uma identidade gerida por um plano de controlo, pode criar executando o seguinte comando de criação de identidade az :

az identity create --name myIdentity --resource-group myResourceGroup

A saída deve assemelhar-se ao seguinte:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Se não tiver uma identidade gerida por kubelet, pode criar uma executando o seguinte comando de identidade az :

az identity create --name myKubeletIdentity --resource-group myResourceGroup

A saída deve assemelhar-se ao seguinte:

{
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", 
  "location": "westus2",
  "name": "myKubeletIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Nota

Para criar e utilizar o seu próprio VNet e tabela de rotas onde os recursos estão fora do grupo de recursos de nó de trabalhador, o CLI adicionará automaticamente a atribuição de funções. Se estiver a utilizar um modelo ARM ou outro cliente, tem de utilizar o ID principal do cluster gerido para executar uma atribuição de funções.

Criar um cluster AKS com identidades atribuídas ao utilizador

Agora pode utilizar o seguinte comando para criar o seu cluster AKS com as suas identidades existentes na sub-rede. Forneça o ID de identidade do plano de controlo através assign-identity e a identidade gerida por kubelet através de assign-kubelet-identity:

az aks create -g $RG -n $AKSNAME -l $LOC \
  --node-count 3 \
  --network-plugin kubenet \
  --outbound-type userDefinedRouting \
  --vnet-subnet-id $SUBNETID \
  --api-server-authorized-ip-ranges $FWPUBLIC_IP
  --enable-managed-identity \
  --assign-identity <identity-resource-id> \
  --assign-kubelet-identity <kubelet-identity-resource-id>

Permitir o acesso do desenvolvedor ao servidor API

Se utilizou gamas IP autorizadas para o cluster no passo anterior, deve adicionar os endereços IP de ferramentas do seu desenvolvedor à lista de clusters AKS de gamas IP aprovadas para aceder ao servidor API a partir daí. Outra opção é configurar uma caixa de salto com a ferramenta necessária dentro de uma sub-rede separada na rede virtual do Firewall.

Adicione outro endereço IP às gamas aprovadas com o seguinte comando

# Retrieve your IP address
CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)

# Add to AKS approved list
az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32

Use o comando az aks get-credentials para configurar kubectl para ligar ao seu cluster Kubernetes recém-criado.

az aks get-credentials -g $RG -n $AKSNAME

Implantar um serviço público

Pode agora começar a expor serviços e a implementar aplicações neste cluster. Neste exemplo, vamos expor um serviço público, mas também pode optar por expor um serviço interno através do equilibrador de carga interno.

DNAT de serviço público

Implemente a aplicação de aplicação de voto Azure copiando o yaml abaixo para um ficheiro chamado example.yaml.

# voting-storage-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: voting-storage
spec:
  replicas: 1
  selector:
    matchLabels:
      app: voting-storage
  template:
    metadata:
      labels:
        app: voting-storage
    spec:
      containers:
      - name: voting-storage
        image: mcr.microsoft.com/aks/samples/voting/storage:2.0
        args: ["--ignore-db-dir=lost+found"]
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 250m
            memory: 256Mi
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_ROOT_PASSWORD
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_USER
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_PASSWORD
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_DATABASE
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
---
# voting-storage-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: voting-storage-secret
type: Opaque
data:
  MYSQL_USER: ZGJ1c2Vy
  MYSQL_PASSWORD: UGFzc3dvcmQxMg==
  MYSQL_DATABASE: YXp1cmV2b3Rl
  MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==
---
# voting-storage-pv-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
# voting-storage-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: voting-storage
  labels: 
    app: voting-storage
spec:
  ports:
  - port: 3306
    name: mysql
  selector:
    app: voting-storage
---
# voting-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: voting-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: voting-app
  template:
    metadata:
      labels:
        app: voting-app
    spec:
      containers:
      - name: voting-app
        image: mcr.microsoft.com/aks/samples/voting/app:2.0
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
          name: http
        env:
        - name: MYSQL_HOST
          value: "voting-storage"
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_USER
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_PASSWORD
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_DATABASE
        - name: ANALYTICS_HOST
          value: "voting-analytics"
---
# voting-app-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: voting-app
  labels: 
    app: voting-app
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
    name: http
  selector:
    app: voting-app
---
# voting-analytics-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: voting-analytics
spec:
  replicas: 1
  selector:
    matchLabels:
      app: voting-analytics
      version: "2.0"
  template:
    metadata:
      labels:
        app: voting-analytics
        version: "2.0"
    spec:
      containers:
      - name: voting-analytics
        image: mcr.microsoft.com/aks/samples/voting/analytics:2.0
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
          name: http
        env:
        - name: MYSQL_HOST
          value: "voting-storage"
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_USER
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_PASSWORD
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: voting-storage-secret
              key: MYSQL_DATABASE
---
# voting-analytics-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: voting-analytics
  labels: 
    app: voting-analytics
spec:
  ports:
  - port: 8080
    name: http
  selector:
    app: voting-analytics

Implementar o serviço executando:

kubectl apply -f example.yaml

Adicione uma regra de DNAT a Azure Firewall

Importante

Quando utilizar Azure Firewall para restringir o tráfego de saídas e criar uma rota definida pelo utilizador (UDR) para forçar todo o tráfego de saídas, certifique-se de que cria uma regra de ADN apropriada na Firewall para permitir corretamente o tráfego de entrada. A utilização de Azure Firewall com um UDR quebra a configuração de entrada devido ao encaminhamento assimétrico. (O problema ocorre se a sub-rede AKS tiver uma rota padrão que vai para o endereço IP privado da firewall, mas está a utilizar um equilibrador de carga público - ingress ou serviço kubernetes do tipo: LoadBalancer). Neste caso, o tráfego do balançador de carga de entrada é recebido através do seu endereço IP público, mas a trajetória de retorno passa pelo endereço IP privado da firewall. Como a firewall é imponente, deixa cair o pacote de retorno porque a firewall não está ciente de uma sessão estabelecida. Para aprender a integrar Azure Firewall com o seu equilibrador de carga de entrada ou serviço, consulte Integra Azure Firewall com o Azure Balanceador de Carga Standard.

Para configurar a conectividade de entrada, uma regra de ADN deve ser escrita para o Azure Firewall. Para testar a conectividade com o seu cluster, é definida uma regra para o endereço IP público frontal de firewall para encaminhar para o IP interno exposto pelo serviço interno.

O endereço de destino pode ser personalizado, uma vez que é a porta da firewall a ser acedida. O endereço traduzido deve ser o endereço IP do balançador de carga interno. A porta traduzida deve ser a porta exposta para o seu serviço Kubernetes.

Terá de especificar o endereço IP interno atribuído ao balançador de carga criado pelo serviço Kubernetes. Recupere o endereço executando:

kubectl get services

O endereço IP necessário será listado na coluna EXTERNAL-IP, semelhante ao seguinte.

NAME               TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes         ClusterIP      10.41.0.1       <none>        443/TCP        10h
voting-analytics   ClusterIP      10.41.88.129    <none>        8080/TCP       9m
voting-app         LoadBalancer   10.41.185.82    20.39.18.6    80:32718/TCP   9m
voting-storage     ClusterIP      10.41.221.201   <none>        3306/TCP       9m

Obtenha o IP de serviço executando:

SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')

Adicione a regra NAT executando:

az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP

Validar a conectividade

Navegue para o endereço IP Azure Firewall num browser para validar a conectividade.

Você devia ver a aplicação de voto AKS. Neste exemplo, o IP público firewall foi 52.253.228.132.

A screenshot mostra a App de Voto A K S com botões para Gatos, Cães e Reset, e totais.

Limpar os recursos

Para limpar os recursos do Azure, elimine o grupo de recursos AKS.

az group delete -g $RG

Passos seguintes

Neste artigo, aprendeu quais portas e moradas para permitir se quiser restringir o tráfego de saídas para o cluster. Também viu como proteger o tráfego de saída usando Azure Firewall.

Se necessário, pode generalizar os passos acima para encaminhar o tráfego para a sua solução de saída preferida, seguindo a documentação do Tipo userDefinedRoute de Saída.

Se quiser restringir a forma como as cápsulas comunicam entre si e East-West restrições de tráfego dentro do cluster, consulte o tráfego seguro entre as cápsulas utilizando as políticas de rede em AKS.