Beveiligingsconcepten voor toepassingen en clusters in Azure Kubernetes Service (AKS)

Containerbeveiliging beschermt de volledige end-to-end-pijplijn van build naar de toepassingsworkloads die worden uitgevoerd in Azure Kubernetes Service (AKS).

De Secure Supply Chain omvat de bouwwerkomgeving en de registratie.

Kubernetes bevat beveiligingsonderdelen, zoals beveiligingsstandaarden voor pods en geheimen. Azure bevat onderdelen zoals Microsoft Entra ID, Microsoft Defender voor containers, Azure Policy, Azure Key Vault, netwerkbeveiligingsgroepen en ingedeelde clusterupgrades. AKS combineert deze beveiligingsonderdelen tot:

• Geef een volledig verificatie- en autorisatieverhaal op.
• Pas ingebouwde AKS-Azure Policy toe om uw toepassingen te beveiligen.
• Integraal inzicht van build tot en met uw applicatie met Microsoft Defender for Containers.
• Zorg ervoor dat uw AKS-cluster de meest recente beveiligingsupdates en Kubernetes-releases uitvoert.
• Geef veilig podverkeer en toegang tot gevoelige inloggegevens.

AKS ondersteunt twee clustermodi: AKS Automatic en AKS Standard. De beveiligingsconcepten in dit artikel zijn van toepassing op beide modi, tenzij anders vermeld. AKS Automatic bevat een beperkte beveiligingsbasislijn met verschillende besturingselementen die standaard vooraf zijn geconfigureerd, terwijl AKS Standard meer configuratieflexbiliteit biedt.

In dit artikel worden de belangrijkste concepten geïntroduceerd waarmee uw toepassingen in AKS worden beveiligd.

Beveiliging bouwen

Bouwbeveiliging is het toegangspunt voor uw beveiligde toeleveringsketen. Voordat installatiekopieën worden gepromoveerd naar implementatieomgevingen, voert u statische analyse en evaluatie van beveiligingsproblemen en naleving uit in CI.

Gebruik in beide AKS-modi risicogebaseerde triage in plaats van alle builds te blokkeren bij elke kwetsbaarheid. Geef prioriteit aan herstel met behulp van de status en ernst van de leverancier en pas respijtperioden toe voor niet-exploiteerbare of tijdgebonden uitzonderingen.

AKS Automatic helpt de stroomafwaartse configuratiedrift te verminderen door clusters te starten vanaf een vaste basislijn met vooraf geconfigureerde beveiligingscontroles. Hierdoor wordt validatie tijdens het buildproces van imagekwaliteit en naleving van beleid nog belangrijker, omdat vertrouwde images consistenter worden doorgeschoven naar een veilige runtimebasis.

AKS Standard biedt meer flexibiliteit op clusterniveau, dus moeten build-pipelines expliciet de basislijn van uw organisatie afdwingen voor de herkomst van images, drempelwaarden voor kwetsbaarheden en beleidscontroles vóór de uitrol.

Registerbeveiliging

De registerbeveiliging controleert of alleen vertrouwde en compatibele installatiekopieën beschikbaar zijn voor implementatie en helpt bij het detecteren van afwijkingen na de build. Evalueer de status van beveiligingsproblemen in het register continu, niet alleen tijdens het bouwen. Het scannen van registers detecteert nieuw bekendgemaakte kwetsbaarheden en images die goedgekeurde buildprocessen hebben omzeild. Gebruik het ondertekenen en verifiëren van images, zoals Notary V2, om ervoor te zorgen dat workloads worden uitgerold vanuit vertrouwde bronnen met verifieerbare herkomst.

Voor AKS Automatic, waarbij verschillende runtimebeveiligingsmogelijkheden vooraf zijn geconfigureerd, blijven registerbesturingselementen een kritieke upstream-poort om de runtime-toeleveringsketen schoon te houden. Voor AKS Standard gebruikt u dezelfde registerinstellingen en stemt u deze af op de toelatings- en beleidsconfiguratie van uw cluster om het gebruik van vertrouwde afbeeldingen consistent af te dwingen.

Clusterbeveiliging

In AKS maken de primaire onderdelen van Kubernetes deel uit van de beheerde service die wordt geleverd, beheerd en onderhouden door Microsoft. Elk AKS-cluster heeft een eigen, toegewezen Kubernetes-primaire cluster met één tenant om de API-server, Scheduler, enzovoort te bieden. Zie Vulnerability management voor Azure Kubernetes Service voor meer informatie.

De Kubernetes-API-server maakt standaard gebruik van een openbaar IP-adres en een FQDN (Fully Qualified Domain Name). U kunt de toegang tot het EINDPUNT van de API-server beperken met behulp van geautoriseerde IP-bereiken. U kunt ook een volledig privécluster maken om de toegang van de API-server tot uw virtuele netwerk te beperken.

Voor AKS Automatic is de integratie van het virtuele netwerk van de API-server vooraf geconfigureerd als onderdeel van de standaardbeveiligingspostuur. In AKS Standard is dezelfde mogelijkheid beschikbaar en kan deze worden ingeschakeld op basis van uw netwerkontwerp en beveiligingsvereisten.

U kunt de toegang tot de API-server beheren met behulp van op rollen gebaseerd toegangsbeheer van Kubernetes (Kubernetes RBAC) en Azure RBAC. In AKS Automatic is Azure RBAC voor Kubernetes-autorisatie vooraf geconfigureerd. In AKS Standard kunt u het autorisatiemodel kiezen en configureren dat het beste bij uw omgeving past. Zie Microsoft Entra-integratie met AKS voor meer informatie.

Standaardinstellingen voor automatische beveiliging van AKS

AKS Automatic bevat een beperkte basislijn met vooraf geconfigureerde beveiligingsmaatregelen, waaronder:

• Azure RBAC voor Kubernetes-autorisatie
• Integratie van virtueel netwerk van API-server
• Workloadidentiteit en OIDC-verlener
• Implementatiebeveiligingen en basisbeveiligingsstandaarden voor pods in de afdwingingsmodus
• Afbeeldingsreiniger voor het verwijderen van ongebruikte kwetsbare afbeeldingen
• Beveiligingsbeperkingen voor beheerde systeemknooppuntgroepen die grenzen tussen werkbelastingen van klanten en door AKS beheerde infrastructuur behouden

AKS Standard biedt ondersteuning voor deze mogelijkheden met meer flexibiliteit bij de implementatie, maar hiervoor is mogelijk expliciete activering en operationeel beheer vereist.

Knooppuntbeveiliging

AKS-knooppunten zijn virtuele Azure-machines (VM’s). In AKS Standard beheert u de configuratie en levenscyclusopties voor knooppuntgroepen. In AKS Automatic beheert AKS namens u systeemknooppuntgroepen en kernsysteemonderdelen, inclusief schalen en upgrades, met beveiligingsbeperkingen voor beheerde systeeminfrastructuur.

Linux-knooppunten voeren geoptimaliseerde versies van Ubuntu of Azure Linux uit. Windows Server knooppunten voeren een geoptimaliseerde Windows Server release uit met behulp van de containerd containerruntime.

Wanneer een AKS-cluster wordt gemaakt of opgeschaald, worden de knooppunten automatisch geïmplementeerd met de nieuwste beveiligingsupdates en configuraties van het besturingssysteem.

Zie Security patching nodes voor meer informatie over het beveiligingsupgradeproces voor Linux- en Windows-werkknooppunten.

AKS-clusters met Azure generatie 2-VM's bevatten ondersteuning voor Trusted Launch. Deze functie beschermt tegen geavanceerde en permanente aanvalstechnieken door technologieën te combineren die u onafhankelijk kunt inschakelen, zoals beveiligd opstarten en een gevirtualiseerde versie van de vertrouwde platformmodule (vTPM). Beheerders kunnen AKS-werkknooppunten implementeren met geverifieerde en ondertekende bootloaders, besturingssysteemkernels en stuurprogramma's om de integriteit van de volledige opstartketen van de onderliggende VM te waarborgen.

Opties voor geoptimaliseerd besturingssysteem voor containers en beveiliging

Azure Container Linux (ACL) is een onveranderbaar, containergeoptimeerd besturingssysteem voor AKS. ACL is afgeleid van het Flatcar Container Linux-project en bouwt voort op het beproefde, onveranderbare ontwerp van Flatcar, terwijl het gelaagd wordt in Azure Linux-pakketten, onderhoud en platformintegratie. Hierdoor kan ACL nauw worden afgestemd op upstream Flatcar-innovatie, terwijl aan de productie-, beveiligings- en nalevingsvereisten van Azure wordt voldaan. Zie de Flatcar-documentatie voor meer informatie over Flatcar Container Linux.

ACL is algemeen beschikbaar (GA) als besturingssysteemoptie voor AKS vanaf AKS v1.34. U kunt ACL-knooppuntgroepen implementeren in een nieuw AKS-cluster, ACL-knooppuntgroepen toevoegen aan uw bestaande clusters en bestaande Linux-knooppuntgroepen migreren naar ACL.

Zie Azure Container Linux (ACL) voor AKS-overzicht voor meer informatie over ACL.

Knooppuntautorisatie

Knooppuntautorisatie is een speciale autorisatiemodus die specifiek bedoeld is om kubelet API-aanvragen te autoriseren en bescherming te bieden tegen East-West-aanvallen. Knooppuntautorisatie is standaard ingeschakeld voor AKS 1.24 + clusters.

Knooppuntimplementatie

Knooppunten worden geïmplementeerd in een subnet van een virtueel particulier netwerk, zonder dat er openbare IP-adressen zijn toegewezen. Voor probleemoplossing en beheerdoeleinden is SSH standaard ingeschakeld en alleen toegankelijk via het interne IP-adres. SSH uitschakelen tijdens het maken van clusters en knooppuntgroepen, of bij een bestaand cluster of knooppuntgroep, bevindt zich in de previewfase. Zie SSH-toegang beheren voor meer informatie.

Opslagruimte voor knooppunten

Om opslag te bieden, gebruiken de knooppunten Azure Managed Disks. Voor de meeste VM-knooppuntgrootten zijn Azure Managed Disks Premium-schijven die worden ondersteund door ssd's met hoge prestaties. De gegevens die zijn opgeslagen op beheerde schijven worden automatisch in rust versleuteld binnen het Azure-platform. Om redundantie te verbeteren, worden Azure Managed Disks veilig gerepliceerd binnen het Azure datacenter.

Vijandige workloads met meerdere tenants

Momenteel zijn Kubernetes-omgevingen niet veilig voor vijandig multitenant gebruik. Extra beveiligingsfuncties, zoals Pod Security Policies of Kubernetes RBAC voor knooppunten, blokkeren efficiënt aanvallen. Voor echte beveiliging bij het uitvoeren van vijandige multitenant-workloads vertrouwt u alleen een hypervisor. Het beveiligingsdomein voor Kubernetes wordt het hele cluster, niet een afzonderlijk knooppunt.

Voor deze typen vijandige multitenant-workloads moet u fysiek geïsoleerde clusters gebruiken. Zie Best practices voor clusterisolatie in AKS voor meer informatie over manieren om workloads te isoleren.

Computerisolatie

Vanwege nalevings- of regelgevingsvereisten kunnen bepaalde workloads een hoge mate van isolatie van andere workloads van klanten vereisen. Voor deze workloads biedt Azure:

• Kernel-geïsoleerde containers te gebruiken als agentknooppunten in een AKS-cluster. Deze containers zijn volledig geïsoleerd tot een specifiek hardwaretype en geïsoleerd van de Azure Host-infrastructuur, het hostbesturingssysteem en de hypervisor. Ze zijn gewijd aan één klant. Selecteer een van de geïsoleerde VM-grootten als de knooppuntgrootte bij het maken van een AKS-cluster of het toevoegen van een knooppuntgroep.
• Vertrouwelijke containers (preview), ook op basis van Kata Confidential Containers, versleutelt het containergeheugen en voorkomt dat gegevens in het geheugen tijdens de berekening duidelijke tekst, leesbare indeling en manipulatie hebben. Hiermee kunt u uw containers isoleren van andere containergroepen/pods en de kernel van het besturingssysteem van het VM-knooppunt. Confidential Containers (preview) maakt gebruik van hardwaregebaseerde geheugenversleuteling (SEV-SNP).
• Pod Sandboxing (preview) biedt een isolatiegrens tussen de containertoepassing en de gedeelde kernel en rekenresources (CPU, geheugen en netwerk) van de containerhost.

Netwerkbeveiliging

Voor connectiviteit en beveiliging met on-premises netwerken kunt u uw AKS-cluster implementeren in bestaande Azure subnetten van virtuele netwerken. Deze virtuele netwerken maken verbinding met uw on-premises netwerk met behulp van Azure site-naar-site-VPN of ExpressRoute. Definieer Kubernetes-ingresscontrollers met privé, interne IP-adressen om de toegang tot services te beperken tot de interne netwerkverbinding.

In AKS Automatic zijn de mogelijkheden van beheerde virtuele netwerken en de standaardinstellingen voor inkomend en uitgaand verkeer vooraf geconfigureerd om een veilige basislijn te bieden. In AKS Standard zijn netwerkmodellen en uitgaande/inkomend verkeerscontroles flexibeler en moeten ze worden geselecteerd op basis van uw beveiligingsarchitectuur.

Azure netwerkbeveiligingsgroepen

Voor het filteren van de verkeersstroom van virtuele netwerken gebruikt Azure regels voor netwerkbeveiligingsgroepen. Deze regels definiëren de bron- en doel-IP-bereiken, poorten en protocollen die toegang tot resources hebben toegestaan of geweigerd. Standaardregels worden gemaakt om TLS-verkeer naar de Kubernetes-API-server toe te staan. U maakt services met load balancers, poorttoewijzingen of toegangsbeheerroutes. AKS wijzigt automatisch de netwerkbeveiligingsgroep voor verkeer.

Als u uw eigen subnet opgeeft voor uw AKS-cluster (ongeacht of u Azure CNI of Kubenet gebruikt), niet wijzigt u de netwerkbeveiligingsgroep op NIC-niveau die wordt beheerd door AKS. Maak in plaats daarvan meer netwerkbeveiligingsgroepen op subnetniveau om de verkeersstroom te wijzigen. Zorg ervoor dat ze niet interfereren met het benodigde verkeer dat het cluster beheert, zoals load balancer-toegang, communicatie met het besturingsvlak of uitgaand verkeer.

Kubernetes-netwerkbeleid

AKS biedt ondersteuning voor Kubernetes-netwerkbeleid om netwerkverkeer tussen pods in uw cluster te beperken. Met netwerkbeleid kunt u specifieke netwerkpaden in het cluster toestaan of weigeren op basis van naamruimten en labelkiezers.

Toepassingsbeveiliging

Als u pods wilt beveiligen die worden uitgevoerd op AKS, kunt u overwegen Microsoft Defender voor containers om cyberaanvallen te detecteren en te beperken tegen uw toepassingen die worden uitgevoerd in uw pods. Voer continu scannen uit om afwijkingen in de beveiligingsstatus van uw toepassing te detecteren en een 'blauw/groen/canary'-proces te implementeren om de kwetsbare afbeeldingen te patchen en te vervangen.

In AKS Automatic zijn de workloadidentiteit en de OIDC-uitgever vooraf geconfigureerd om veilige toegang van workloads tot Azure-services te vereenvoudigen. In AKS Standard zijn deze mogelijkheden beschikbaar en kunnen deze worden ingeschakeld als onderdeel van uw basisbeveiligingspostuur.

Beveilig toegang tot bronnen voor containers

Op dezelfde manier dat u gebruikers of groepen de vereiste minimale bevoegdheden moet verlenen, moet u ook containers beperken tot alleen noodzakelijke acties en processen. Vermijd het configureren van toepassingen en containers waarvoor geëscaleerde bevoegdheden of toegang tot de hoofdmap zijn vereist om het risico op aanvallen te minimaliseren. Ingebouwde Linux-beveiligingsfuncties, zoals AppArmor en seccomp , worden aanbevolen als best practices voor het beveiligen van containertoegang tot resources.

Kubernetes-geheimen

Met een Kubernetes-geheim injecteert u gevoelige gegevens in pods, zoals toegangsreferenties of sleutels.

1. Maak een geheim met behulp van de Kubernetes-API.
2. Definieer uw pod of implementatie en vraag een specifiek Secret aan.
   • Geheimen worden alleen verstrekt aan knooppunten die een geplande pod hebben waarvoor ze vereist zijn.
   • Het geheim wordt opgeslagen in tmpfs, niet naar schijf geschreven.
3. Wanneer u de laatste pod op een node verwijdert waarvoor een Secret is vereist, wordt de Secret verwijderd uit de tmpfs van de node.
   • Geheimen worden opgeslagen in een bepaalde naamruimte en zijn alleen toegankelijk vanuit pods binnen dezelfde naamruimte.

Het gebruik van Geheimen vermindert de hoeveelheid gevoelige informatie die is opgenomen in het YAML-manifest van de pod of service. In plaats daarvan vraagt u het geheim aan dat is opgeslagen in Kubernetes API Server als onderdeel van uw YAML-manifest. Deze benadering biedt alleen de specifieke podtoegang tot het geheim.

Kubernetes-geheimen worden opgeslagen in enzovoort, een gedistribueerd sleutel-waardearchief. AKS staat versleuteling in rest van geheimen toe in etcd met behulp van door de klant beheerde sleutels.

Verwante inhoud

Zie Een AKS-cluster upgraden om aan de slag te gaan met het beveiligen van uw AKS-clusters.

Als u modusspecifieke standaardinstellingen en operationele verantwoordelijkheden evalueert, raadpleegt u Wat is Azure Kubernetes Service (AKS) Automatisch?

Zie voor geassocieerde aanbevolen procedures aanbevolen procedures voor clusterbeveiliging en upgrades in AKS en aanbevolen procedures voor podbeveiliging in AKS.

Zie voor meer informatie over de belangrijkste Kubernetes- en AKS-concepten:

• Kubernetes/AKS-clusters en workloads
• Kubernetes/AKS-identiteit
• Virtuele Kubernetes-/AKS-netwerken
• Kubernetes / AKS-opslag
• Kubernetes/AKS-schaal