Voorbereiden op het implementeren van de workload van de AWS-webtoepassing (Amazon Web Services) in Azure

Dit artikel bevat een uitgebreide handleiding over het implementeren van een robuuste en productieklare infrastructuur om het hosten, beveiligen, schalen en bewaken van een webtoepassing op het Azure-platform te vergemakkelijken.

Yelb-implementatie op AWS

De Yelb-voorbeeldwebtoepassing in AWS wordt geïmplementeerd met behulp van Bash, AWS CLI, eksctl, kubectl en Helm. Het bijbehorende voorbeeld bevat Bash-scripts en YAML-manifesten die u kunt gebruiken om de implementatie van de Yelb-toepassing op AWS Elastic Kubernetes Service (EKS) te automatiseren. Deze oplossing laat zien hoe u een webtoepassingsfirewall implementeert met AWS WAF om een webtoepassing te beveiligen die wordt uitgevoerd op Amazon Elastic Kubernetes Service (EKS). U kunt de Bash-scripts gebruiken om een EKS-cluster te maken en de Yelb-toepassing te implementeren. De Yelb-webtoepassing wordt blootgesteld aan het openbare internet met behulp van een Amazon Application Load Balancer (ALB) en beveiligd met behulp van de AWS WAF-webtoegangsbeheerlijst (web-ACL). Zie Een webtoepassing van AWS Elastic Kubernetes Service (EKS) overzetten naar Azure Kubernetes Service (AKS) voor gedetailleerde instructies.

Schermopname van de Yelb-service-interface.

Yelb-implementatie in Azure

In de volgende secties leert u hoe u de Yelb-voorbeeldwebtoepassing implementeert in een AKS-cluster (Azure Kubernetes Service) en deze beschikbaar maakt via een ingangscontroller zoals de NGINX-ingangscontroller. De controllerservice voor inkomend verkeer is toegankelijk via een interne (of privé) load balancer, die het verkeer verdeelt binnen het virtuele netwerk dat de AKS-cluster herbergt. In een hybride scenario kan de front-end van de load balancer worden geopend vanuit een on-premises netwerk. Zie Een interne load balancer gebruiken met Azure Kubernetes Service (AKS) voor meer informatie over interne taakverdeling.

Het bijbehorende voorbeeld ondersteunt het installeren van een beheerde NGINX-ingangscontroller met de invoegtoepassing voor toepassingsroutering of een niet-beheerde NGINX-ingangscontroller met behulp van de Helm-grafiek. De invoegtoepassing voor toepassingsroutering met NGINX-ingangscontroller biedt de volgende functies:

Eenvoudige configuratie van beheerde NGINX-ingangscontrollers op basis van kubernetes NGINX-ingangscontroller.
Integratie met Azure DNS voor beheer van openbare en privézones.
SSL-beëindiging met certificaten die zijn opgeslagen in Azure Key Vault.

Voor andere configuraties,

Om de beveiliging te verbeteren, wordt de Yelb-toepassing beveiligd door een Azure Application Gateway-resource . Deze resource wordt geïmplementeerd in een toegewezen subnet binnen hetzelfde virtuele netwerk als het AKS-cluster of in een gekoppeld virtueel netwerk. De Azure Web Application Firewall (WAF) beveiligt de toegang tot de webtoepassing die wordt gehost in Azure Kubernetes Service (AKS) en wordt weergegeven via Azure Application Gateway tegen veelvoorkomende aanvallen en beveiligingsproblemen.

Vereiste voorwaarden

Een actief Azure-abonnement. Als u nog geen Azure-account hebt, maakt u een gratis Azure-account voordat u begint.
De ingebouwde rol Eigenaar van Azure, of de ingebouwde rollen Beheerder gebruikersrechten en Medewerker, voor een abonnement in uw Azure-account.
Azure CLI versie 2.61.0 of hoger. Zie Azure CLI installeren voor meer informatie.
Preview-extensie voor Azure Kubernetes Service (AKS).
jq versie 1.5 of hoger.
Python 3 of hoger.
kubectl versie 1.21.0 of hoger
Helm-versie 3.0.0 of hoger
Visual Studio Code is geïnstalleerd op een van de ondersteunde platforms , samen met de Bicep-extensie.
Een bestaande Azure Key Vault-resource met een geldig TLS-certificaat voor de Yelb-webtoepassing.
Een bestaande Azure DNS-zone of equivalente DNS-server voor de naamomzetting van de Yelb-toepassing .

Architectuur

Dit voorbeeld biedt een verzameling Bicep-sjablonen , Bash-scripts en YAML-manifesten voor het bouwen van een AKS-cluster, het implementeren van de Yelb-toepassing , het beschikbaar maken van de UI-service met behulp van de NGINX-ingangscontroller en het beveiligen met de Azure Application Gateway en Azure Web Application Firewall (WAF).<

Dit voorbeeld bevat ook twee afzonderlijke Bicep-parameterbestanden en twee sets Bash-scripts en YAML-manifesten, elk gericht op het implementeren van twee verschillende oplossingsopties. Zie Wat is Bicep voor meer informatie over Bicep?

TLS-beëindiging bij application gateway en yelb-aanroep via HTTP

In deze oplossing zorgt de Azure Web Application Firewall (WAF) voor de beveiliging van het systeem door schadelijke aanvallen te blokkeren. De Azure Application Gateway ontvangt binnenkomende aanroepen van clienttoepassingen, voert TLS-beëindiging uit en stuurt de aanvragen door naar de door AKS gehoste yelb-ui service. Deze communicatie wordt bereikt via de interne load balancer en NGINX-ingangscontroller met behulp van het HTTP-transportprotocol. In het volgende diagram ziet u de architectuur:

De berichtstroom is als volgt:

Diagram van de berichtstroom van de oplossing op basis van Application Gateway WAFv2 en NGINX-ingangscontroller via HTTP.

De Azure Application Gateway verwerkt TLS-beëindiging en verzendt binnenkomende aanroepen naar de AKS-gehoste yelb-ui service via HTTP.
De Application Gateway Listener maakt gebruik van een SSL-certificaat dat is verkregen uit Azure Key Vault om veilige communicatie te garanderen.
Het Azure WAF-beleid dat is gekoppeld aan de listener past OWASP-regels en aangepaste regels toe op binnenkomende aanvragen, waardoor veel soorten schadelijke aanvallen effectief worden voorkomen.
De HTTP-instellingen voor de back-end van Application Gateway roepen de Yelb-toepassing aan via HTTP met behulp van poort 80.
De Application Gateway-back-endpool en statustest roepen de NGINX-ingangscontroller aan via de interne AKS-load balancer met behulp van het HTTP-protocol voor verkeerbeheer.
De NGINX-ingangscontroller maakt gebruik van de interne AKS-load balancer om beveiligde communicatie binnen het cluster te garanderen.
Een Kubernetes-inkomend object maakt gebruik van de NGINX-ingangscontroller om de toepassing via HTTP beschikbaar te maken via de interne load balancer.
De yelb-ui service met het ClusterIP type beperkt de aanroep tot binnen het cluster of via de NGINX-ingangscontroller.

End-to-end TLS implementeren met Behulp van Azure Application Gateway

TLS-beëindiging

Azure Application Gateway ondersteunt TLS-beëindiging op gatewayniveau, wat betekent dat verkeer wordt ontsleuteld bij de gateway voordat het naar de back-endservers wordt verzonden. Als u TLS-beëindiging wilt configureren, moet u een TLS/SSL-certificaat toevoegen aan de listener. Het certificaat moet de PFX-indeling (Personal Information Exchange) hebben, die zowel de persoonlijke als openbare sleutels bevat. U kunt het certificaat importeren uit Azure Key Vault naar de Application Gateway. Zie TLS-beëindiging met Key Vault-certificaten voor meer informatie.

Zero Trust-beveiligingsmodel

Als u een Zero Trust-beveiligingsmodel gebruikt, moet u niet-versleutelde communicatie tussen een serviceproxy, zoals Azure Application Gateway en de back-endservers, voorkomen. Met het Zero Trust-beveiligingsmodel wordt vertrouwen niet automatisch verleend aan gebruikers of apparaten die toegang proberen te krijgen tot resources binnen een netwerk. In plaats daarvan is continue verificatie van identiteit en autorisatie vereist voor elke aanvraag, ongeacht de locatie of het netwerk van de gebruiker. In ons scenario omvat het implementeren van het Zero Trust-beveiligingsmodel het gebruik van De Azure Application Gateway als een serviceproxy, die fungeert als een front-end voor binnenkomende aanvragen. Deze aanvragen gaan vervolgens naar de NGINX-ingangscontroller in Azure Kubernetes Service (AKS) in een versleutelde indeling.

End-to-end TLS met Application Gateway

U kunt een Zero Trust-benadering implementeren door Azure Application Gateway te configureren voor end-to-end TLS-versleuteling met de back-endservers. Met end-to-end TLS-versleuteling kunt u veilig gevoelige gegevens naar de back-end verzenden terwijl u gebruikmaakt van de laag 7-taakverdelingsfuncties van Application Gateway, waaronder sessieaffiniteit op basis van cookies, op URL's gebaseerde routering, routering op basis van sites en de mogelijkheid om X-Forwarded-*-headers te herschrijven of te injecteren.

Wanneer Application Gateway is geconfigureerd met end-to-end TLS-communicatiemodus, worden de TLS-sessies op de gateway beëindigd en wordt gebruikersverkeer ontsleuteld. Vervolgens worden de geconfigureerde regels toegepast om het juiste exemplaar van de back-endpool te selecteren om het verkeer naar te routeren. Vervolgens start Application Gateway een nieuwe TLS-verbinding met de back-endserver en versleutelt de gegevens opnieuw met behulp van het openbare-sleutelcertificaat van de back-endserver voordat de aanvraag naar de back-end wordt verzonden. Het antwoord van de webserver volgt hetzelfde proces voordat de eindgebruiker wordt bereikt. Als u end-to-end TLS wilt inschakelen, moet u de protocolinstelling instellen in de BACK-end-HTTP-instelling op HTTPS en deze toepassen op een back-endpool. Deze aanpak zorgt ervoor dat uw communicatie met de back-endservers wordt beveiligd en voldoet aan uw vereisten.

Zie end-to-end TLS-versleuteling en aanbevolen procedures voor het beveiligen van uw Application Gateway voor meer informatie.

In deze oplossing zorgt de Azure Web Application Firewall (WAF) voor de beveiliging van het systeem door schadelijke aanvallen te blokkeren. De Azure Application Gateway verwerkt binnenkomende aanroepen van clienttoepassingen, voert TLS-beëindiging uit en implementeert end-to-end TLS door de onderliggende AKS-gehoste yelb-ui service aan te roepen met behulp van het HTTPS-transportprotocol via de interne load balancer en de NGINX-ingangscontroller. In het volgende diagram ziet u de architectuur:

De berichtstroom is als volgt:

De Azure Application Gateway verwerkt TLS-beëindiging en communiceert met de back-endtoepassing via HTTPS.
De Application Gateway Listener maakt gebruik van een SSL-certificaat dat is verkregen uit Azure Key Vault.
Het Azure WAF-beleid dat is gekoppeld aan de listener voert OWASP-regels en aangepaste regels uit voor binnenkomende aanvragen om schadelijke aanvallen te blokkeren.
De HTTP-instellingen voor de back-end van Application Gateway zijn geconfigureerd voor het aanroepen van de AKS-gehoste yelb-ui service via HTTPS op poort 443.
De Application Gateway-back-endpool en statustest roepen de NGINX-ingangscontroller aan via de interne AKS-load balancer met behulp van HTTPS.
De NGINX-ingangscontroller wordt geïmplementeerd voor het gebruik van de interne AKS-load balancer.
Het SAKS-cluster is geconfigureerd met de Azure Key Vault-provider voor de Secrets Store CSI Driver invoegtoepassing om geheimen, certificaten en sleutels op te halen uit Azure Key Vault via een CSI-volume.
Een SecretProviderClass wordt gebruikt om het certificaat op te halen dat wordt gebruikt door de Application Gateway uit Key Vault.
Een Kubernetes-inkomend object maakt gebruik van de NGINX-ingangscontroller om de toepassing via HTTPS beschikbaar te maken via de interne AKS-load balancer.
De yelb-ui service heeft een ClusterIP type, dat de aanroep beperkt tot binnen het cluster of via de NGINX-ingangscontroller.

Houd rekening met de volgende aanbevelingen om de veiligheid en stabiliteit van het systeem te waarborgen:

Werk het Azure WAF-beleid regelmatig bij met de nieuwste regels om een optimale beveiliging te garanderen.
Implementeer mechanismen voor bewaking en logboekregistratie om binnenkomende aanvragen en mogelijke aanvallen bij te houden en te analyseren.
Voer regelmatig onderhoud en updates uit van het AKS-cluster, de NGINX-ingangscontroller en Application Gateway om beveiligingsproblemen op te lossen en een beveiligde infrastructuur te onderhouden.
Implementeer mechanismen voor bewaking en logboekregistratie om binnenkomende aanvragen en mogelijke aanvallen bij te houden en te analyseren.
Voer regelmatig onderhoud en updates uit van het AKS-cluster, de NGINX-ingangscontroller en Application Gateway om beveiligingsproblemen op te lossen en een beveiligde infrastructuur te onderhouden.

Hostnaam

De Application Gateway Listener en de Kubernetes-ingress zijn geconfigureerd om dezelfde hostnaam te gebruiken. Het is belangrijk om dezelfde hostnaam te gebruiken voor een serviceproxy en een back-endwebtoepassing om de volgende redenen:

Behoud van sessiestatus: wanneer u een andere hostnaam gebruikt voor de proxy en de back-endtoepassing, kan de sessiestatus verloren gaan. Dit betekent dat gebruikerssessies mogelijk niet goed blijven bestaan, wat resulteert in een slechte gebruikerservaring en mogelijk verlies van gegevens.
Verificatiefout: Als de hostnaam verschilt tussen de proxy en de back-endtoepassing, kunnen verificatiemechanismen mislukken. Deze aanpak kan ertoe leiden dat gebruikers zich niet kunnen aanmelden of toegang kunnen krijgen tot beveiligde resources binnen de toepassing.
Onbedoelde blootstelling van URL's: Als de hostnaam niet behouden blijft, bestaat het risico dat back-end-URL's mogelijk zichtbaar zijn voor eindgebruikers. Dit kan leiden tot mogelijke beveiligingsproblemen en onbevoegde toegang tot gevoelige informatie.
Cookieproblemen: Cookies spelen een cruciale rol bij het onderhouden van gebruikerssessies en het doorgeven van informatie tussen de client en de server. Wanneer de hostnaam verschilt, werken cookies mogelijk niet zoals verwacht, wat leidt tot problemen zoals mislukte verificatie, onjuiste sessieafhandeling en onjuiste omleiding.
End-to-end TLS/SSL-vereisten: als end-to-end TLS/SSL vereist is voor beveiligde communicatie tussen de proxy en de back-endservice, is een overeenkomend TLS-certificaat voor de oorspronkelijke hostnaam nodig. Het gebruik van dezelfde hostnaam vereenvoudigt het certificaatbeheerproces en zorgt ervoor dat veilige communicatie naadloos tot stand wordt gebracht.

U kunt deze problemen voorkomen door dezelfde hostnaam te gebruiken voor de serviceproxy en de back-endwebtoepassing. De back-endtoepassing ziet hetzelfde domein als de webbrowser, zodat de sessiestatus, verificatie en URL-verwerking correct werken.

Berichtenstroom

In het volgende diagram ziet u de stappen voor de berichtstroom tijdens de implementatie en runtime.

Implementatiewerkstroom

In de volgende stappen wordt het implementatieproces beschreven. Deze werkstroom komt overeen met de groene getallen in het voorgaande diagram.

Een beveiligingstechnicus genereert een certificaat voor het aangepaste domein dat door de workload wordt gebruikt en slaat het op in een Azure-sleutelkluis. U kunt een geldig certificaat verkrijgen bij een bekende certificeringsinstantie (CA).
Een platformengineer specificeert de benodigde informatie in het main.bicepparams Bicep-parametersbestand en rolt de Bicep-sjablonen uit om de Azure-resources te maken. De benodigde informatie omvat:
- Een voorvoegsel voor de Azure-resources.
- De naam en resourcegroep van de bestaande Azure Key Vault die het TLS-certificaat voor de workload-hostnaam en de Application Gateway-listener met het aangepaste domein bevat.
U kunt het implementatiescript configureren om de volgende pakketten te installeren in uw AKS-cluster. Raadpleeg de sectie parameters van de Bicep-module voor meer informatie.
- Prometheus en Grafana met behulp van de Kubernetes Helm-grafieken van de Prometheus-community: deze voorbeeldconfiguratie installeert Prometheus en Grafana standaard niet in het AKS-cluster. In plaats daarvan worden Azure Managed Prometheus en Azure Managed Grafana geïnstalleerd.
- certificaatbeheer: Certificaatbeheer is niet nodig in dit voorbeeld, omdat zowel de controller voor inkomend verkeer van Application Gateway als NGINX een vooraf geüpload TLS-certificaat uit Azure Key Vault gebruikt.
- NGINX-ingangscontroller via een Helm-grafiek: Als u de beheerde NGINX-ingangscontroller gebruikt met de invoegtoepassing voor toepassingsroutering, hoeft u geen ander exemplaar van de NGINX-ingangscontroller via Helm te installeren.
De Application Gateway-listener haalt het TLS-certificaat op uit Azure Key Vault.
Het Kubernetes-toegangsobject gebruikt het certificaat dat is verkregen van de Azure Key Vault-provider voor Secrets Store CSI Driver om de Yelb UI-service beschikbaar te maken via HTTPS.
De Application Gateway Listener haalt het TLS-certificaat op uit Azure Key Vault.
Het Kubernetes-object voor inkomend verkeer maakt gebruik van het certificaat dat is verkregen van de Azure Key Vault-provider voor Secrets Store CSI-stuurprogramma om de Yelb UI-service beschikbaar te maken via HTTPS.

Uitvoeringstijd werkstroom

De clienttoepassing roept de voorbeeldwebtoepassing aan met behulp van de hostnaam. De DNS-zone die is gekoppeld aan het aangepaste domein van de Application Gateway-listener maakt gebruik van een A record om de DNS-query op te lossen met het adres van het openbare IP-adres van Azure dat wordt gebruikt door de front-end-IP-configuratie van de Application Gateway.
De aanvraag wordt verzonden naar het openbare IP-adres van Azure dat wordt gebruikt door de front-end-IP-configuratie van de Application Gateway.
De Toepassingsgateway voert de volgende acties uit:
1. De Application Gateway verwerkt TLS-beëindiging en communiceert met de back-endtoepassing via HTTPS.
2. De Application Gateway Listener maakt gebruik van een SSL-certificaat dat is verkregen uit Azure Key Vault.
3. Het Azure WAF-beleid dat is gekoppeld aan de listener voert OWASP-regels en aangepaste regels uit op de binnenkomende aanvraag en blokkeert schadelijke aanvallen.
4. De HTTP-instellingen voor de back-end van Application Gateway zijn geconfigureerd voor het aanroepen van de voorbeeldwebtoepassing via HTTPS op poort 443.
De back-endpool van Application Gateway roept de NGINX-ingangscontroller aan via de interne AKS-load balancer met behulp van HTTPS.
De aanvraag wordt verzonden naar een van de agentknooppunten die als host fungeert voor een pod van de NGINX-ingangscontroller.
Een van de NGINX-ingresscontroller-replica's verwerkt de aanvraag en verzendt de aanvraag naar een van de service-eindpunten van de yelb-ui service.
De yelb-ui roept de yelb-appserver service aan.
De yelb-appserver roept de yelb-db en yelb-cache services aan.
De yelb-ui roept de yelb-appserver-dienst aan.
De yelb-appserver roept de yelb-db- en yelb-cache-diensten aan.

Implementatie

Bicep-sjablonen installeren standaard het AKS-cluster met de Azure CNI Overlay-netwerkinvoegtoepassing en het gegevensvlak Cilium . U kunt een alternatieve netwerkinvoegtoepassing gebruiken. Daarnaast ziet u in het project hoe u een AKS-cluster implementeert met de volgende extensies en functies:

In een productieomgeving bevelen we u ten zeerste aan een privé-AKS-cluster te implementeren met Uptime SLA. Zie privé-AKS-cluster met een openbaar DNS-adres voor meer informatie.

U kunt ook een openbaar AKS-cluster implementeren en de toegang tot de API-server beveiligen met behulp van geautoriseerde IP-adresbereiken. Zie het bijbehorende Azure-codevoorbeeld voor gedetailleerde informatie en instructies over het implementeren van de infrastructuur in Azure met bicep-sjablonen.

In een productieomgeving raden we ten zeerste aan om een privé-AKS-cluster met een Uptime SLA te implementeren. Zie het privé-AKS-cluster met een openbaar DNS-adres voor meer informatie. U kunt ook een openbaar AKS-cluster implementeren en de toegang tot de API-server beveiligen met behulp van geautoriseerde IP-adresbereiken. Raadpleeg het bijbehorende Azure-codevoorbeeld voor gedetailleerde informatie en instructies over het implementeren van de infrastructuur in Azure met bicep-sjablonen.

Volgende stap

Een AWS-webtoepassingsworkload implementeren in Azure

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben het oorspronkelijk geschreven:

Hoofdauteur:

Paolo Salvatori | Principal Customer Engineer

Andere Inzenders:

Ken Kilty | Hoofd TPM
Russell de Pina | Principal TPM
Erin Schaffer | Inhoudsontwikkelaar 2

Feedback

Is deze pagina nuttig?

Last updated on 2025-04-05