Bewerken

Azure Firewall gebruiken om een AKS-cluster (Azure Kubernetes Service) te beveiligen

Azure Firewall
Azure Kubernetes Service (AKS)
Azure Private Link
Azure Virtual Network
Azure DevOps

In deze handleiding wordt beschreven hoe u een privé-AKS-cluster maakt in een hub-and-spoke-netwerktopologie met behulp van Terraform en Azure DevOps. Azure Firewall wordt gebruikt om verkeer van en naar het AKS-cluster (Azure Kubernetes Service) te inspecteren. Het cluster wordt gehost door een of meer virtuele spoke-netwerken die zijn gekoppeld aan het virtuele hubnetwerk.

Architectuur

Diagram that shows an architecture that has a private A K S cluster in a hub-and-spoke network topology.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom

Terraform-modules worden gebruikt voor het implementeren van een nieuw virtueel netwerk met vier subnetten die als host fungeren:

  • Het AKS-cluster (AksSubnet).
  • Een jump-box virtuele machine (VM) en privé-eindpunten (VmSubnet).
  • Application Gateway WAF2 (AppGatewaySubnet).
  • Azure Bastion (AzureBastionSubnet).

Het AKS-cluster maakt gebruik van een door de gebruiker gedefinieerde beheerde identiteit om extra resources te maken, zoals load balancers en beheerde schijven in Azure. Met de Terraform-modules kunt u desgewenst een AKS-cluster met deze functies implementeren:

Het AKS-cluster bestaat uit de volgende pools:

  • Een systeemknooppuntgroep die alleen kritieke systeempods en -services host
  • Een gebruikersknooppuntgroep die als host fungeert voor gebruikersworkloads en artefacten

Er wordt een VIRTUELE machine geïmplementeerd in het virtuele netwerk dat als host fungeert voor het AKS-cluster. Wanneer u AKS als een privécluster implementeert, kunnen systeembeheerders deze VM gebruiken om het cluster te beheren via het Kubernetes-opdrachtregelprogramma. De diagnostische logboeken voor opstarten van de virtuele machine worden opgeslagen in een Azure Storage-account.

Een Azure Bastion-host biedt verbeterde SSH-connectiviteit met de jumpbox-VM via SSL. Azure Container Registry wordt gebruikt voor het bouwen, opslaan en beheren van containerinstallatiekopieën en artefacten (zoals Helm-grafieken).

De architectuur bevat een Azure Firewall die wordt gebruikt om het binnenkomende en uitgaande verkeer te beheren via DNAT-regels, netwerkregels en toepassingsregels. Het helpt ook bij het beveiligen van workloads met behulp van filteren op basis van bedreigingsinformatie. De Azure Firewall en Bastion worden geïmplementeerd in een virtueel hubnetwerk dat is gekoppeld aan het virtuele netwerk dat als host fungeert voor het privé-AKS-cluster. Een routetabel en door de gebruiker gedefinieerde routes worden gebruikt om het uitgaande verkeer van het privé-AKS-cluster naar de Azure Firewall te routeren.

Notitie

We raden u ten zeerste aan om de Premium-SKU van Azure Firewall te gebruiken, omdat deze geavanceerde beveiliging tegen bedreigingen biedt.

Een Key Vault wordt gebruikt als een geheim archief door workloads die worden uitgevoerd op AKS om sleutels, certificaten en geheimen op te halen via het Microsoft Entra Workload-ID, Secrets Store CSI Driver of Dapr. Met Azure Private Link kunnen AKS-workloads toegang krijgen tot Azure PaaS-services, zoals Azure Key Vault, via een privé-eindpunt in het virtuele netwerk.

De topologie omvat privé-eindpunten en privé-DNS-zones voor deze services:

  • Azure Blob Storage-account
  • Container Registry
  • Sleutelkluis
  • De API-server van het Kubernetes-cluster

Er is een virtuele netwerkkoppeling tussen de hub-and-spoke-virtuele netwerken die als host fungeren voor het AKS-cluster en de privé-DNS-zones die eerder zijn beschreven.

Een Log Analytics-werkruimte wordt gebruikt om de diagnostische logboeken en metrische gegevens van Azure-services te verzamelen.

Onderdelen

  • Azure Firewall is een cloudeigen, intelligente netwerkfirewallbeveiligingsservice die bescherming biedt tegen bedreigingen voor cloudworkloads die worden uitgevoerd in Azure. Het is een volledige stateful firewall als een service met ingebouwde hoge beschikbaarheid en onbeperkte cloudschaalbaarheid. Het biedt zowel oost-west- als noord-zuid verkeersinspectie.

  • Container Registry is een beheerde, persoonlijke Docker-registerservice die is gebaseerd op opensource Docker Registry 2.0. U kunt Azure-containerregisters gebruiken met uw bestaande pijplijnen voor containerontwikkeling en -implementatie of containerregistertaken gebruiken om containerinstallatiekopieën te bouwen in Azure.

  • Azure Kubernetes Service vereenvoudigt het implementeren van beheerde Kubernetes-clusters in Azure door de operationele overhead naar Azure te offloaden. Als gehoste Kubernetes-service verwerkt Azure kritieke taken, zoals statuscontrole en onderhoud. Omdat Kubernetes-masters worden beheerd door Azure, beheert en onderhoudt u alleen de agentknooppunten.

  • Key Vault slaat de toegang tot geheimen op, zoals API-sleutels, wachtwoorden, certificaten en cryptografische sleutels, met verbeterde beveiliging. Met Key Vault kunt u ook eenvoudig openbare en persoonlijke TLS/SSL-certificaten (Transport Layer Security/Secure Sockets Layer) inrichten, beheren en implementeren voor gebruik met Azure en uw interne verbonden resources.

  • Azure Bastion is een volledig beheerd Platform as a Service (PaaS) dat u in uw virtuele netwerk inricht. Azure Bastion biedt verbeterde connectiviteit met Remote Desktop Protocol (RDP) en Secure Shell (SSH) met de VM's in uw virtuele netwerk, rechtstreeks vanuit Azure Portal via TLS.

  • Azure Virtual Machines biedt on-demand, schaalbare computingresources die u de flexibiliteit van virtualisatie bieden.

  • Azure Virtual Network is de fundamentele bouwsteen voor privénetwerken van Azure. Met Virtual Network kunnen Azure-resources (zoals VM's) met elkaar communiceren, internet en on-premises netwerken met verbeterde beveiliging. Een virtueel Azure-netwerk is net als een traditioneel netwerk dat on-premises is, maar het bevat voordelen van de Azure-infrastructuur, zoals schaalbaarheid, beschikbaarheid en isolatie.

  • Met virtuele netwerkinterfaces kunnen Azure-VM's communiceren met internet, Azure en on-premises resources. U kunt verschillende netwerkinterfacekaarten toevoegen aan één Virtuele Azure-machine, zodat onderliggende VM's hun eigen toegewezen netwerkinterfaceapparaten en IP-adressen kunnen hebben.

  • Beheerde Azure-schijven bieden opslagvolumes op blokniveau die door Azure worden beheerd op Azure-VM's. Ultraschijven, premium SSD's (solid-state drives), standard SSD's en standard harde schijven (HDD's) zijn beschikbaar.

  • Blob Storage is een oplossing voor objectopslag voor de cloud. Blob Storage is geoptimaliseerd voor het opslaan van grote hoeveelheden ongestructureerde gegevens.

  • Met Private Link hebt u toegang tot Azure PaaS-services (bijvoorbeeld Blob Storage en Key Vault) via een privé-eindpunt in uw virtuele netwerk. U kunt deze ook gebruiken voor toegang tot door Azure gehoste services die u bezit of die worden geleverd door een Microsoft-partner.

Alternatieven

U kunt een firewall van derden van Azure Marketplace gebruiken in plaats van Azure Firewall. Als u dit doet, is het uw verantwoordelijkheid om de firewall goed te configureren om het binnenkomende en uitgaande verkeer van het AKS-cluster te inspecteren en toe te staan of te weigeren.

Scenariodetails

In een productieomgeving moet communicatie met een Kubernetes-cluster worden beveiligd door een firewall die het binnenkomende en uitgaande netwerkverkeer bewaakt en beheert op basis van een set beveiligingsregels. Een firewall brengt doorgaans een barrière tot stand tussen een vertrouwd netwerk en een niet-vertrouwd netwerk, zoals internet.

U kunt een privé-AKS-cluster maken in een hub-and-spoke-netwerktopologie met behulp van Terraform en Azure DevOps. Azure Firewall wordt gebruikt om verkeer van en naar het AKS-cluster (Azure Kubernetes Service) te inspecteren. Het cluster wordt gehost door een of meer virtuele spoke-netwerken die zijn gekoppeld aan het virtuele hubnetwerk.

Azure Firewall ondersteunt drie verschillende SKU's om te voldoen aan een breed scala aan gebruiksscenario's en voorkeuren van klanten:

  • Azure Firewall Premium wordt aanbevolen om zeer gevoelige toepassingen, zoals betalingsverwerking, te beveiligen. Het biedt ondersteuning voor geavanceerde mogelijkheden voor beveiliging tegen bedreigingen, zoals malware en TLS-inspectie.
  • Azure Firewall Standard wordt aanbevolen voor klanten die op zoek zijn naar een Laag 3-Laag 7-firewall en die automatisch schalen nodig hebben om piekperioden van maximaal 30 Gbps af te handelen. Het biedt ondersteuning voor bedrijfsfuncties, zoals bedreigingsinformatie, DNS-proxy, aangepaste DNS en webcategorieën.
  • Azure Firewall Basic wordt aanbevolen voor klanten met doorvoerbehoeften van minder dan 250 Mbps.

In de volgende tabel ziet u de functies van de drie Azure Firewall-SKU's. Zie prijzen voor Azure Firewall voor meer informatie.

Screenshot that shows features of the three Azure Firewall SKUs

AKS-clusters hebben standaard onbeperkte uitgaande internettoegang. Met dit netwerktoegangsniveau kunnen knooppunten en services die in het AKS-cluster worden uitgevoerd, zo nodig toegang krijgen tot externe resources. Als u uitgaand verkeer wilt beperken, moet een beperkt aantal poorten en adressen toegankelijk blijven om goede clusteronderhoudstaken te onderhouden. De eenvoudigste manier om het uitgaande verkeer van een Kubernetes-cluster zoals AKS te beveiligen, is door een softwarefirewall te gebruiken die uitgaand verkeer kan beheren op basis van domeinnamen. Azure Firewall kan uitgaand HTTP- en HTTPS-verkeer beperken op basis van de FQDN (Fully Qualified Domain Name) van de bestemming. U kunt ook uw firewall- en beveiligingsregels configureren om deze vereiste poorten en adressen toe te staan. Zie Uitgaand verkeer voor clusterknooppunten in AKS beheren voor meer informatie.

Op dezelfde manier kunt u inkomend verkeer beheren en de beveiliging verbeteren door filteren op basis van bedreigingsinformatie in te schakelen op een Azure Firewall die is geïmplementeerd in een gedeeld perimeternetwerk. Deze filtering kan waarschuwingen bieden en verkeer naar en van bekende schadelijke IP-adressen en domeinen weigeren.

Potentiële gebruikscases

In dit scenario wordt de beveiliging van inkomend en uitgaand verkeer naar en van een Kubernetes-cluster verbeterd.

Asymmetrische routering voorkomen

In deze oplossing wordt Azure Firewall geïmplementeerd in een virtueel hubnetwerk en wordt het privé-AKS-cluster geïmplementeerd in een virtueel spoke-netwerk. Azure Firewall maakt gebruik van netwerk- en toepassingsregelverzamelingen om het uitgaand verkeer te beheren. In dit geval moet u het inkomend verkeer configureren naar een openbaar eindpunt dat wordt weergegeven door elke service die wordt uitgevoerd op AKS om het systeem in te voeren via een van de openbare IP-adressen die door de Azure Firewall worden gebruikt.

Pakketten komen binnen op het openbare IP-adres van de firewall, maar keren terug naar de firewall via het privé-IP-adres (met behulp van de standaardroute). Dit is een probleem. Om dit te voorkomen, maakt u een andere door de gebruiker gedefinieerde route voor het openbare IP-adres van de firewall, zoals wordt weergegeven in het volgende diagram. Pakketten die naar het openbare IP-adres van de firewall gaan, worden gerouteerd via internet. Deze configuratie vermijdt de standaardroute naar het privé-IP-adres van de firewall.

Als u het verkeer van uw AKS-workloads wilt routeren naar de Azure Firewall in het virtuele hubnetwerk, moet u het volgende doen:

  • Maak en koppel een routetabel aan elk subnet dat als host fungeert voor de werkknooppunten van uw cluster.
  • Maak een door de gebruiker gedefinieerde route om het verkeer voor CIDR 0.0.0.0/0 door te sturen naar het privé-IP-adres van de Azure Firewall. Geef het virtuele apparaat op voor het type Volgende hop.

Zie Zelfstudie: Azure Firewall implementeren en configureren met behulp van Azure Portal voor meer informatie.

Diagram that shows how to avoid asymmetric routing when you use Azure Firewall in front of your workloads.

Zie voor meer informatie:

Workloads implementeren in een privé-AKS-cluster wanneer u Azure DevOps gebruikt

Als u Azure DevOps gebruikt, moet u er rekening mee houden dat u geen door Microsoft gehoste Azure DevOps-agents kunt gebruiken om uw workloads te implementeren in een privé-AKS-cluster. Ze hebben geen toegang tot de API-server. Als u workloads wilt implementeren in uw privé-AKS-cluster, moet u een zelf-hostende Azure DevOps-agent inrichten en gebruiken in hetzelfde virtuele netwerk als uw privé-AKS-cluster of in een gekoppeld virtueel netwerk. In het laatste geval moet u een koppeling voor een virtueel netwerk maken tussen de privé-DNS-zone van het AKS-cluster in de knooppuntresourcegroep en het virtuele netwerk dat als host fungeert voor de zelf-hostende Azure DevOps-agent.

U kunt één Windows - of Linux Azure DevOps-agent implementeren op een virtuele machine of u kunt een virtuele-machineschaalset gebruiken. Zie Azure Virtual Machine Scale Set-agents voor meer informatie. Als alternatief kunt u een zelf-hostende agent instellen in Azure Pipelines om te worden uitgevoerd in een Windows Server Core-container (voor Windows-hosts) of Ubuntu-container (voor Linux-hosts) met Docker. Implementeer deze als pod met een of meerdere replica's in uw privé-AKS-cluster. Zie voor meer informatie:

Als de subnetten waarop de knooppuntgroepen van uw privé-AKS-cluster worden gehost, zijn geconfigureerd om het uitgaand verkeer naar een Azure Firewall te routeren via een routetabel en door de gebruiker gedefinieerde route, moet u de juiste toepassings- en netwerkregels maken. Deze regels moeten de agent toegang geven tot externe sites om hulpprogramma's te downloaden en te installeren, zoals Docker, Kubectl, Azure CLI en Helm op de virtuele machine van de agent. Zie Een zelf-hostende agent uitvoeren in Docker en Azure DevOps Pipeline Agent bouwen en implementeren op AKS voor meer informatie.

Diagram that shows deployment of workloads to a private AKS cluster for use with Azure DevOps.

Azure Firewall gebruiken vóór een openbare Standard Load Balancer

Resourcedefinities in de Terraform-modules maken gebruik van het metaargument voor de levenscyclus om acties aan te passen wanneer Azure-resources buiten Terraform-beheer worden gewijzigd. Het argument ignore_changes wordt gebruikt om Terraform te instrueren om updates voor bepaalde resource-eigenschappen, zoals tags, te negeren. De resourcedefinitie van Azure Firewall Policy bevat een levenscyclusblok om te voorkomen dat Terraform de resource bijwerkt wanneer een regelverzameling of één regel wordt gemaakt, bijgewerkt of verwijderd. Op dezelfde manier bevat de Azure Route-tabel een levenscyclusblok om te voorkomen dat Terraform de resource bijwerkt wanneer een door de gebruiker gedefinieerde route wordt gemaakt, verwijderd of bijgewerkt. Hiermee kunt u de DNAT-, toepassings- en netwerkregels van een Azure Firewall Policy en de door de gebruiker gedefinieerde routes van een Azure Route Table buiten Terraform-beheer beheren.

Het voorbeeld dat is gekoppeld aan dit artikel bevat een Azure DevOps CD-pijplijn die laat zien hoe u een workload implementeert in een privé-AKS-cluster met behulp van een Azure DevOps-pijplijn die wordt uitgevoerd op een zelf-hostende agent. In het voorbeeld wordt de webtoepassing Bitnami redmine-projectbeheer geïmplementeerd met behulp van een openbare Helm-grafiek . In dit diagram ziet u de netwerktopologie van het voorbeeld:

Diagram that shows Azure Firewall in front of a public Standard Load Balancer.

Dit is de berichtstroom:

  1. Een aanvraag voor de door AKS gehoste webtoepassing wordt verzonden naar een openbaar IP-adres dat wordt weergegeven door Azure Firewall via een openbare IP-configuratie. Zowel het openbare IP-adres als de openbare IP-configuratie zijn toegewezen aan deze workload.
  2. Een AZURE Firewall DNAT-regel vertaalt het openbare IP-adres en de poort van Azure Firewall naar het openbare IP-adres en de poort die wordt gebruikt door de werkbelasting in de openbare Standard Load Balancer van het AKS-cluster in de knooppuntresourcegroep.
  3. De load balancer verzendt de aanvraag naar een van de Kubernetes-servicepods die worden uitgevoerd op een van de agentknooppunten van het AKS-cluster.
  4. Het antwoordbericht wordt via een door de gebruiker gedefinieerde route teruggestuurd naar de oorspronkelijke beller. Het openbare IP-adres van Azure Firewall is het adresvoorvoegsel en internet is het type Volgende hop.
  5. Elke door workload geïnitieerde uitgaande aanroep wordt gerouteerd naar het privé-IP-adres van de Azure Firewall door de standaard door de gebruiker gedefinieerde route. 0.0.0.0/0 is het adresvoorvoegsel en het virtuele apparaat is het type volgende hop.

Zie Azure Firewall gebruiken vóór de Openbare Standard Load Balancer van het AKS-cluster voor meer informatie.

Azure Firewall gebruiken vóór een interne Standard Load Balancer

In het voorbeeld dat aan dit artikel is gekoppeld, wordt een ASP.NET Core-toepassing gehost als een service door een AKS-cluster en wordt fronted door een NGINX-ingangscontroller. De NGINX-ingangscontroller wordt weergegeven via een interne load balancer met een privé-IP-adres in het virtuele spoke-netwerk dat als host fungeert voor het AKS-cluster. Zie Een ingangscontroller maken voor een intern virtueel netwerk in AKS voor meer informatie. Wanneer u een NGINX-ingangscontroller of meer algemeen een LoadBalancer of ClusterIP service implementeert, met de service.beta.kubernetes.io/azure-load-balancer-internal: "true" aantekening in de sectie metagegevens, wordt er een interne standaard load balancer gemaakt die wordt aangeroepen kubernetes-internal onder de knooppuntresourcegroep. Zie Een interne load balancer gebruiken met AKS voor meer informatie. Zoals wordt weergegeven in het volgende diagram, wordt de testwebtoepassing weergegeven door de Azure Firewall via een toegewezen openbaar IP-adres van Azure.

Diagram that shows Azure Firewall in front of an internal Standard Load Balancer.

Dit is de berichtstroom:

  1. Een aanvraag voor de door AKS gehoste testwebtoepassing wordt verzonden naar een openbaar IP-adres dat wordt weergegeven door de Azure Firewall via een openbare IP-configuratie. Zowel het openbare IP-adres als de openbare IP-configuratie zijn toegewezen aan deze workload.
  2. Een AZURE Firewall DNAT-regel vertaalt het openbare IP-adres en de poort van Azure Firewall naar het privé-IP-adres en de poort die wordt gebruikt door de NGINX-ingangscontroller in de interne Standard Load Balancer van het AKS-cluster in de knooppuntresourcegroep.
  3. De aanvraag wordt verzonden door de interne load balancer naar een van de Kubernetes-servicepods die worden uitgevoerd op een van de agentknooppunten van het AKS-cluster.
  4. Het antwoordbericht wordt via een door de gebruiker gedefinieerde route teruggestuurd naar de oorspronkelijke beller. 0.0.0.0/0 is het adresvoorvoegsel en het virtuele apparaat is het type volgende hop.
  5. Elke door workload geïnitieerde uitgaande aanroep wordt gerouteerd naar het privé-IP-adres van de door de gebruiker gedefinieerde route.

Zie Azure Firewall gebruiken voor een interne Standard Load Balancer voor meer informatie.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Enkele van de volgende overwegingen zijn algemene aanbevelingen die niet specifiek zijn voor het gebruik van Azure Firewall om de beveiliging van een AKS-cluster te verbeteren. We geloven dat ze essentiële vereisten van deze oplossing zijn. Dit geldt voor de overwegingen voor beveiliging, prestaties, beschikbaarheid en betrouwbaarheid, opslag, service mesh en bewaking.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Het Azure-platform biedt verbeterde bescherming tegen verschillende bedreigingen, zoals aanvallen op het netwerk en DDoS-aanvallen (Distributed Denial-of-Service). U moet een Web Application Firewall (WAF) gebruiken om beveiliging te bieden voor alle door AKS gehoste webtoepassingen en -services die een openbaar HTTPS-eindpunt beschikbaar maken. U moet bescherming bieden tegen veelvoorkomende bedreigingen, zoals SQL-injectie, cross-site scripting en andere webaanvallen. Hiervoor gebruikt u open OWASP-regels (Web Application Security Project) en aangepaste regels. Azure Web Application Firewall biedt verbeterde gecentraliseerde beveiliging van uw webtoepassingen tegen veelvoorkomende aanvallen en beveiligingsproblemen. U kunt Azure WAF implementeren met Azure-toepassing Gateway, Azure Front Door en Azure Content Delivery Network.

DDoS-aanvallen zijn een van de grootste beschikbaarheids- en beveiligingsproblemen waarmee organisaties hun toepassingen verplaatsen naar de cloud. Met een DDoS-aanval wordt geprobeerd de resources van een toepassing uit te putten, waardoor de toepassing niet meer beschikbaar is voor legitieme gebruikers. DDoS-aanvallen kunnen worden gericht op elk eindpunt dat openbaar bereikbaar is via internet. Elke eigenschap in Azure omvat beveiliging via Azure DDoS-infrastructuurbeveiliging zonder extra kosten. De schaal en capaciteit van het wereldwijd geïmplementeerde Azure-netwerk bieden verbeterde beveiliging tegen veelvoorkomende netwerklaagaanvallen via always-on-verkeersbewaking en realtime-beperking. DDoS-infrastructuurbeveiliging vereist geen wijzigingen in de gebruikersconfiguratie of toepassing. Hiermee kunt u alle Azure-services beveiligen, waaronder PaaS-services zoals Azure DNS.

Azure DDoS Network Protection, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties om meer bescherming te bieden tegen DDoS-aanvallen. Schakel Azure DDOS-netwerkbeveiliging in voor elk virtueel perimeternetwerk.

Hier volgen enkele aanvullende beveiligingsoverwegingen:

  • Maak een privé-eindpunt voor een PaaS-service die wordt gebruikt door AKS-workloads, zoals Key Vault, Azure Service Bus en Azure SQL Database. Het verkeer tussen de toepassingen en deze services wordt niet blootgesteld aan het openbare internet. Verkeer tussen het virtuele netwerk van het AKS-cluster en een exemplaar van een PaaS-service via een privé-eindpunt reist het Microsoft-backbonenetwerk, maar de communicatie wordt niet door de Azure Firewall doorgegeven. Dit mechanisme biedt betere beveiliging en betere bescherming tegen gegevenslekken. Zie Wat is Azure Private Link? voor meer informatie.
  • Wanneer u Application Gateway vóór het AKS-cluster gebruikt, gebruikt u een Web Application Firewall-beleid om openbare workloads te beveiligen die worden uitgevoerd op AKS tegen aanvallen.
  • Gebruik netwerkbeleid om intraservicecommunicatie te scheiden en te beveiligen door te bepalen welke onderdelen met elkaar kunnen communiceren. Standaard kunnen alle pods in een Kubernetes-cluster zonder beperkingen verkeer verzenden en ontvangen. Om de beveiliging te verbeteren, kunt u Azure-netwerkbeleid of Calico-netwerkbeleid gebruiken om regels te definiëren waarmee de verkeersstroom tussen verschillende microservices wordt beheerd. Zie netwerkbeleid voor meer informatie.
  • Maak geen externe connectiviteit beschikbaar voor uw AKS-knooppunten. Maak een bastionhost of jumpbox in een virtueel beheernetwerk. Gebruik de bastionhost om verkeer naar uw AKS-cluster te routeren.
  • Overweeg om een privé-AKS-cluster in uw productieomgeving te gebruiken of ten minste veilige toegang tot de API-server met behulp van geautoriseerde IP-adresbereiken in AKS. Wanneer u geautoriseerde IP-adresbereiken op een openbaar cluster gebruikt, staat u alle uitgaande IP-adressen toe in de verzameling netwerkregels van Azure Firewall. In-clusterbewerkingen worden de Kubernetes API-server gebruikt.
  • Als u DNS-proxy inschakelt in Azure Firewall, kan Azure Firewall DNS-query's van een of meer virtuele netwerken verwerken en doorsturen naar een DNS-server die u kiest. Deze functionaliteit is van cruciaal belang en vereist voor betrouwbare FQDN-filtering in netwerkregels. U kunt dns-proxy inschakelen in de instellingen van Azure Firewall en Firewall Policy. Zie azure Firewall-logboeken en metrische gegevens voor meer informatie over DNS-proxylogboeken.
  • Wanneer u Azure Firewall voor Application Gateway gebruikt, kunt u uw Kubernetes-toegangsresource configureren om workloads beschikbaar te maken via HTTPS en een afzonderlijk subdomein en digitaal certificaat voor elke tenant gebruiken. De Application Gateway-ingangscontroller (AGIC) configureert automatisch de Application Gateway-listener voor SSL-beëindiging (Secure Sockets Layer).
  • U kunt Azure Firewall gebruiken vóór een serviceproxy, zoals de NGINX-ingangscontroller. Deze controller biedt omgekeerde proxy, configureerbare verkeersroutering en TLS-beëindiging voor Kubernetes-services. Kubernetes-resources voor inkomend verkeer worden gebruikt om de regels en routes voor uitgaand verkeer worden geconfigureerd voor individuele Kubernetes-services. Met behulp van een ingangscontroller en regels voor inkomend verkeer kunt u één IP-adres gebruiken om verkeer naar meerdere services in een Kubernetes-cluster te routeren. U kunt de TLS-certificaten genereren met behulp van een erkende certificeringsinstantie. U kunt ook Let's Encrypt gebruiken om automatisch TLS-certificaten te genereren met een dynamisch openbaar IP-adres of met een statisch openbaar IP-adres. Zie Een HTTPS-ingangscontroller maken en uw eigen TLS-certificaten op AKS gebruiken voor meer informatie.
  • Strikte coördinatie tussen de Azure Firewall-operator en de cluster- en workloadteams is nodig voor de eerste clusterimplementatie en op een doorlopende manier naarmate de workload en de clusterbehoeften zich ontwikkelen. Dit geldt met name wanneer u de verificatiemechanismen configureert, zoals OAuth 2.0 en OpenID Verbinding maken, die worden gebruikt door workloads om hun clients te verifiëren.
  • Gebruik de volgende richtlijnen om de omgeving te beveiligen die in dit artikel wordt beschreven:

Beschikbaarheid en betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

De overwegingen voor beschikbaarheid en betrouwbaarheid zijn hier niet specifiek voor multitenancy in AKS. We geloven dat ze essentiële vereisten zijn voor deze oplossing. Houd rekening met de volgende methoden voor het optimaliseren van de beschikbaarheid van uw AKS-cluster en workloads.

Tolerantie binnen regio's

  • Tijdens de implementatie kunt u Azure Firewall configureren om meerdere beschikbaarheidszones te omvatten voor een hogere beschikbaarheid. Zie de SLA voor Azure Firewall voor uptimepercentages. U kunt Azure Firewall ook koppelen aan een specifieke zone omwille van nabijheid, hoewel deze configuratie van invloed is op de SLA. Er zijn geen extra kosten verbonden aan een firewall die is geïmplementeerd in een beschikbaarheidszone. Er zijn echter extra kosten voor binnenkomende en uitgaande gegevensoverdrachten die zijn gekoppeld aan beschikbaarheidszones. Zie Prijsinformatie voor bandbreedte voor meer informatie.
  • Overweeg de knooppuntgroepen van uw AKS-cluster te implementeren in alle beschikbaarheidszones in een regio. Gebruik een Azure Standard Load Balancer of Application Gateway vóór de knooppuntgroepen. Deze topologie biedt betere tolerantie als er sprake is van een storing in één datacenter. De clusterknooppunten worden verdeeld over meerdere datacenters, in drie afzonderlijke beschikbaarheidszones binnen een regio.
  • Schakel zoneredundantie in Container Registry in voor tolerantie binnen regio's en hoge beschikbaarheid.
  • Gebruik beperkingen voor podtopologie om te bepalen hoe pods worden verdeeld over uw AKS-cluster tussen foutdomeinen zoals regio's, beschikbaarheidszones en knooppunten.
  • Overweeg om sla voor uptime te gebruiken voor AKS-clusters die bedrijfskritieke workloads hosten. Sla voor uptime is een optionele functie die een financieel ondersteunde, hogere SLA voor een cluster mogelijk maakt. Sla voor uptime garandeert hoge beschikbaarheid van het Kubernetes API-servereindpunt voor clusters die gebruikmaken van beschikbaarheidszones. U kunt deze ook gebruiken voor clusters die geen beschikbaarheidszones gebruiken, maar de SLA is lager. Zie SLA voor uptime voor meer informatie over de SLA. AKS maakt gebruik van masterknooppuntreplica's in update- en foutdomeinen om te waarborgen dat er aan de SLA-vereisten wordt voldaan.

Herstel na noodgevallen en bedrijfscontinuïteit

  • Overweeg om uw oplossing te implementeren in ten minste twee gekoppelde Azure-regio's binnen een geografie. Gebruik een globale load balancer, zoals Azure Traffic Manager of Azure Front Door, met een actieve/actieve of actieve/passieve routeringsmethode, om bedrijfscontinuïteit en herstel na noodgevallen (DR) te garanderen.
  • Azure Firewall is een regionale service. Als u uw oplossing in twee of meer regio's implementeert, moet u in elke regio een Azure Firewall maken. U kunt een globaal Azure Firewall-beleid maken om door de organisatie verplichte regels op te nemen die van toepassing zijn op alle regionale hubs. U kunt dit beleid gebruiken als een bovenliggend beleid voor regionaal Azure-beleid. Beleid dat is gemaakt met niet-leeg bovenliggend beleid, nemen alle regelverzamelingen van het bovenliggende beleid over. Verzamelingen voor netwerkregels die zijn overgenomen van een bovenliggend beleid, krijgen altijd prioriteit boven verzamelingen met netwerkregels die zijn gedefinieerd als onderdeel van een nieuw beleid. Dezelfde logica is van toepassing op toepassingsregelverzamelingen. Netwerkregelverzamelingen worden echter altijd verwerkt vóór toepassingsregelverzamelingen, ongeacht overname. Zie het overzicht van azure Firewall Manager-beleid voor meer informatie over Standard- en Premium-beleid.
  • Zorg ervoor dat u scripts, documenten uitvoert en periodiek een regionaal failoverproces test in een QA-omgeving. Dit helpt onvoorspelbare problemen te voorkomen als een kernservice wordt beïnvloed door een storing in de primaire regio. Deze tests controleren ook of de DR-benadering voldoet aan RPO/RTO-doelen, in combinatie met uiteindelijke handmatige processen en interventies die nodig zijn voor een failover.
  • Test de failbackprocedures om te controleren of ze werken zoals verwacht.
  • Sla uw containerinstallatiekopieën op in Container Registry. Geo-replicatie van het register naar elke AKS-regio. Zie Geo-replicatie in Azure Container Registry voor meer informatie.
  • Vermijd indien mogelijk het opslaan van de servicestatus in de container. Gebruik in plaats daarvan een Azure PaaS die ondersteuning biedt voor replicatie van meerdere regio's.
  • Als u Azure Storage gebruikt, bereidt en test u een proces voor het migreren van uw opslag van de primaire regio naar de back-upregio.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

DevOps

  • Implementeer uw workloads in AKS met behulp van een Helm-grafiek in een CI/CD-pijplijn (continue integratie en continue levering). Gebruik een DevOps-systeem, zoals GitHub Actions of Azure DevOps. Zie Build and deploy to Azure Kubernetes Service (Bouwen en implementeren in Azure Kubernetes Service) voor meer informatie.
  • Als u een toepassing goed wilt testen voordat u deze beschikbaar maakt voor gebruikers, gebruikt u A/B-tests en kanarie-implementaties in het levenscyclusbeheer van uw toepassing. Er zijn verschillende technieken die u kunt gebruiken om het verkeer over verschillende versies van dezelfde service te splitsen. Als alternatief kunt u de mogelijkheden voor het splitsen van verkeer gebruiken die worden geleverd door een service-mesh-implementatie. Zie Linkerd Traffic Split en Istio Traffic Management voor meer informatie.
  • Gebruik Azure Container Registry of een ander containerregister (zoals Docker Hub) om de persoonlijke Docker-installatiekopieën op te slaan die in het cluster zijn geïmplementeerd. AKS kan worden geverifieerd met Azure Container Registry met behulp van de Microsoft Entra-identiteit.
  • Test inkomend en uitgaand verkeer op uw workloads in een afzonderlijke preproductieomgeving die de netwerktopologie en firewallregels van uw productieomgeving weerspiegelt. Met een gefaseerde implementatiestrategie kunt u netwerk- of beveiligingsproblemen detecteren voordat u een nieuwe functie of netwerkregel in productie brengt.

Controleren

Azure Firewall is volledig geïntegreerd met Azure Monitor voor het registreren van binnenkomend en uitgaand verkeer dat door de firewall wordt verwerkt. Zie Filteren op basis van bedreigingsinformatie van Azure Firewall voor meer informatie.

De volgende bewakingsoverwegingen zijn niet specifiek voor multitenancy in AKS, maar we denken dat dit essentiële vereisten zijn voor deze oplossing.

  • Gebruik Container insights om de status van het AKS-cluster en de workloads te bewaken.
  • Configureer alle PaaS-services (zoals Container Registry en Key Vault) om diagnostische logboeken en metrische gegevens te verzamelen.

Kostenoptimalisatie

De kosten van de resulterende architectuur zijn afhankelijk van de volgende configuratiegegevens:

  • Servicelagen
  • Schaalbaarheid (het aantal instanties dat dynamisch wordt toegewezen door services ter ondersteuning van een bepaalde vraag)
  • Automatiseringsscripts
  • Uw herstelniveau na noodgevallen

Nadat u deze configuratiegegevens hebt beoordeeld, gebruikt u de Azure-prijscalculator om uw kosten te schatten. Zie de principes van kostenoptimalisatie in het Microsoft Azure Well-Architected Framework voor meer opties voor prijsoptimalisatie.

Dit scenario implementeren

De broncode voor dit scenario is beschikbaar in GitHub. Deze oplossing is open source en wordt geleverd met een MIT-licentie.

Vereisten

Voor online implementaties hebt u een Azure-account nodig. Als u nog geen Azure-account hebt, maakt u een gratis Azure-account voordat u begint. U moet aan deze vereisten voldoen voordat u Terraform-modules kunt implementeren met behulp van Azure DevOps:

Implementatie in Azure

  1. Zorg ervoor dat uw Azure-abonnementsgegevens handig zijn.

  2. Kloon de Workbench GitHub-opslagplaats:

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

  3. Volg de instructies in het bestand README.md.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de aanbevelingen en best practices voor AKS in het Microsoft Azure Well-Architected Framework:

Azure Firewall

Azure Kubernetes Service

Richtlijnen voor architectuur

Referentiearchitecturen