Az Azure Firewall használata az Azure Kubernetes Service- (AKS-) fürtök védelméhez
Ez a cikk bemutatja, hogyan védheti meg az Azure Kubernetes Service-fürtöket az Azure Firewall használatával a kimenő és bejövő forgalom védelméhez.
Háttér
Az Azure Kubernetes Service (AKS) egy felügyelt Kubernetes-fürtöt kínál az Azure-ban. További információ: Azure Kubernetes Service.
Annak ellenére, hogy az AKS teljes mértékben felügyelt megoldás, nem kínál beépített megoldást a fürt és a külső hálózatok közötti bejövő és kimenő forgalom védelmére. Erre kínál megoldást az Azure Firewall.
Az AKS-fürtök virtuális hálózaton vannak üzembe helyezve. Ez a hálózat kezelhető (az AKS által létrehozott) vagy egyéni (előre konfigurált a felhasználó által előre konfigurált). A fürt mindkét esetben kimenő függőségekkel rendelkezik a virtuális hálózaton kívüli szolgáltatásoktól (a szolgáltatás nem rendelkezik bejövő függőségekkel). Felügyeleti és üzemeltetési célokra az AKS-fürtök csomópontjainak bizonyos portokhoz és teljes tartománynevekhez (FQDN-ekhez) kell hozzáférniük, amelyek ezeket a kimenő függőségeket írják le. Ez különböző függvényekhez szükséges, beleértve a Kubernetes API-kiszolgálóval kommunikáló csomópontokat is, de nem kizárólagosan. Letöltik és telepítik az alapvető Kubernetes-fürtösszetevőket és csomópontbiztonsági frissítéseket, vagy lekérik az alaprendszer tárolórendszerképeit a Microsoft Container Registryből (MCR) stb. Ezek a kimenő függőségek szinte teljes egészében FQDN-ekkel vannak definiálva, amelyek mögött nincsenek statikus címek. A statikus címek hiánya azt jelenti, hogy a hálózati biztonsági csoportok nem használhatók az AKS-fürtök kimenő forgalmának zárolására. Emiatt az AKS-fürtök alapértelmezés szerint korlátlan kimenő (kimenő) internetkapcsolattal rendelkeznek. A hálózati hozzáférés ezen szintje lehetővé teszi, hogy a futtatott csomópontok és szolgáltatások szükség szerint hozzáférjenek a külső erőforrásokhoz.
Éles környezetben azonban a Kubernetes-fürttel folytatott kommunikációt védeni kell, hogy megelőzhető legyen az adatkiszivárgás és más biztonsági rések. Az összes bejövő és kimenő hálózati forgalmat biztonsági szabályok alapján kell figyelni és szabályozni. Ha ezt szeretné, korlátoznia kell a kimenő forgalmat, de korlátozott számú portnak és címnek elérhetőnek kell maradnia ahhoz, hogy kifogástalan fürtkarbantartási feladatokat tartson fenn, és kielégítse a korábban említett kimenő függőségeket.
A legegyszerűbb megoldás egy tűzfaleszközt használ, amely tartománynevek alapján képes szabályozni a kimenő forgalmat. A tűzfal általában akadályt képez egy megbízható hálózat és egy nem megbízható hálózat, például az internet között. Az Azure Firewall például korlátozhatja a kimenő HTTP- és HTTPS-forgalmat a cél teljes tartományneve alapján, így részletes kimenő forgalomvezérlést biztosíthat, ugyanakkor lehetővé teszi az AKS-fürt kimenő függőségeit magában foglaló teljes tartománynevek elérését (ezt az NSG-k nem tehetik meg). Hasonlóképpen szabályozhatja a bejövő forgalmat, és javíthatja a biztonságot azáltal, hogy engedélyezi a fenyegetésintelligencia-alapú szűrést egy megosztott szegélyhálózaton üzembe helyezett Azure Firewallon. Ez a szűrés riasztásokat adhat meg, és megtagadhatja az ismert rosszindulatú IP-címekre és tartományokra érkező és onnan érkező forgalmat.
Abhinav Sriram alábbi videójában gyorsan áttekintheti, hogyan működik ez a gyakorlatban egy mintakörnyezetben:
A microsoft letöltőközpontból letölthet egy zip-fájlt, amely bash-szkriptfájlt és yaml-fájlt tartalmaz a videóban használt mintakörnyezet automatikus konfigurálásához. Konfigurálja az Azure Firewallt a bejövő és kimenő forgalom védelmére. Az alábbi útmutatók részletesebben ismertetik a szkript minden lépését, így egyéni konfigurációt állíthat be.
Az alábbi ábra a szkript és az útmutató által konfigurált videó mintakörnyezetét mutatja be:
Egy különbség van a szkript és az alábbi útmutató között. A szkript felügyelt identitásokat használ, de az útmutató szolgáltatásnevet használ. Ez két különböző módszert mutat be egy identitás létrehozására a fürterőforrások kezeléséhez és létrehozásához.
Kimenő forgalom korlátozása az Azure Firewall használatával
Konfiguráció beállítása környezeti változókon keresztül
Az erőforrás-létrehozásokban használandó környezeti változók halmazának meghatározása.
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"
Több alhálózattal rendelkező virtuális hálózat létrehozása
Hozzon létre egy virtuális hálózatot két különálló alhálózattal, egyet a fürthöz, egyet a tűzfalhoz. A belső szolgáltatásbejárathoz is létrehozhat egyet.
Hozzon létre egy erőforráscsoportot az összes erőforrás tárolásához.
# Create Resource Group
az group create --name $RG --location $LOC
Hozzon létre egy virtuális hálózatot két alhálózattal az AKS-fürt és az Azure Firewall üzemeltetéséhez. Mindegyiknek saját alhálózata van. Kezdjük az AKS-hálózattal.
# 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
Azure Firewall létrehozása és beállítása UDR használatával
Az Azure Firewall bejövő és kimenő szabályait konfigurálni kell. A tűzfal fő célja, hogy lehetővé tegye a szervezetek számára, hogy részletes bejövő és kimenő forgalmi szabályokat konfiguráljanak az AKS-fürtbe és onnan kifelé.
Fontos
Ha a fürt vagy alkalmazás nagy számú kimenő kapcsolatot hoz létre, amelyek ugyanahhoz a célcsoporthoz vagy kis részhalmazhoz vannak irányítva, előfordulhat, hogy több tűzfalelőtéri IP-címre van szükség, hogy elkerülje a portok frontend IP-címenkénti maximális számát. További információ a több IP-címmel rendelkező Azure-tűzfal létrehozásáról:
Hozzon létre egy standard SKU nyilvános IP-erőforrást, amelyet az Azure Firewall előtérbeli címeként használnak.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Regisztrálja az előzetes cli-bővítményt egy Azure Firewall létrehozásához.
# 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
A korábban létrehozott IP-cím mostantól hozzárendelhető a tűzfal előtéréhez.
Feljegyzés
A nyilvános IP-cím beállítása az Azure Firewallra eltarthat néhány percig. A teljes tartománynév hálózati szabályokon való kihasználásához engedélyezni kell a DNS-proxyt, ha engedélyezve van, a tűzfal figyeli az 53-at, és továbbítja a DNS-kéréseket a korábban megadott DNS-kiszolgálónak. Ez lehetővé teszi, hogy a tűzfal automatikusan lefordítsa a teljes tartománynevet.
# 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
Ha az előző parancs sikeres volt, mentse a tűzfal előtérbeli IP-címét a későbbi konfigurációhoz.
# 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)
Feljegyzés
Ha biztonságos hozzáférést használ az engedélyezett IP-címtartományokkal rendelkező AKS API-kiszolgálóhoz, hozzá kell adnia a tűzfal nyilvános IP-címét az engedélyezett IP-címtartományhoz.
UDR létrehozása ugrással az Azure Firewallra
Az Azure automatikusan irányítja a forgalmat az Azure-alhálózatok, a virtuális hálózatok és a helyszíni hálózatok között. Ha módosítani szeretné az Azure egyik alapértelmezett útválasztását, ezt egy útvonaltábla létrehozásával teheti meg.
Hozzon létre egy üres útvonaltáblát egy adott alhálózathoz társítani. Az útvonaltábla a következő ugrást a korábban létrehozott Azure Firewallként határozza meg. Mindegyik alhálózattal nulla vagy egy útvonaltábla társítható.
# 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
Tekintse meg a virtuális hálózat útvonaltáblájának dokumentációját arról, hogyan bírálhatja felül az Azure alapértelmezett rendszerútvonalait, vagy hogyan adhat hozzá további útvonalakat az alhálózat útvonaltábláihoz.
Tűzfalszabályok hozzáadása
Feljegyzés
A kube-rendszeren vagy a gatekeeper-system névtéren kívüli alkalmazások esetében, amelyeknek az API-kiszolgálóval kell beszélni, egy további hálózati szabályra van szükség, amely lehetővé teszi a TCP-kommunikációt az API-kiszolgáló IP-címéhez tartozó 443-es porton, valamint az fqdn-tag AzureKubernetesService alkalmazásszabályának hozzáadása mellett.
A tűzfal konfigurálásához az alábbi három hálózati szabályt használhatja. Előfordulhat, hogy ezeket a szabályokat az üzembe helyezés alapján kell módosítania. Az első szabály lehetővé teszi a 9000-s port tcp-en keresztüli elérését. A második szabály lehetővé teszi az 1194- és 123-as port elérését az UDP-en keresztül. Mindkét szabály csak az általunk használt Azure-régió CIDR felé irányuló forgalmat engedélyezi, ebben az esetben az USA keleti régiójába.
Végül hozzáadunk egy harmadik hálózati szabályt, amely a 123-at nyitja meg egy internetes időkiszolgáló teljes tartománynevéhez (például:ntp.ubuntu.com) az UDP-n keresztül. A teljes tartománynév hálózati szabályként való hozzáadása az Azure Firewall egyik sajátos funkciója, és a saját beállítások használatakor hozzá kell igazítania.
A hálózati szabályok beállítása után egy olyan alkalmazásszabályt is hozzáadunk, amely a AzureKubernetesService szükséges teljes tartománynevekre vonatkozik, amelyek a 443-es TCP-porton és a 80-as porton keresztül érhetők el. Emellett előfordulhat, hogy az üzembe helyezés alapján további hálózati és alkalmazásszabályokat kell konfigurálnia. További információt az Azure Kubernetes Service- (AKS-) fürtök kimenő hálózatára és teljes tartománynevére vonatkozó szabályokban talál.
FW hálózati szabályok hozzáadása
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
FW-alkalmazásszabályok hozzáadása
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
Az Azure Firewall szolgáltatással kapcsolatos további információkért tekintse meg az Azure Firewall dokumentációját .
Útvonaltábla társítása az AKS-hez
A fürt tűzfalhoz való társításához a fürt alhálózatához tartozó dedikált alhálózatnak hivatkoznia kell a korábban létrehozott útvonaltáblára. A társítás úgy végezhető el, hogy parancsot ad ki a fürt és a tűzfalat tartalmazó virtuális hálózatnak a fürt alhálózatának útvonaltáblájának frissítéséhez.
# 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
Az AKS üzembe helyezése kimenő UDR-típussal a meglévő hálózaton
Most már üzembe helyezhet egy AKS-fürtöt a meglévő virtuális hálózaton. Kimenő típust userDefinedRoutingis használ, ez a funkció biztosítja, hogy a kimenő forgalom a tűzfalon keresztül legyen kényszerítve, és nincsenek más kimenő útvonalak (alapértelmezés szerint a Load Balancer kimenő típusa használható).
A üzembe helyezendő célalhálózatot a környezeti változó határozza meg. $SUBNETID Az előző lépésekben nem definiáltuk a $SUBNETID változót. Az alhálózat-azonosító értékének beállításához használja a következő parancsot:
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)
Megadhatja a kimenő típust az alhálózaton már létező UDR használatához. Ez a konfiguráció lehetővé teszi, hogy az AKS kihagyja a terheléselosztó beállítását és IP-kiépítését.
Fontos
További információ a kimenő UDR típusról, beleértve a korlátozásokat is, lásd a kimenő kimenő UDR típust.
Tipp.
A fürt központi telepítéséhez további funkciók is hozzáadhatók, például a Privát fürt vagy az operációsrendszer-termékváltozat módosítása.
Az API-kiszolgáló által engedélyezett IP-tartományok AKS-funkciója hozzáadható, hogy az API-kiszolgáló hozzáférése csak a tűzfal nyilvános végpontjára legyen korlátozva. Az engedélyezett IP-tartományok funkció a diagramban választhatóként van jelölve. Ha engedélyezi az engedélyezett IP-tartomány funkciónak az API-kiszolgáló hozzáférésének korlátozását, a fejlesztői eszközöknek a tűzfal virtuális hálózatából származó jumpboxot kell használniuk, vagy az összes fejlesztői végpontot hozzá kell adni az engedélyezett IP-tartományhoz.
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
Feljegyzés
Ha saját virtuális hálózatát és útvonaltábláját hálózati beépülő modullal kubenet szeretné létrehozni és használni, felhasználó által hozzárendelt felügyelt identitást kell használnia. A rendszer által hozzárendelt felügyelt identitások esetében nem tudjuk lekérni az identitásazonosítót a fürt létrehozása előtt, ami késlelteti a szerepkör-hozzárendelés érvénybe lépését.
Ha saját virtuális hálózatát és útvonaltábláját hálózati beépülő modullal azure szeretné létrehozni és használni, a rendszer által hozzárendelt és a felhasználó által hozzárendelt felügyelt identitások is támogatottak.
Fejlesztői hozzáférés engedélyezése az API-kiszolgálóhoz
Ha az előző lépésben engedélyezett IP-tartományokat használt a fürthöz, hozzá kell adnia a fejlesztői eszköz IP-címeit a jóváhagyott IP-tartományok AKS-fürtlistájához, hogy onnan hozzáférjen az API-kiszolgálóhoz. Egy másik lehetőség a jumpbox konfigurálása a szükséges eszközökkel a tűzfal virtuális hálózatának egy külön alhálózatán belül.
Adjon hozzá egy másik IP-címet a jóváhagyott tartományokhoz az alábbi paranccsal
# 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
Az az aks get-credentials paranccsal konfigurálhatja kubectl az újonnan létrehozott Kubernetes-fürthöz való csatlakozást.
az aks get-credentials -g $RG -n $AKSNAME
Bejövő forgalom korlátozása az Azure Firewall használatával
Mostantól megkezdheti a szolgáltatások felfedését és az alkalmazások üzembe helyezését ebben a fürtben. Ebben a példában egy közszolgáltatást teszünk elérhetővé, de dönthet úgy is, hogy belső szolgáltatást tesz elérhetővé belső terheléselosztón keresztül.
Az Azure szavazóalkalmazás üzembe helyezéséhez másolja a következő yaml-et egy nevű example.yamlfájlba.
# 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/azuredocs/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/azuredocs/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/azuredocs/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
A szolgáltatás üzembe helyezése a következő futtatásával:
kubectl apply -f example.yaml
DNST-szabály hozzáadása az Azure Firewallhoz
Fontos
Ha az Azure Firewall használatával korlátozza a kimenő forgalmat, és létrehoz egy felhasználó által megadott útvonalat (UDR) az összes kimenő forgalom kényszerítéséhez, győződjön meg arról, hogy a tűzfalban megfelelő DNST-szabályt hoz létre a bejövő forgalom megfelelő engedélyezéséhez. Az Azure Firewall UDR-vel való használata megszakítja a bejövő forgalom beállítását az aszimmetrikus útválasztás miatt. (A probléma akkor fordul elő, ha az AKS-alhálózatnak van egy alapértelmezett útvonala, amely a tűzfal privát IP-címére kerül, de nyilvános terheléselosztót használ – bejövő vagy Kubernetes típusú szolgáltatást: LoadBalancer). Ebben az esetben a bejövő terheléselosztó-forgalom a nyilvános IP-címén keresztül érkezik, de a visszatérési útvonal a tűzfal magánhálózati IP-címén halad át. Mivel a tűzfal állapotalapú, a visszaadott csomagot elveti, mert a tűzfal nem tud egy már létrehozott munkamenetről. Ha tudni szeretné, hogyan integrálhatja az Azure Firewallt a bejövő vagy szolgáltatás terheléselosztójával, olvassa el az Azure Firewall integrálása az Azure Standard Load Balancerrel című témakört.
A bejövő kapcsolatok konfigurálásához egy DNST-szabályt kell írni az Azure Firewallba. A fürthöz való kapcsolódás teszteléséhez a tűzfal előtérbeli nyilvános IP-címére egy szabály van meghatározva, amely a belső szolgáltatás által közzétett belső IP-címre irányít.
A célcím testre szabható, mivel a tűzfalon lévő portot kell elérni. A lefordított címnek a belső terheléselosztó IP-címének kell lennie. A lefordított portnak a Kubernetes-szolgáltatás közzétett portjának kell lennie.
Meg kell adnia a Kubernetes szolgáltatás által létrehozott terheléselosztóhoz rendelt belső IP-címet. A cím lekérése a következő futtatásával:
kubectl get services
A szükséges IP-cím az EXTERNAL-IP oszlopban szerepel, az alábbiakhoz hasonlóan.
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
A szolgáltatás IP-címének lekérése a következő futtatásával:
SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Adja hozzá a NAT-szabályt a következő futtatásával:
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
A kapcsolat ellenőrzése
Lépjen az Azure Firewall előtérbeli IP-címére egy böngészőben a kapcsolat ellenőrzéséhez.
Látnia kell az AKS szavazóalkalmazást. Ebben a példában a tűzfal nyilvános IP-címe volt 52.253.228.132.
Az erőforrások eltávolítása
Az Azure-erőforrások törléséhez törölje az AKS-erőforráscsoportot.
az group delete -g $RG
Következő lépések
- További információ az Azure Kubernetes Service-ről: Az Azure Kubernetes Service (AKS) kubernetes alapfogalmai.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: