Az Azure Firewall használata az Azure Kubernetes Service-fürt (AKS) védelméhez

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

Ez az útmutató bemutatja, hogyan hozhat létre privát AKS-fürtöt küllős hálózati topológiában a Terraform és az Azure DevOps használatával. Az Azure Firewall az Azure Kubernetes Service (AKS) fürtbe irányuló és onnan érkező forgalom vizsgálatára szolgál. A fürtöt a központi virtuális hálózathoz társviszonyban lévő egy vagy több küllős virtuális hálózat üzemelteti.

Felépítés

Töltse le az architektúra Visio-fájlját.

Munkafolyamat

A Terraform-modulok egy új, négy alhálózattal rendelkező virtuális hálózat üzembe helyezésére szolgálnak:

Az AKS-fürt (AksSubnet).
Egy jump-box virtuális gép (VM) és privát végpontok (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

Az AKS-fürt egy felhasználó által definiált felügyelt identitással hoz létre további erőforrásokat, például terheléselosztókat és felügyelt lemezeket az Azure-ban. A Terraform-modulok lehetővé teszik az alábbi funkciókkal rendelkező AKS-fürt opcionális üzembe helyezését:

Az AKS-fürt a következő készletekből áll:

Olyan rendszercsomópont-készlet, amely csak kritikus rendszer podokat és szolgáltatásokat üzemeltet
Felhasználói csomópontkészlet, amely felhasználói számítási feladatokat és összetevőket üzemeltet

A virtuális gép az AKS-fürtöt üzemeltető virtuális hálózaton van üzembe helyezve. Ha privát fürtként telepíti az AKS-t, a rendszergazdák ezzel a virtuális géppel kezelhetik a fürtöt a Kubernetes parancssori eszközével. A virtuális gép rendszerindítási diagnosztikai naplóit egy Azure Storage-fiók tárolja.

Az Azure Bastion-gazdagép fokozott biztonsági SSH-kapcsolatot biztosít a jump-box virtuális géphez SSL-en keresztül. Az Azure Container Registry tárolólemezképek és -összetevők (például Helm-diagramok) létrehozására, tárolására és kezelésére szolgál.

Az architektúra tartalmaz egy Azure Firewallt, amely a bejövő és kimenő forgalom DNST-szabályokon, hálózati szabályokon és alkalmazásszabályokon keresztüli szabályozására szolgál. Emellett fenyegetésintelligencia-alapú szűréssel is védi a számítási feladatokat. Az Azure Firewall és a Bastion egy központi virtuális hálózaton van üzembe helyezve, amely a privát AKS-fürtöt üzemeltető virtuális hálózattal van társviszonyban. A rendszer egy útvonaltáblát és felhasználó által definiált útvonalakat használ a privát AKS-fürtből az Azure Firewallra irányuló kimenő forgalom átirányításához.

Megjegyzés:

Javasoljuk, hogy az Azure Firewall prémium termékváltozatát használja, mert fejlett veszélyforrások elleni védelmet nyújt.

A Key Vaultot titkos tárként használják az AKS-en futó számítási feladatok a kulcsok, tanúsítványok és titkos kódok lekéréséhez a Microsoft Entra Számítási feladat ID, a Titkos kulcsok tár CSI-illesztőprogramja vagy a Dapr segítségével. Az Azure Private Link lehetővé teszi, hogy az AKS számítási feladatai hozzáférjenek az Azure PaaS-szolgáltatásokhoz, például az Azure Key Vaulthoz a virtuális hálózat privát végpontján keresztül.

A topológia magánvégpontokat és privát DNS-zónákat tartalmaz az alábbi szolgáltatásokhoz:

Azure Blob Storage-fiók
Container Registry
Key Vault
A Kubernetes-fürt API-kiszolgálója

Virtuális hálózati kapcsolat van az AKS-fürtöt üzemeltető küllős virtuális hálózatok és a korábban ismertetett privát DNS-zónák között.

A Log Analytics-munkaterület a diagnosztikai naplók és metrikák Azure-szolgáltatásokból való gyűjtésére szolgál.

Összetevők

Az Azure Firewall egy natív felhőbeli, intelligens hálózati tűzfalbiztonsági szolgáltatás, amely fenyegetésvédelmet biztosít az Azure-ban futó felhőalapú számítási feladatokhoz. Ez egy szolgáltatott, teljesen állapotalapú tűzfal, beépített magas rendelkezésre állással és korlátlan felhőalapú skálázhatósággal. Kelet-nyugati és észak-déli forgalmi ellenőrzést is biztosít.
A Tárolóregisztrációs adatbázis egy felügyelt, privát Docker-beállításjegyzék-szolgáltatás, amely a nyílt forráskódú Docker Registry 2.0-n alapul. Az Azure tárolóregisztrációs adatbázisait használhatja a meglévő tárolófejlesztési és üzembehelyezési folyamatokkal, vagy tárolóregisztrációs feladatokkal tárolólemezképeket hozhat létre az Azure-ban.
Az Azure Kubernetes Service leegyszerűsíti a felügyelt Kubernetes-fürtök üzembe helyezését az Azure-ban a működési többletterhelés Azure-ba való kiszervezésével. Üzemeltetett Kubernetes-szolgáltatásként az Azure olyan kritikus feladatokat kezel, mint az állapotfigyelés és a karbantartás. Mivel a Kubernetes-főkiszolgálókat az Azure felügyeli, ön csak az ügynökcsomópontokat kezeli és tartja karban.
A Key Vault nagyobb biztonsággal tárolja és szabályozza az olyan titkos kulcsokhoz való hozzáférést, mint az API-kulcsok, jelszavak, tanúsítványok és titkosítási kulcsok. A Key Vault lehetővé teszi továbbá a nyilvános és privát Transport Layer Security/Secure Sockets Layer (TLS/SSL) tanúsítványok kiépítését, kezelését és üzembe helyezését az Azure-ral és a belső csatlakoztatott erőforrásokkal való használatra.
Az Azure Bastion egy teljes körűen felügyelt szolgáltatásként nyújtott platform (PaaS), amelyet a virtuális hálózaton belül épít ki. Az Azure Bastion továbbfejlesztett biztonsági távoli asztali protokollt (RDP) és Secure Shell-kapcsolatot (SSH) biztosít a virtuális hálózat virtuális gépeihez, közvetlenül az Azure Portalról TLS-en keresztül.
Az Azure Virtual Machines igény szerinti, méretezhető számítási erőforrásokat biztosít, amelyek lehetővé teszik a virtualizálás rugalmasságát.
Az Azure Virtual Network az Azure-beli magánhálózatok alapvető építőeleme. A virtuális hálózat lehetővé teszi, hogy az Azure-erőforrások (például a virtuális gépek) nagyobb biztonsággal kommunikáljanak egymással, az internettel és a helyszíni hálózatokkal. Az Azure-beli virtuális hálózat olyan, mint egy hagyományos, helyszíni hálózat, de magában foglalja az Azure-infrastruktúra előnyeit, például a méretezhetőséget, a rendelkezésre állást és az elkülönítést.
A virtuális hálózati adapterek lehetővé teszik, hogy az Azure-beli virtuális gépek kommunikáljanak az internettel, az Azure-ral és a helyszíni erőforrásokkal. Több hálózati adapterkártyát is hozzáadhat egy Azure-beli virtuális géphez, így a gyermek virtuális gépek saját dedikált hálózati adaptereszközökkel és IP-címekkel rendelkezhetnek.
Az Azure által felügyelt lemezek blokkszintű tárolóköteteket biztosítanak, amelyeket az Azure felügyel az Azure-beli virtuális gépeken. Ultralemezek, prémium szintű SSD-k, standard SSD-k és standard merevlemez-meghajtók (HDD-k) érhetők el.
A Blob Storage egy objektumtárolási megoldás a felhő számára. A Blob Storage nagy mennyiségű strukturálatlan adat tárolására van optimalizálva.
A Private Link lehetővé teszi az Azure PaaS-szolgáltatások (például a Blob Storage és a Key Vault) elérését a virtuális hálózat egy privát végpontján keresztül. Azt is használhatja, hogy hozzáférjen az Ön tulajdonában lévő vagy a Microsoft-partner által biztosított Azure-beli szolgáltatásokhoz.

Alternatívák

Az Azure Firewall helyett használhat külső tűzfalat az Azure Marketplace-ről. Ha igen, az Ön felelőssége, hogy megfelelően konfigurálja a tűzfalat az AKS-fürt bejövő és kimenő forgalmának vizsgálatára és engedélyezésére vagy letiltására.

Forgatókönyv részletei

Éles környezetben a Kubernetes-fürttel folytatott kommunikációt tűzfalnak kell védenie, amely biztonsági szabályok alapján figyeli és szabályozza a bejövő és kimenő hálózati 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.

Privát AKS-fürtöt hozhat létre küllős hálózati topológiában a Terraform és az Azure DevOps használatával. Az Azure Firewall az Azure Kubernetes Service (AKS) fürtbe irányuló és onnan érkező forgalom vizsgálatára szolgál. A fürtöt a központi virtuális hálózathoz társviszonyban lévő egy vagy több küllős virtuális hálózat üzemelteti.

Az Azure Firewall három különböző termékváltozatot támogat az ügyfél-használati esetek és beállítások széles körének kiszolgálásához:

Az Azure Firewall Premium ajánlott a rendkívül bizalmas alkalmazások, például a fizetésfeldolgozás biztonságossá tételéhez. Támogatja az olyan fejlett veszélyforrások elleni védelmet, mint a kártevők és a TLS-ellenőrzés.
Az Azure Firewall Standard a 3–7. rétegbeli tűzfalat kereső ügyfelek számára ajánlott, akiknek automatikus skálázásra van szükségük a legfeljebb 30 Gb/s csúcsforgalmi időszakok kezeléséhez. Támogatja a vállalati funkciókat, például a fenyegetésfelderítést, a DNS-proxyt, az egyéni DNS-t és a webes kategóriákat.
Az Azure Firewall Basic 250 Mbps-nál kisebb átviteli sebességű ügyfelek számára ajánlott.

Az alábbi táblázat a három Azure Firewall termékváltozat funkcióit mutatja be. További információkért tekintse meg az Azure Firewall díjszabását.

Screenshot that shows features of the three Azure Firewall SKUs

Alapértelmezés szerint az AKS-fürtök korlátlan kimenő internetkapcsolattal rendelkeznek. A hálózati hozzáférés ezen szintje lehetővé teszi, hogy az AKS-fürtben futó csomópontok és szolgáltatások szükség szerint hozzáférjenek a külső erőforrásokhoz. Ha korlátozni szeretné a kimenő forgalmat, korlátozott számú portnak és címnek elérhetőnek kell maradnia a fürt kifogástalan karbantartási feladatainak fenntartásához. A Kubernetes-fürtökről, például az AKS-ből érkező kimenő forgalom biztonságának legegyszerűbb módja egy olyan szoftveres tűzfal használata, amely tartománynevek alapján képes szabályozni a kimenő forgalmat. Az Azure Firewall a cél teljes tartományneve (FQDN) alapján korlátozhatja a kimenő HTTP- és HTTPS-forgalmat. A tűzfalat és a biztonsági szabályokat úgy is konfigurálhatja, hogy engedélyezze ezeket a szükséges portokat és címeket. További információ: A fürtcsomópontok kimenő forgalmának szabályozása az AKS-ben.

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.

Lehetséges használati esetek

Ez a forgatókönyv a Kubernetes-fürtökbe irányuló és onnan érkező bejövő és kimenő forgalom biztonságának javítását ismerteti.

Az aszimmetrikus útválasztás elkerülése

Ebben a megoldásban az Azure Firewall központi virtuális hálózaton van üzembe helyezve, a privát AKS-fürt pedig egy küllős virtuális hálózaton van üzembe helyezve. Az Azure Firewall hálózati és alkalmazásszabály-gyűjteményeket használ a kimenő forgalom szabályozásához. Ebben az esetben konfigurálnia kell az AKS-en futó bármely szolgáltatás által közzétett nyilvános végpont bejövő forgalmát, hogy az Azure Firewall által használt nyilvános IP-címek egyikén keresztül lépjen be a rendszerbe.

A csomagok a tűzfal nyilvános IP-címére érkeznek, de a privát IP-címen (az alapértelmezett útvonal használatával) visszatérnek a tűzfalhoz. Ez egy probléma. Ennek elkerülése érdekében hozzon létre egy másik felhasználó által definiált útvonalat a tűzfal nyilvános IP-címéhez, ahogyan az az alábbi ábrán látható. A tűzfal nyilvános IP-címére érkező csomagok az interneten keresztül lesznek irányítva. Ez a konfiguráció elkerüli a tűzfal privát IP-címére vezető alapértelmezett útvonalat.

Az AKS-számítási feladatok forgalmának a központi virtuális hálózat Azure Firewallra való átirányításához a következőkre van szükség:

Hozzon létre és rendeljen hozzá egy útvonaltáblát minden alhálózathoz, amely a fürt feldolgozó csomópontjait üzemelteti.
Hozzon létre egy felhasználó által megadott útvonalat a 0.0.0.0/0 CIDR-forgalom továbbításához az Azure Firewall privát IP-címére. Adja meg a Következő ugrás típushoz tartozó virtuális berendezést.

További információ : Oktatóanyag: Az Azure Firewall üzembe helyezése és konfigurálása az Azure Portal használatával.

For more information, see:

Számítási feladatok üzembe helyezése privát AKS-fürtön az Azure DevOps használatakor

Ha Az Azure DevOpsot használja, vegye figyelembe, hogy nem használhatja az Azure DevOps Microsoft által üzemeltetett ügynökeit a számítási feladatok privát AKS-fürtön való üzembe helyezéséhez. Nem férnek hozzá az API-kiszolgálóhoz. A számítási feladatok privát AKS-fürtön való üzembe helyezéséhez ki kell építenie és használnia kell egy saját üzemeltetésű Azure DevOps-ügynököt ugyanabban a virtuális hálózaton, mint a privát AKS-fürt, vagy egy társhálózaton. Az utóbbi esetben mindenképpen hozzon létre egy virtuális hálózati kapcsolatot a csomópont erőforráscsoportjában található AKS-fürt privát DNS-zónája és az Azure DevOps saját üzemeltetésű ügynököt üzemeltető virtuális hálózat között.

Egyetlen Windows - vagy Linux Azure DevOps-ügynököt helyezhet üzembe egy virtuális gépen, vagy használhat virtuálisgép-méretezési csoportot. További információ: Azure Virtual Machine Scale Set agents. Másik lehetőségként beállíthat egy saját üzemeltetésű ügynököt az Azure Pipelinesban a Windows Server Core-tárolóban (Windows-gazdagépek esetén) vagy az Ubuntu-tárolóban (Linux-gazdagépek esetén) a Dockerrel való futtatáshoz. Helyezze üzembe podként egy vagy több replikával a privát AKS-fürtben. For more information, see:

Ha a privát AKS-fürt csomópontkészleteit üzemeltető alhálózatok úgy vannak konfigurálva, hogy útvonaltáblán és felhasználó által megadott útvonalon keresztül irányítják a kimenő forgalmat egy Azure Firewallra, mindenképpen hozza létre a megfelelő alkalmazás- és hálózati szabályokat. Ezeknek a szabályoknak lehetővé kell tenniük, hogy az ügynök hozzáférjen a külső webhelyekhez, hogy olyan eszközöket töltsön le és telepítsen, mint a Docker, a Kubectl, az Azure CLI és a Helm az ügynök virtuális gépén. További információ: Saját üzemeltetésű ügynök futtatása a Dockerben , az Azure DevOps Pipeline Agent összeállítása és üzembe helyezése az AKS-ben.

Az Azure Firewall használata nyilvános Standard Load Balancer előtt

A Terraform-modulok erőforrásdefiníciói az életciklus metaargumentumával szabják testre a műveleteket, ha az Azure-erőforrásokat a Terraform-vezérlőn kívül módosítják. A ignore_changes argumentum arra utasítja a Terraformot, hogy hagyja figyelmen kívül az adott erőforrástulajdonságok( például címkék) frissítéseit. Az Azure Firewall Policy erőforrásdefiníciója egy életciklus-blokkot tartalmaz, amely megakadályozza, hogy a Terraform frissítse az erőforrást egy szabálygyűjtemény vagy egyetlen szabály létrehozásakor, frissítésekor vagy törlésekor. Hasonlóképpen, az Azure Route Table tartalmaz egy életciklus-blokkot, amely megakadályozza, hogy a Terraform felhasználó által megadott útvonal létrehozásakor, törlésekor vagy frissítésekor frissítse az erőforrást. Ez lehetővé teszi egy Azure Firewall-szabályzat DNST-, alkalmazás- és hálózati szabályainak, valamint egy Azure Route Table felhasználó által megadott útvonalainak kezelését a Terraform-vezérlőn kívül.

A jelen cikkhez társított minta egy Azure DevOps CD-folyamatot tartalmaz, amely bemutatja, hogyan helyezhet üzembe számítási feladatokat egy privát AKS-fürtön egy saját üzemeltetésű ügynökön futó Azure DevOps-folyamat használatával. A minta egy nyilvános Helm-diagram használatával telepíti a Bitnami redmine projektfelügyeleti webalkalmazást. Ez az ábra a minta hálózati topológiáját mutatja be:

Az üzenetfolyam a következő:

Az AKS által üzemeltetett webalkalmazásra vonatkozó kérelmet egy nyilvános IP-címre küldi a rendszer, amelyet az Azure Firewall nyilvános IP-konfiguráción keresztül fed le. A nyilvános IP-cím és a nyilvános IP-konfiguráció is erre a számítási feladatra van kiállítva.
Az Azure Firewall DNST-szabálya lefordítja az Azure Firewall nyilvános IP-címét és portját a csomópont erőforráscsoportjában lévő AKS-fürt Kubernetes nyilvános Standard Load Balancerjében használt számítási feladat által használt nyilvános IP-címre és portra.
A terheléselosztó elküldi a kérést az AKS-fürt egyik ügynökcsomópontján futó Kubernetes-szolgáltatás podoknak.
A válaszüzenetet a rendszer egy felhasználó által megadott útvonalon küldi vissza az eredeti hívónak. Az Azure Firewall nyilvános IP-címe a címelőtag, az internet pedig a Következő ugrás típus.
A számítási feladat által kezdeményezett kimenő hívásokat a rendszer az alapértelmezett felhasználó által megadott útvonalon irányítja át az Azure Firewall privát IP-címére. A 0.0.0.0/0 a címelőtag, a virtuális berendezés pedig a Következő ugrás típus.

További információ: Az Azure Firewall használata az AKS-fürt nyilvános standard terheléselosztója előtt.

Az Azure Firewall használata belső Standard Load Balancer előtt

A jelen cikkhez társított mintában egy ASP.NET Core-alkalmazást egy AKS-fürt üzemeltet szolgáltatásként, és egy NGINX bejövőforgalom-vezérlővel nyitható meg. Az NGINX bejövőforgalom-vezérlő egy belső terheléselosztón keresztül érhető el, amely egy privát IP-címmel rendelkezik az AKS-fürtöt üzemeltető küllős virtuális hálózaton. További információ: Bejövőforgalom-vezérlő létrehozása belső virtuális hálózathoz az AKS-ben. Ha NGINX-bejövő vezérlőt vagy általánosabb LoadBalancerClusterIP szolgáltatást helyez üzembe a service.beta.kubernetes.io/azure-load-balancer-internal: "true" metaadatok szakaszban található megjegyzéssel, létrejön egy belső standard terheléselosztó kubernetes-internal a csomópont erőforráscsoportja alatt. További információ: Belső terheléselosztó használata az AKS-sel. Az alábbi ábrán látható módon a teszt webalkalmazást az Azure Firewall egy dedikált Nyilvános Azure-IP-címen keresztül teszi közzé.

Az üzenetfolyam a következő:

A rendszer az AKS által üzemeltetett teszt webalkalmazásra vonatkozó kérelmet küld egy nyilvános IP-címre, amelyet az Azure Firewall nyilvános IP-konfiguráción keresztül tesz közzé. A nyilvános IP-cím és a nyilvános IP-konfiguráció is erre a számítási feladatra van kiállítva.
Az Azure Firewall DNST-szabálya lefordítja az Azure Firewall nyilvános IP-címét és portját arra a privát IP-címre és portra, amelyet az NGINX bejövőforgalom-vezérlő használ a csomópont erőforráscsoportjában lévő AKS-fürt belső Standard Load Balancerjében.
A kérést a belső terheléselosztó küldi az AKS-fürt egyik ügynökcsomópontján futó Kubernetes-szolgáltatás podok egyikének.
A válaszüzenetet a rendszer egy felhasználó által megadott útvonalon küldi vissza az eredeti hívónak. A 0.0.0.0/0 a címelőtag, a virtuális berendezés pedig a Következő ugrás típus.
A számítási feladat által kezdeményezett kimenő hívások a felhasználó által megadott útvonal magánhálózati IP-címére lesznek irányítva.

További információ: Az Azure Firewall használata egy belső Standard Load Balancer előtt.

Considerations

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Az alábbi szempontok közül néhány olyan általános javaslat, amely nem kifejezetten az Azure Firewall az AKS-fürtök védelmének javítására vonatkozik. Úgy gondoljuk, hogy ezek a megoldás alapvető követelményei. Ez vonatkozik a biztonságra, a teljesítményre, a rendelkezésre állásra és a megbízhatóságra, a tárolásra, a szolgáltatáshálóra és a figyelési szempontokra.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

Az Azure platform továbbfejlesztett védelmet nyújt a különböző fenyegetések, például a hálózati behatolás és az elosztott szolgáltatásmegtagadási (DDoS) támadások ellen. A nyilvános HTTPS-végpontot elérhetővé tevő AKS-alapú webalkalmazások és -szolgáltatások védelméhez webalkalmazási tűzfalat (WAF) kell használnia. Védelmet kell biztosítania az olyan gyakori fenyegetések ellen, mint az SQL-injektálás, a helyek közötti szkriptelés és más webes biztonsági rések. Ehhez használja az Open Web Application Security Project (OWASP) szabályokat és egyéni szabályokat. Az Azure Web Application Firewall továbbfejlesztett központi védelmet biztosít a webalkalmazásoknak a gyakori biztonsági résekkel és biztonsági résekkel szembeni védelmével. Az Azure WAF üzembe helyezhető a Azure-alkalmazás Gateway, az Azure Front Door és az Azure Content Delivery Network használatával.

A DDoS-támadások az egyik legnagyobb rendelkezésre állási és biztonsági problémát jelentenek azoknak a szervezeteknek, amelyek az alkalmazásaikat a felhőbe helyezik át. A DDoS-támadás megpróbálja kimeríteni az alkalmazás erőforrásait, így az alkalmazás nem érhető el a jogos felhasználók számára. A DDoS-támadásokat bármely olyan végponton meg lehet célozni, amely nyilvánosan elérhető az interneten keresztül. Az Azure minden tulajdonsága extra költségek nélkül biztosít védelmet az Azure DDoS-infrastruktúra védelmén keresztül. A globálisan üzembe helyezett Azure-hálózat mérete és kapacitása továbbfejlesztett védelmet nyújt a gyakori hálózati rétegbeli támadások ellen a folyamatos forgalomfigyelés és a valós idejű kockázatcsökkentés révén. A DDoS-infrastruktúra védelme nem igényel felhasználói konfigurációt vagy alkalmazásmódosítást. Segít megvédeni az összes Azure-szolgáltatást, beleértve a PaaS-szolgáltatásokat, például az Azure DNS-t.

Az Azure DDoS Network Protection alkalmazástervezési ajánlott eljárásokkal kombinálva továbbfejlesztett DDoS-kockázatcsökkentési funkciókat biztosít, hogy nagyobb védelmet nyújtson a DDoS-támadásokkal szemben. Az Azure DDOS Network Protectiont minden szegélyhálózaton engedélyeznie kell.

Az alábbiakban néhány további biztonsági szempontot is figyelembe kell venni:

Hozzon létre egy privát végpontot az AKS számítási feladatai által használt bármely PaaS-szolgáltatáshoz, például a Key Vaulthoz, az Azure Service Bushoz és az Azure SQL Database-hez. Az alkalmazások és a szolgáltatások közötti forgalom nem érhető el a nyilvános interneten. Az AKS-fürt virtuális hálózata és a PaaS-szolgáltatás egy privát végponton keresztüli példánya közötti forgalom a Microsoft gerinchálózatán halad át, de a kommunikáció nem halad át az Azure Firewallon. Ez a mechanizmus jobb biztonságot és jobb védelmet biztosít az adatszivárgás ellen. További információ: Mi az Azure Private Link?
Ha az Application Gatewayt az AKS-fürt előtt használja, egy webalkalmazási tűzfalszabályzattal megvédheti az AKS-en futó, nyilvánosan elérhető számítási feladatokat a támadásoktól.
A hálózati házirendek használatával elkülönítheti és biztonságossá teheti a szolgáltatáson belüli kommunikációt annak szabályozásával, hogy mely összetevők kommunikálhatnak egymással. Alapértelmezés szerint a Kubernetes-fürtök összes podja korlátozás nélkül küldhet és fogadhat forgalmat. A biztonság javítása érdekében azure-beli hálózati házirendek vagy Calico-hálózati szabályzatok használatával definiálhat olyan szabályokat, amelyek szabályozzák a különböző mikroszolgáltatások közötti forgalom áramlását. További információ: hálózati szabályzat.
Ne tegye elérhetővé az AKS-csomópontokhoz való távoli kapcsolatot. Hozzon létre egy megerősített gazdagépet vagy jump boxot egy felügyeleti virtuális hálózaton. A megerősített gazdagép használatával irányíthatja a forgalmat az AKS-fürtbe.
Fontolja meg egy privát AKS-fürt használatát az éles környezetben, vagy legalább biztonságos hozzáférést az API-kiszolgálóhoz az engedélyezett IP-címtartományok használatával az AKS-ben. Ha engedélyezett IP-címtartományokat használ egy nyilvános fürtön, engedélyezze az Összes kimenő IP-címet az Azure Firewall hálózati szabálygyűjteményében. A fürtön belüli műveletek a Kubernetes API-kiszolgálót használják.
Ha engedélyezi a DNS-proxyt az Azure Firewallban, az Azure Firewall feldolgozhatja és továbbíthatja a DNS-lekérdezéseket egy vagy több virtuális hálózatból egy ön által választott DNS-kiszolgálóra. Ez a funkció kulcsfontosságú és szükséges a hálózati szabályok megbízható teljes tartománynév-szűréséhez. Engedélyezheti a DNS-proxyt az Azure Firewall és a tűzfalszabályzat beállításaiban. A DNS-proxynaplókkal kapcsolatos további információkért tekintse meg az Azure Firewall naplóit és metrikáit.
Amikor az Azure Firewallt az Application Gateway előtt használja, konfigurálhatja a Kubernetes bejövő erőforrását a számítási feladatok HTTPS-en keresztüli felfedésére, és minden bérlőhöz külön altartományt és digitális tanúsítványt használhat. Az Application Gateway bejövőforgalom-vezérlője (AGIC) automatikusan konfigurálja az Application Gateway figyelőt a Secure Sockets Layer (SSL) leállításához.
Az Azure Firewallt olyan szolgáltatásproxy előtt használhatja, mint az NGINX bejövőforgalom-vezérlő. Ez a vezérlő fordított proxyt, konfigurálható forgalomirányítást és TLS-lezárást biztosít a Kubernetes-szolgáltatásokhoz. A Kubernetes bemeneti erőforrásainak használatával konfigurálhatók az egyes Kubernetes-szolgáltatásokhoz tartozó bejövő szabályok és útvonalak. Bejövőforgalom-vezérlő és bejövő szabályok használatával egyetlen IP-címmel irányíthatja a forgalmat egy Kubernetes-fürt több szolgáltatásához. A TLS-tanúsítványokat egy elismert hitelesítésszolgáltatóval hozhatja létre. Másik lehetőségként a Let's Encryption használatával automatikusan létrehozhat TLS-tanúsítványokat dinamikus nyilvános IP-címmel vagy statikus nyilvános IP-címmel. További információ: HTTPS bejövőforgalom-vezérlő létrehozása és saját TLS-tanúsítványok használata az AKS-en.
Az Azure Firewall-operátor, valamint a fürt- és számítási feladatok csapatainak szigorú koordinációja szükséges mind a fürt kezdeti üzembe helyezéséhez, mind pedig a számítási feladatok és a fürt igényeinek folyamatos fejlődéséhez. Ez különösen igaz, ha olyan hitelesítési mechanizmusokat konfigurál, mint az OAuth 2.0 és az OpenID Csatlakozás, amelyeket a számítási feladatok használnak az ügyfelek hitelesítéséhez.
A cikkben ismertetett környezet védelméhez használja az alábbi irányelveket:

Rendelkezésre állás és megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: A megbízhatósági pillér áttekintése.

A rendelkezésre állási és megbízhatósági szempontok itt nem az AKS-ben való több-bérlősségre vonatkoznak. Úgy gondoljuk, hogy ezek a megoldás alapvető követelményei. Fontolja meg az alábbi módszereket az AKS-fürt és a számítási feladatok rendelkezésre állásának optimalizálásához.

Régión belüli rugalmasság

Az üzembe helyezés során úgy konfigurálhatja az Azure Firewallt , hogy több rendelkezésre állási zónára is kiterjedjen a nagyobb rendelkezésre állás érdekében. Az üzemidő százalékos arányát az Azure Firewall SLA-jában talál. Az Azure Firewallt egy adott zónához is társíthatja a közelség érdekében, bár ez a konfiguráció hatással van az SLA-ra. A rendelkezésre állási zónában üzembe helyezett tűzfalnak nincs többletköltsége. A rendelkezésre állási zónákhoz társított bejövő és kimenő adatátvitelek azonban további költségekkel járnak. További információ: Sávszélesség díjszabásának részletei.
Fontolja meg az AKS-fürt csomópontkészleteinek üzembe helyezését egy régió összes rendelkezésre állási zónájában . Használjon egy Azure Standard Load Balancert vagy Application Gatewayt a csomópontkészletek előtt. Ez a topológia nagyobb rugalmasságot biztosít egyetlen adatközpont-kimaradás esetén. A fürtcsomópontok több adatközpontban vannak elosztva, egy régió három különálló rendelkezésre állási zónájában.
Zónaredundancia engedélyezése a Container Registryben a régión belüli rugalmasság és a magas rendelkezésre állás érdekében.
Podtopológiapárzási korlátozások használatával szabályozhatja, hogy a podok hogyan oszlanak el az AKS-fürtön a hibatartományok, például régiók, rendelkezésre állási zónák és csomópontok között.
Fontolja meg a kritikus fontosságú számítási feladatokat üzemeltető AKS-fürtök üzemidejű SLA-jának használatát. Az üzemidejű SLA egy választható funkció, amely lehetővé teszi egy pénzügyileg támogatott, magasabb szintű SLA-t a fürtök számára. Az üzemidejű SLA garantálja a Kubernetes API-kiszolgálóvégpont magas rendelkezésre állását a rendelkezésre állási zónákat használó fürtök számára. Olyan fürtökhöz is használhatja, amelyek nem használnak rendelkezésre állási zónákat, de az SLA alacsonyabb. Az SLA részleteiért lásd az Uptime SLA-t. Az AKS főcsomópont-replikákat használ a frissítési és a tartalék tartományokhoz, így biztosítva az SLA-követelményeknek való megfelelőséget.

Vészhelyreállítás és üzletmenet-folytonosság

Fontolja meg a megoldás üzembe helyezését legalább két párosított Azure-régióban egy földrajzi helyen. Az üzletmenet folytonosságának és vészhelyreállításának (DR) garantálásához használjon egy globális terheléselosztót, például az Azure Traffic Managert vagy az Azure Front Doort egy aktív/aktív vagy aktív/passzív útválasztási módszerrel.
Az Azure Firewall egy regionális szolgáltatás. Ha a megoldást két vagy több régióban helyezi üzembe, minden régióban létre kell hoznia egy Azure-tűzfalat. Létrehozhat egy globális Azure Firewall-szabályzatot, amely tartalmazza az összes regionális központra vonatkozó, szervezetre vonatkozó szabályokat. Ezt a szabályzatot szülőszabályzatként használhatja a regionális Azure-szabályzatokhoz. A nem üres szülőszabályzatokkal létrehozott házirendek a szülőházirend összes szabálygyűjteményét öröklik. A szülőházirendtől örökölt hálózati szabálygyűjtemények mindig elsőbbséget kapnak az új szabályzat részeként definiált hálózati szabálygyűjtemények felett. Ugyanez a logika vonatkozik az alkalmazásszabály-gyűjteményekre is. A hálózati szabálygyűjtemények feldolgozása azonban mindig az alkalmazásszabály-gyűjtemények előtt történik, az örökléstől függetlenül. A Standard és a Premium szabályzatokkal kapcsolatos további információkért tekintse meg az Azure Firewall Manager szabályzatainak áttekintését.
Ügyeljen arra, hogy minőségbiztosítási környezetben minden regionális feladatátvételi folyamatot szkripteljen, dokumentáljon és rendszeres időközönként teszteljen. Ez segít elkerülni a kiszámíthatatlan problémákat, ha az elsődleges régióban kimaradás érint egy alapszolgáltatást. Ezek a tesztek azt is ellenőrzik, hogy a dr. megközelítés megfelel-e az RPO/RTO-céloknak, a feladatátvételhez szükséges manuális folyamatokkal és beavatkozásokkal együtt.
Mindenképpen tesztelje a feladat-visszavételi eljárásokat annak ellenőrzéséhez, hogy a várt módon működnek-e.
Tárolja a tárolólemezképeket a Container Registryben. A beállításjegyzék georeplikációs replikálása minden AKS-régióba. További információ: Georeplikálás az Azure Container Registryben.
Ha lehetséges, kerülje a szolgáltatásállapot tárolóban való tárolását. Ehelyett használjon olyan Azure PaaS-t, amely támogatja a többrégiós replikációt.
Ha az Azure Storage-t használja, készítsen elő és teszteljen egy folyamatot a tároló elsődleges régióból a biztonsági mentési régióba való migrálásához.

Működés eredményessége

Az üzemeltetési kiválóság azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben tartják azt. További információ: A működési kiválósági pillér áttekintése.

DevOps

Helyezze üzembe a számítási feladatokat az AKS-ben egy Helm-diagram használatával egy folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatban. Használjon olyan DevOps-rendszert, mint a GitHub Actions vagy az Azure DevOps. További információ: Build and Deploy to Azure Kubernetes Service.
Egy alkalmazás megfelelő teszteléséhez, mielőtt elérhetővé teszi a felhasználók számára, használja az A/B tesztelést és a kanári-telepítéseket az alkalmazás életciklus-felügyeletében. Több módszer is használható a forgalom felosztására ugyanazon szolgáltatás különböző verziói között. Alternatív megoldásként használhatja a szolgáltatásháló-implementáció által biztosított forgalomelosztó képességeket. További információ: Linkerd Traffic Split és Istio Traffic Management.
Az Azure Container Registry vagy egy másik tárolóregisztrációs adatbázis (például Docker Hub) használatával tárolja a fürtön üzembe helyezett privát Docker-rendszerképeket. Az AKS a Microsoft Entra-identitásával hitelesítheti az Azure Container Registryt.
Az éles környezet hálózati topológiáját és tűzfalszabályait tükröző, külön éles környezetben tesztelheti a bejövő és kimenő forgalmat a számítási feladatokon. A szakaszos bevezetési stratégia segít észlelni a hálózati vagy biztonsági problémákat, mielőtt új funkciót vagy hálózati szabályt ad ki éles környezetben.

Figyelés

Az Azure Firewall teljes mértékben integrálva van az Azure Monitorral a tűzfal által feldolgozott bejövő és kimenő forgalom naplózásához. További információ: Azure Firewall fenyegetésintelligencia-alapú szűrés.

Az alábbi monitorozási szempontok nem az AKS-ben való több-bérlősségre vonatkoznak, de úgy gondoljuk, hogy ezek a megoldás alapvető követelményei.

A Container Insights használatával monitorozza az AKS-fürt és a számítási feladatok állapotát.
Konfigurálja az összes PaaS-szolgáltatást (például a Container Registryt és a Key Vaultot) a diagnosztikai naplók és metrikák gyűjtéséhez.

Költségoptimalizálás

Az eredményként kapott architektúra költsége a következő konfigurációs részletektől függ:

Service tiers
Méretezhetőség (azon példányok száma, amelyeket a szolgáltatások dinamikusan osztanak ki egy adott igény támogatására)
Automation-parancsprogramok
A vészhelyreállítás szintje

A konfiguráció részleteinek kiértékelése után az Azure díjszabási kalkulátorával megbecsülheti a költségeket. További díjszabásoptimalizálási lehetőségekért tekintse meg a költségoptimalizálás alapelveit a Microsoft Azure Well-Architected Frameworkben.

A forgatókönyv üzembe helyezése

A forgatókönyv forráskódja a GitHubon érhető el. Ez a megoldás nyílt forráskód és MIT-licenccel rendelkezik.

Előfeltételek

Online üzembe helyezéshez Azure-fiókra van szükség. Ha nem rendelkezik ilyen fiókkal, a kezdés előtt hozzon létre egy ingyenes Azure-fiókot . Az Azure DevOps használatával a Terraform-modulok üzembe helyezése előtt meg kell felelnie ezeknek a követelményeknek:

Tárolja a Terraform-állapotfájlt egy Azure Storage-fiókban. A távoli Terraform-állapot, az állapotzárolás és a titkosítás inaktív állapotának tárfiók használatával történő tárolásáról további információt a Terraform-állapot tárolása az Azure Storage-ban című témakörben talál.
Azure DevOps-projekt létrehozása. További információ: Projekt létrehozása az Azure DevOpsban.
Azure DevOps-szolgáltatáskapcsolat létrehozása az Azure-előfizetéshez. A szolgáltatáskapcsolat létrehozásakor használhatja a szolgáltatásnév-hitelesítést (SPA) vagy egy Azure-beli felügyeltszolgáltatás-identitást. Mindkét esetben győződjön meg arról, hogy az Azure DevOps által az Azure-előfizetéshez való csatlakozáshoz használt szolgáltatásnév vagy felügyelt identitás a teljes előfizetés tulajdonosi szerepköréhez van rendelve.

Üzembe helyezés az Azure-ban

Az Azure-előfizetés adatainak használata.

Klónozza a workbench GitHub-adattárat:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Kövesse a README.md fájlban megadott utasításokat.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Paolo Salvatori | Főszolgáltatás-mérnök

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

További lépések

Tekintse át az AKS-sel kapcsolatos javaslatokat és ajánlott eljárásokat a Microsoft Azure Well-Architected Frameworkben:

Az Azure Firewall használata az Azure Kubernetes Service-fürt (AKS) védelméhez