Restreindre le trafic de sortie provenant des clusters Big Data SQL Server 2019 dans un cluster privé Azure Kubernetes Service (AKS)
Important
Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.
Vous pouvez restreindre le trafic de sortie provenant des clusters Big Data avec Azure Kubernetes Service (AKS). Le service provisionne une référence SKU Standard Load Balancer. Cette configuration est utilisée par défaut pour la sortie. La configuration par défaut peut parfois ne pas remplir toutes les exigences, ni être adaptée à tous les scénarios. Cela arrive, par exemple, si les adresses IP publiques ne sont pas autorisées ou si des tronçons supplémentaires sont nécessaires pour la sortie. Vous pouvez définir une table de routes définies par l’utilisateur (UDR) si le cluster n’autorise pas les adresses IP publiques et se trouve derrière une appliance virtuelle réseau (NVA).
Les clusters AKS ont un accès sortant (egress) à Internet illimité. Cela répond à des besoins de gestion et opérationnels. Les nœuds Worker dans un cluster AKS doivent pouvoir accéder à certains ports et noms de domaine complets (FQDN). En voici des exemples :
- Quand le cluster doit tirer (pull) les images conteneurs système de base de Microsoft Container Registry (MCR) durant les mises à jour de sécurité système des nœuds Worker.
- Quand les nœuds Worker AKS avec GPU activé doivent accéder aux points de terminaison de Nvidia pour installer un pilote.
- Quand les clients utilisent AKS conjointement avec des services Azure, comme Azure Policy pour la conformité de l’entreprise ou Azure Monitor (avec Container Insights).
- Quand un espace de développement ou d’autres scénarios similaires sont activés.
Notes
Lorsque vous déployez un cluster Big Data (BDC) dans un cluster privé Azure Kubernetes Service (AKS), il n’y a pas de dépendances entrantes, à l’exception de celles mentionnées dans cet article. Vous trouverez toutes les dépendances sortantes dans Contrôler le trafic de sortie pour les nœuds de cluster dans Azure Kubernetes Service (AKS).
Cet article explique comment déployer des clusters Big Data dans un cluster privé AKS avec une mise en réseau avancée et le routage UDR. Il explore également l’intégration plus étroite des clusters Big Data aux environnements réseau de niveau entreprise.
Comment restreindre le trafic de sortie à l’aide du Pare-feu Azure
Le Pare-feu Azure fournit une étiquette FQDN Azure Kubernetes Service (AzureKubernetesService) pour simplifier la configuration.
Pour obtenir des informations complètes sur l’étiquette FQDN, consultez Limitation du trafic de sortie à l’aide du Pare-feu Azure.
L’illustration suivante montre comment le trafic est limité sur un cluster privé AKS.
Développez l’architecture de base pour un cluster Big Data avec le Pare-feu Azure :
- Créer le groupe de ressources et le réseau virtuel
- Créer et configurer le pare-feu Azure
- Créer une table d’itinéraires définie par l’utilisateur
- Configurer des règles de pare-feu
- Créer un principal du service (SP)
- Créer un cluster privé AKS
- Créer un profil de déploiement de BDC
- Déployer un BDC
Créer le groupe de ressources et le réseau virtuel
Définissez un ensemble de variables d’environnement pour créer des ressources.
export REGION_NAME=<region> export RESOURCE_GROUP=private-bdc-aksudr-rg export SUBNET_NAME=aks-subnet export VNET_NAME=bdc-vnet export AKS_NAME=bdcaksprivateclusterCréer le groupe de ressources
az group create -n $RESOURCE_GROUP -l $REGION_NAMECréer le réseau virtuel
az network vnet create \ --resource-group $RESOURCE_GROUP \ --location $REGION_NAME \ --name $VNET_NAME \ --address-prefixes 10.0.0.0/8 \ --subnet-name $SUBNET_NAME \ --subnet-prefix 10.1.0.0/16 SUBNET_ID=$(az network vnet subnet show \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_NAME \ --query id -o tsv)
Créer et configurer un pare-feu Azure
Définissez un ensemble de variables d’environnement pour la création de ressources.
export FWNAME=bdcaksazfw export FWPUBIP=$FWNAME-ip export FWIPCONFIG_NAME=$FWNAME-config az extension add --name azure-firewallCréer un sous-réseau dédié pour le pare-feu
Notes
Vous ne pouvez pas changer le nom du pare-feu après sa création
az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name AzureFirewallSubnet \ --address-prefix 10.3.0.0/24 az network firewall create -g $RESOURCE_GROUP -n $FWNAME -l $REGION_NAME --enable-dns-proxy true az network public-ip create -g $RESOURCE_GROUP -n $FWPUBIP -l $REGION_NAME --sku "Standard" az network firewall ip-config create -g $RESOURCE_GROUP -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBIP --vnet-name $VNET_NAME
Azure achemine automatiquement le trafic entre les sous-réseaux, les réseaux virtuels et les réseaux locaux Azure.
Comment créer une table de routes définies par l’utilisateur (UDR)
Vous pouvez créer une table UDR avec un tronçon vers le Pare-feu Azure.
export SUBID= <your Azure subscription ID>
export FWROUTE_TABLE_NAME=bdcaks-rt
export FWROUTE_NAME=bdcaksroute
export FWROUTE_NAME_INTERNET=bdcaksrouteinet
export FWPUBLIC_IP=$(az network public-ip show -g $RESOURCE_GROUP -n $FWPUBIP --query "ipAddress" -o tsv)
export FWPRIVATE_IP=$(az network firewall show -g $RESOURCE_GROUP -n $FWNAME --query "ipConfigurations[0].privateIpAddress" -o tsv)
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RESOURCE_GROUP --name $FWROUTE_TABLE_NAME
az network route-table route create -g $RESOURCE_GROUP --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 --subscription $SUBID
az network route-table route create -g $RESOURCE_GROUP --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet
Comment définir les règles de pare-feu
# Add FW Network Rules
az network firewall network-rule create -g $RESOURCE_GROUP -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$REGION_NAME" --destination-ports 1194 --action allow --priority 100
az network firewall network-rule create -g $RESOURCE_GROUP -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$REGION_NAME" --destination-ports 9000
az network firewall network-rule create -g $RESOURCE_GROUP -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 $RESOURCE_GROUP -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
Vous pouvez associer une table UDR à un cluster AKS où vous avez précédemment déployé un cluster Big Data, en utilisant la commande suivante :
az network vnet subnet update -g $RESOURCE_GROUP --vnet-name $VNET_NAME --name $SUBNET_NAME --route-table $FWROUTE_TABLE_NAME
Créer et configurer le principal de service (SP)
Au cours de cette étape, vous devez créer le principal de service et attribuer une autorisation au réseau virtuel.
Voir l’exemple suivant :
# Create SP and Assign Permission to Virtual Network
az ad sp create-for-rbac -n "bdcaks-sp"
APPID=<your service principal ID >
PASSWORD=< your service principal password >
VNETID=$(az network vnet show -g $RESOURCE_GROUP --name $VNET_NAME --query id -o tsv)
# Assign SP Permission to VNET
az role assignment create --assignee $APPID --scope $VNETID --role "Network Contributor"
RTID=$(az network route-table show -g $RESOURCE_GROUP -n $FWROUTE_TABLE_NAME --query id -o tsv)
az role assignment create --assignee $APPID --scope $RTID --role "Network Contributor"
Créer un cluster AKS
Vous pouvez maintenant créer le cluster AKS avec userDefinedRouting comme type sortant.
az aks create \
--resource-group $RESOURCE_GROUP \
--location $REGION_NAME \
--name $AKS_NAME \
--load-balancer-sku standard \
--outbound-type userDefinedRouting \
--enable-private-cluster \
--network-plugin azure \
--vnet-subnet-id $SUBNET_ID \
--docker-bridge-address 172.17.0.1/16 \
--dns-service-ip 10.2.0.10 \
--service-cidr 10.2.0.0/24 \
--service-principal $APPID \
--client-secret $PASSWORD \
--node-vm-size Standard_D13_v2 \
--node-count 2 \
--generate-ssh-keys
Créer un profil de déploiement d’un cluster Big Data
Vous pouvez créer un cluster Big Data avec un profil personnalisé :
azdata bdc config init --source aks-dev-test --target private-bdc-aks --force
Générer et configurer un profil de déploiement personnalisé d’un BDC
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.docker.imageTag=2019-CU6-ubuntu-16.04"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.storage.data.className=default"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.storage.logs.className=default"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.endpoints[1].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.master.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].serviceType=NodePort"
Déployer un cluster Big Data dans un cluster privé AKS
export AZDATA_USERNAME=<your bdcadmin username>
export AZDATA_PASSWORD=< your bdcadmin password>
azdata bdc create --config-profile private-bdc-aks --accept-eula yes
Puis-je utiliser des pare-feu tiers pour restreindre le trafic de sortie ?
Vous pouvez utiliser des pare-feu tiers pour restreindre le trafic de sortie avec un cluster Big Data et un cluster privé AKS déployés. Pour voir un exemple, consultez Pare-feu dans la Place de marché Azure. Les pare-feu tiers peuvent être utilisés dans des solutions de déploiement privées avec des configurations plus conformes. Le pare-feu doit fournir les règles de réseau suivantes :
- Les règles de réseau sortantes et noms FQDN requis pour les clusters AKS. Cette URL inclut également tous les points de terminaison et dépendances HTTP/HTTPS avec des caractères génériques. Ceux-ci peuvent varier avec votre cluster AKS selon le nombre de qualificateurs et vos exigences actuelles.
- Les règles de réseau/noms de domaine complet/règles d’application obligatoires pour Azure Global, comme indiqué ici.
- Règles de nom FQDN/d’application facultatives mais recommandées pour les clusters AKS mentionnées ici.
Vérifiez comment gérer un cluster Big Data dans un cluster privé AKS, et passez à l’étape suivante pour vous connecter au cluster Big Data.
Consultez les scripts d’automatisation pour ce scénario dans le Référentiel d’exemples SQL Server sur GitHub.