Felkészülés az Amazon Web Services (AWS) webalkalmazás számítási feladatainak üzembe helyezésére az Azure-ban

Ez a cikk átfogó útmutatót nyújt egy robusztus és éles üzemre kész infrastruktúra üzembe helyezéséről egy webalkalmazás üzemeltetésének, védelmének, skálázásának és monitorozásának megkönnyítése érdekében az Azure-platformon.

Yelb-üzembe helyezés az AWS-en

Az AWS-en található Yelb-minta webalkalmazás a Bash, az AWS CLI, az eksctl, a kubectl és a Helm használatával van üzembe helyezve. A társminta Bash-szkripteket és YAML-jegyzékeket tartalmaz, amelyekkel automatizálható a Yelb-alkalmazás üzembe helyezése az AWS Elastic Kubernetes Service-ben (EKS). Ez a megoldás bemutatja, hogyan implementálhat egy webalkalmazási tűzfalat az AWS WAF használatával az Amazon Elastic Kubernetes Service -en (EKS) futó webalkalmazások védelmére. A Bash-szkriptekkel EKS-fürtöt hozhat létre, és üzembe helyezheti a Yelb-alkalmazást . A Yelb-webalkalmazás egy Amazon Application Load Balancer (ALB) használatával érhető el a nyilvános interneten, és AWS WAF webes hozzáférés-vezérlési listával (webes ACL) van védve. Részletes útmutatásért lásd: Webalkalmazás portolása az AWS Elastic Kubernetes Service-ből (EKS) az Azure Kubernetes Service-be (AKS).

Képernyőkép a Yelb szolgáltatás felületéről.

Yelb-üzembe helyezés az Azure-ban

A következő szakaszokban megtudhatja, hogyan helyezheti üzembe a Yelb példa webalkalmazást egy Azure Kubernetes Service-fürtön (AKS), és hogyan teheti elérhetővé egy ingress vezérlőn, például az NGINX ingress vezérlőn keresztül. A bejövőforgalom-vezérlő szolgáltatás egy belső (vagy privát) terheléselosztón keresztül érhető el, amely az AKS-fürtöt befogadó virtuális hálózaton belüli forgalmat egyensúlyozza. Hibrid forgatókönyv esetén a terheléselosztó előtere egy helyszíni hálózatról érhető el. A belső terheléselosztással kapcsolatos további információkért lásd: Belső terheléselosztó használata az Azure Kubernetes Service-lel (AKS).

A társminta támogatja a felügyelt NGINX bejövőforgalom-vezérlő telepítését az alkalmazás útválasztási bővítményével vagy egy nem felügyelt NGINX bejövő vezérlővel a Helm-diagram használatával. Az NGINX bejövőforgalom-vezérlővel rendelkező alkalmazás-útválasztási bővítmény a következő funkciókat biztosítja:

Egyéb konfigurációk esetén:

A biztonság növelése érdekében a Yelb-alkalmazást egy Azure Application Gateway-erőforrás védi. Ez az erőforrás egy dedikált alhálózaton kerül üzembe helyezésre az AKS fürttel azonos virtuális hálózaton belül, vagy egy társított virtuális hálózaton. Az Azure Web Application Firewall (WAF) biztosítja az Azure Kubernetes Service (AKS) szolgáltatásban üzemeltetett webalkalmazáshoz való hozzáférést, és az Azure Application Gatewayen keresztül teszi elérhetővé a gyakori biztonsági rések és biztonsági rések ellen.

Előfeltételek

Építészet

Ez a minta Bicep-sablonok , Bash-szkriptek és YAML-jegyzékek gyűjteményét tartalmazza egy AKS-fürt létrehozásához, a Yelb-alkalmazás üzembe helyezéséhez, a felhasználói felületI szolgáltatás NGINX bejövőforgalom-vezérlővel való felfedéséhez és az Azure Application Gateway és az Azure Web Application Firewall (WAF) védelméhez.

Ez a minta két különálló Bicep-paraméterfájlt és két Bash-szkriptet és YAML-jegyzékfájlt is tartalmaz, mindegyik két különböző megoldási lehetőség üzembe helyezésére irányul. További információ a Bicep-ről: Mi a Bicep?

TLS-megszakítás az Application Gatewayen és a Yelb-hívás http-n keresztül

Ebben a megoldásban az Azure Web Application Firewall (WAF) biztosítja a rendszer biztonságát a rosszindulatú támadások blokkolásával. Az Azure Application Gateway fogadja a bejövő hívásokat az ügyfélalkalmazásoktól, TLS-leállítást hajt végre, és továbbítja a kéréseket az AKS által üzemeltetett yelb-ui szolgáltatásnak. Ez a kommunikáció a belső terheléselosztóval és az NGINX bejövőforgalom-vezérlővel érhető el a HTTP átviteli protokoll használatával. Az alábbi ábra az architektúrát szemlélteti:

Az Application Gateway WAFv2 és NGINX bejövőforgalom-vezérlőjén alapuló megoldás ábrája HTTP-n keresztül.

Az üzenetfolyam a következő:

A megoldás üzenetfolyamának diagramja az Application Gateway WAFv2 és NGINX bejövőforgalom-vezérlője alapján HTTP-n keresztül.

  1. Az Azure Application Gateway kezeli a TLS leállítását, és http-en keresztül küld bejövő hívásokat az AKS által üzemeltetett yelb-ui szolgáltatásnak.
  2. Az Application Gateway-figyelő az Azure Key Vaultból beszerzett SSL-tanúsítványt használ a biztonságos kommunikáció biztosításához.
  3. A Figyelőhöz társított Azure WAF-szabályzat OWASP-szabályokat és egyéni szabályokat alkalmaz a bejövő kérelmekre, így hatékonyan megakadályozza a rosszindulatú támadások számos típusát.
  4. Az Application Gateway háttérbeli HTTP-beállításai http-en keresztül hívják meg a Yelb-alkalmazást a 80-os porton keresztül.
  5. Az Application Gateway háttérkészlete és állapotmintája az AKS belső terheléselosztóján keresztül az NGINX vezérlőt hívja meg a forgalomkezeléshez használt HTTP protokollt alkalmazva.
  6. Az NGINX bejövőforgalom-vezérlő az AKS belső terheléselosztójának használatával biztosítja a fürtön belüli biztonságos kommunikációt.
  7. Egy Kubernetes bejövő objektum az NGINX bejövőforgalom-vezérlővel teszi elérhetővé az alkalmazást HTTP-n keresztül a belső terheléselosztón keresztül.
  8. A yelb-ui típussal rendelkező ClusterIP szolgáltatás a fürtön belül vagy az NGINX bejövőforgalom-vezérlőn keresztül korlátozza a hívását.

Végpontok közötti TLS implementálása az Azure Application Gateway használatával

TLS-visszafejtés

Az Azure Application Gateway támogatja a TLS-leállítást az átjáró szintjén, ami azt jelenti, hogy a rendszer visszafejti a forgalmat az átjárón, mielőtt a háttérkiszolgálókra küldené őket. A TLS-megszakítás konfigurálásához TLS-/SSL-tanúsítványt kell hozzáadnia a figyelőhöz. A tanúsítványnak személyes adatcsere (PFX) formátumban kell lennie, amely tartalmazza a titkos és a nyilvános kulcsokat is. Importálhatja a tanúsítványt az Azure Key Vaultból az Application Gatewaybe. További információért lásd a Key Vault tanúsítványokkal való TLS-megszakításról szóló részt.

Nulla megbízhatósági biztonsági modell

Ha nulla megbízhatóságú biztonsági modellt vezet be, meg kell akadályoznia a titkosítatlan kommunikációt egy szolgáltatásproxy, például az Azure Application Gateway és a háttérkiszolgálók között. A nulla megbízhatósági biztonsági modell esetében a rendszer nem biztosít automatikusan megbízhatóságot a hálózaton belüli erőforrásokhoz hozzáférni próbáló felhasználók vagy eszközök számára. Ehelyett az identitás és az engedélyezés folyamatos ellenőrzését igényli minden egyes kéréshez, függetlenül a felhasználó helyétől vagy hálózatától. A mi esetünkben a zéró megbízhatóságú biztonsági modell megvalósítása az Azure Application Gateway szolgáltatásproxyként való használatát jelenti, amely a bejövő kérések előtérként szolgálnak. Ezek a kérések ezután titkosított formátumban jutnak el az Azure Kubernetes Service (AKS) NGINX bejövőforgalom-vezérlője felé.

Végpontok közötti TLS az Application Gateway használatával

Nulla megbízhatósági megközelítés implementálható az Azure Application Gateway teljes körű TLS-titkosításhoz való konfigurálásával a háttérkiszolgálókkal. A végpontok közötti TLS-titkosítás lehetővé teszi a bizalmas adatok biztonságos továbbítását a háttérrendszerbe, miközben kihasználja az Application Gateway 7. rétegbeli terheléselosztási funkcióit, beleértve a cookie-alapú munkamenet-affinitást, az URL-alapú útválasztást, a webhelyeken alapuló útválasztást, valamint az X-Forwarded-* fejlécek újraírásának vagy beszúrásának lehetőségét.

Ha az Application Gateway teljes körű TLS-kommunikációs móddal van konfigurálva, leállítja a TLS-munkameneteket az átjárón, és visszafejti a felhasználói forgalmat. Ezután a konfigurált szabályokat alkalmazza a megfelelő háttérkészlet-példány kiválasztására a forgalom átirányításához. Ezután az Application Gateway új TLS-kapcsolatot kezdeményez a háttérkiszolgálóval, és újra visszafejti az adatokat a háttérkiszolgáló nyilvános kulcstanúsítványával, mielőtt továbbítanák a kérést a háttérrendszernek. A webkiszolgáló válasza ugyanezt a folyamatot követi a végfelhasználó elérése előtt. A teljes körű TLS engedélyezéséhez be kell állítania a protokollbeállítást a háttérbeli HTTP-beállításban HTTPS-re, és alkalmaznia kell azt egy háttérpoolra. Ez a megközelítés biztosítja, hogy a háttérkiszolgálókkal folytatott kommunikáció biztonságos legyen, és megfeleljen a követelményeknek.

További információkért tekintse meg az Application Gateway végpontok közötti TLS-titkosítását és az Application Gateway biztonságossá tételének ajánlott eljárásait.

Ebben a megoldásban az Azure Web Application Firewall (WAF) biztosítja a rendszer biztonságát a rosszindulatú támadások blokkolásával. Az Azure Application Gateway kezeli az ügyfélalkalmazásokból érkező bejövő hívásokat, TLS-lezárást hajt végre, és teljes körű TLS-t valósít meg a mögöttes AKS által üzemeltetett yelb-ui szolgáltatás meghívásával a HTTPS átviteli protokoll használatával a belső terheléselosztón és az NGINX bejövőforgalom-vezérlőn keresztül. Az alábbi ábra az architektúrát szemlélteti:

Az Application Gateway WAFv2 és NGINX bejövőforgalom-vezérlőjén alapuló megoldás ábrája HTTPS-en keresztül.

Az üzenetfolyam a következő:

  1. Az Azure Application Gateway kezeli a TLS leállítását, és HTTPS-en keresztül kommunikál a háttéralkalmazással.
  2. Az Application Gateway-figyelő az Azure Key Vaultból beszerzett SSL-tanúsítványt használja.
  3. A Figyelőhöz társított Azure WAF-szabályzat OWASP-szabályokat és egyéni szabályokat futtat a rosszindulatú támadások blokkolására irányuló bejövő kérések ellen.
  4. Az Application Gateway háttérbeli HTTP-beállításai úgy vannak konfigurálva, hogy a 443-as porton HTTPS-en keresztül hívja meg az AKS által üzemeltetett yelb-ui szolgáltatást.
  5. Az Application Gateway háttérpoolja és állapotellenőrzése az NGINX bejövőforgalom-vezérlőt az AKS belső terheléselosztón keresztül, HTTPS használatával hívja meg.
  6. Az NGINX bejövőforgalom-vezérlő az AKS belső terheléselosztójának használatára van üzembe helyezve.
  7. A SAKS klaszter az Azure Key Vault szolgáltatóval van konfigurálva a Secrets Store CSI-illesztőprogram bővítményhez, amely titkos adatokat, tanúsítványokat és kulcsokat kér le az Azure Key Vaultból egy CSI kötet segítségével.
  8. A SecretProviderClass használatával lekérheti az Application Gateway által használt tanúsítványt a Key Vaultból.
  9. Egy Kubernetes bejövő objektum az NGINX bejövőforgalom-vezérlővel teszi elérhetővé az alkalmazást HTTPS-en keresztül az AKS belső terheléselosztón keresztül.
  10. A yelb-ui szolgáltatásnak van egy ClusterIP típusa, amely korlátozza, hogy a hívás a fürtön belül vagy az NGINX bejövőforgalom-vezérlőn keresztül történhessen.

A rendszer biztonságának és stabilitásának biztosítása érdekében vegye figyelembe a következő javaslatokat:

  • Az optimális biztonság érdekében rendszeresen frissítse az Azure WAF-szabályzatot a legújabb szabályokkal.
  • Monitorozási és naplózási mechanizmusok implementálása a bejövő kérések és a lehetséges támadások nyomon követésére és elemzésére.
  • Rendszeresen végezze el az AKS-fürt, az NGINX bejövőforgalom-vezérlő és az Application Gateway karbantartását és frissítését a biztonsági rések kezelése és a biztonságos infrastruktúra fenntartása érdekében.
  • Monitorozási és naplózási mechanizmusok implementálása a bejövő kérések és a lehetséges támadások nyomon követésére és elemzésére.
  • Rendszeresen végezze el az AKS-fürt, az NGINX bejövőforgalom-vezérlő és az Application Gateway karbantartását és frissítését a biztonsági rések kezelése és a biztonságos infrastruktúra fenntartása érdekében.

Állomásnév

Az Application Gateway figyelője és a Kubernetes bejövőforgalom ugyanarra a gazdagépnévre van konfigurálva. Fontos, hogy ugyanazt a gazdagépnevet használjuk egy szolgáltatási proxy és egy háttérben futó webalkalmazás esetén a következő okok miatt:

  • A munkamenet állapotának megőrzése: Ha a proxy és a háttéralkalmazás eltérő állomásnevét használja, a munkamenet állapota elveszhet. Ez azt jelenti, hogy a felhasználói munkamenetek nem biztos, hogy megfelelően fennmaradnak, ami rossz felhasználói élményt és lehetséges adatvesztést okozhat.
  • Hitelesítési hiba: Ha a gazdagépnév eltér a proxy és a háttéralkalmazás között, a hitelesítési mechanizmusok sikertelenek lehetnek. Ez a megközelítés azt eredményezheti, hogy a felhasználók nem tudnak bejelentkezni vagy biztonságos erőforrásokhoz férnek hozzá az alkalmazásban.
  • Az URL-címek véletlen expozíciója: Ha a gazdagépnév nem marad meg, fennáll annak a kockázata, hogy a háttérbeli URL-címek a végfelhasználók számára lesznek közzétéve. Ez biztonsági résekhez és bizalmas információkhoz való jogosulatlan hozzáféréshez vezethet.
  • Cookie-problémák: A cookie-k kulcsfontosságú szerepet játszanak a felhasználói munkamenetek fenntartásában és az adatok átadásában az ügyfél és a kiszolgáló között. Ha a gazdagép neve eltér, előfordulhat, hogy a cookie-k nem a várt módon működnek, ami olyan problémákhoz vezet, mint a sikertelen hitelesítés, a helytelen munkamenet-kezelés és a helytelen átirányítás.
  • Végpontok közötti TLS/SSL-követelmények: Ha a proxy és a háttérszolgáltatás közötti biztonságos kommunikációhoz végpontok közötti TLS/SSL szükséges, az eredeti gazdagépnévhez megfelelő TLS-tanúsítványra van szükség. Az azonos gazdagépnév használata leegyszerűsíti a tanúsítványkezelési folyamatot, és biztosítja a biztonságos kommunikáció zökkenőmentes létrehozását.

Ezeket a problémákat elkerülheti, ha ugyanazt a gazdagépnevet használja mind a szolgáltatás proxyhoz, mind a háttérbeli webalkalmazáshoz. A háttéralkalmazás ugyanazt a tartományt látja, mint a webböngésző, biztosítva, hogy a munkamenet állapota, a hitelesítés és az URL-kezelés megfelelően működjön.

Üzenetfolyam

Az alábbi ábra az üzenetfolyam üzembe helyezés és futtatókörnyezet során végzett lépéseit mutatja be.

A megoldás üzenetfolyamának ábrája az Application Gateway WAFv2 és NGINX bejövőforgalom-vezérlője alapján HTTPS-en keresztül.

Üzembehelyezési munkafolyamat

Az alábbi lépések az üzembehelyezési folyamatot írják le. Ez a munkafolyamat megfelel az előző diagram zöld számainak.

  1. A biztonsági mérnök létrehoz egy tanúsítványt a számítási feladat által használt egyéni tartományhoz, és egy Azure-kulcstartóban menti. Egy jól ismert hitelesítésszolgáltatótól (CA) szerezhet be érvényes tanúsítványt.
  2. A platformmérnök megadja a main.bicepparams Bicep paraméterfájlban szükséges információkat, és üzembe helyezi a Bicep-sablonokat az Azure-erőforrások létrehozásához. A szükséges információk a következők:
    • Az Azure-erőforrások előtagja.
    • Annak a meglévő Azure Key Vaultnak a neve és erőforráscsoportja, amely a számítási feladat állomásneve és az Application Gateway figyelő egyéni tartományához tartozó TLS-tanúsítványt tartalmazza.
  3. Az üzembehelyezési szkriptet úgy konfigurálhatja, hogy az alábbi csomagokat telepítse az AKS-fürtre. További információkért tekintse meg a Bicep-modul paraméterek szakaszát.
  4. Az Application Gateway figyelője lekéri a TLS-tanúsítványt az Azure Key Vaultból.
  5. A Kubernetes bejövő objektum az Azure Key Vault-szolgáltatótól a Titkos kulcstár CSI-illesztőprogramjához beszerzett tanúsítványt használja a Yelb felhasználói felületi szolgáltatás HTTPS-en keresztüli megjelenítéséhez.
  6. Az Application Gateway figyelője lekéri a TLS-tanúsítványt az Azure Key Vaultból.
  7. A Kubernetes bejövő objektum az Azure Key Vault-szolgáltatótól a Titkos kulcstár CSI-illesztőprogramhoz beszerzett tanúsítványt használja a Yelb felhasználói felületi szolgáltatás HTTPS-en keresztüli megjelenítéséhez.

Futtatási munkafolyamat

  1. Az ügyfélalkalmazás meghívja a minta webalkalmazást a gazdagép nevét használva. Az Application Gateway-figyelő egyéni tartományához társított DNS-zóna egy A rekord használatával oldja fel a DNS-lekérdezést az Application Gateway előtérbeli IP-konfigurációja által használt Azure nyilvános IP-cím címével.
  2. A rendszer elküldi a kérelmet az Application Gateway előtérbeli IP-konfigurációja által használt Nyilvános Azure IP-címre.
  3. Az Application Gateway a következő műveleteket hajtja végre:
    1. Az Application Gateway kezeli a TLS leállítását, és HTTPS-en keresztül kommunikál a háttéralkalmazással.
    2. Az Application Gateway-figyelő az Azure Key Vaultból beszerzett SSL-tanúsítványt használja.
    3. A Figyelőhöz társított Azure WAF-szabályzat OWASP-szabályokat és egyéni szabályokat futtat a bejövő kérések ellen, és blokkolja a rosszindulatú támadásokat.
    4. Az Application Gateway háttérbeli HTTP-beállításai úgy vannak konfigurálva, hogy a minta webalkalmazást HTTPS-en keresztül hívja meg a 443-as porton.
  4. Az Application Gateway háttérkészlete meghívja az NGINX bejövőforgalom-vezérlőt az AKS belső terheléselosztón keresztül HTTPS használatával.
  5. A rendszer elküldi a kérést az egyik ügynökcsomópontnak, amely az NGINX bejövőforgalom-vezérlő podját üzemelteti.
  6. Az NGINX bejövőforgalom-vezérlő egyik replikája kezeli a kérést, és elküldi a kérést a yelb-ui szolgáltatás egyik szolgáltatásvégpontjának.
  7. A yelb-ui a yelb-appserver szolgáltatást hívja.
  8. A yelb-appserver a yelb-db és yelb-cache szolgáltatásokat hívja.
  9. A yelb-ui a yelb-appserver szolgáltatást hívja.
  10. A yelb-appserver a yelb-db és yelb-cache szolgáltatásokat hívja.

Telepítés

A Bicep-sablonok alapértelmezés szerint az AKS-fürtöt az Azure CNI Overlay hálózati plugin és a Cilium adat sík telepítésével állítják be. Alternatív hálózati beépülő modult is használhat. Emellett a projekt bemutatja, hogyan helyezhet üzembe egy AKS-fürtöt az alábbi bővítményekkel és szolgáltatásokkal:

Éles környezetben erősen javasoljuk egy privát AKS-fürt üzembe helyezését az Uptime SLA-val. További információkért lásd: nyilvános DNS-címmel rendelkező privát AKS-fürt.

Másik lehetőségként üzembe helyezhet egy nyilvános AKS-fürtöt, és biztonságos hozzáférést biztosíthat az API-kiszolgálóhoz engedélyezett IP-címtartományok használatával. Az infrastruktúra Bicep-sablonok használatával történő azure-beli üzembe helyezésével kapcsolatos részletes információkért és utasításokért tekintse meg a társ Azure-kódmintát.

Éles környezetben erősen javasoljuk egy privát AKS-fürt üzembe helyezését az Uptime SLA-val. További információért lásd: nyilvános DNS-címmel rendelkező privát AKS-fürt. Másik lehetőségként üzembe helyezhet egy nyilvános AKS-fürtöt, és biztonságos hozzáférést biztosíthat az API-kiszolgálóhoz engedélyezett IP-címtartományok használatával. Az infrastruktúra Bicep-sablonok használatával történő azure-beli üzembe helyezésével kapcsolatos részletes információkért és utasításokért tekintse meg a társ Azure-kódmintát.

Következő lépés

AWS-webalkalmazás számítási feladatainak üzembe helyezése az Azure-ban

Közreműködők

A Microsoft fenntartja ezt a cikket. A következő közreműködők eredetileg megírták:

Fő szerző:

Egyéb közreműködők:

  • Utolsó frissítés időpontja: