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

  • Artikel

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 bevat de buildomgeving en het register.

Kubernetes bevat beveiligingsonderdelen, zoals beveiligingsstandaarden voor pods en geheimen. Azure bevat onderdelen zoals Active Directory, Microsoft Defender for Containers, Azure Policy, Azure Key Vault, netwerkbeveiligingsgroepen en ingedeelde clusterupgrades. AKS combineert deze beveiligingsonderdelen tot:

  • Geef een volledig verificatie- en autorisatieverhaal op.
  • Pas AKS ingebouwd Azure Policy toe om uw toepassingen te beveiligen.
  • End-to-end inzicht van het bouwen via uw toepassing 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 referenties.

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

Beveiliging bouwen

Als toegangspunt voor de supply chain is het belangrijk om statische analyses van installatiekopieën uit te voeren voordat ze worden gepromoveerd tot de pijplijn. Dit omvat evaluatie van beveiligingsproblemen en naleving. Het gaat niet om het mislukken van een build omdat het een beveiligingsprobleem heeft, omdat dat de ontwikkeling onderbreekt. Het gaat erom de leveranciersstatus te segmenteren op basis van beveiligingsproblemen die door de ontwikkelteams kunnen worden uitgevoerd. Gebruik ook Respijtperioden om ontwikkelaars tijd te geven om geïdentificeerde problemen op te lossen.

Registerbeveiliging

Het beoordelen van de beveiligingsstatus van de installatiekopie in het register detecteert drift en detecteert ook installatiekopieën die niet afkomstig zijn uit uw buildomgeving. Gebruik Notary V2 om handtekeningen toe te voegen aan uw installatiekopieën om ervoor te zorgen dat implementaties afkomstig zijn van een vertrouwde locatie.

Clusterbeveiliging

In AKS maken de Kubernetes-hoofdonderdelen deel uit van de beheerde service die wordt geleverd, beheerd en onderhouden door Microsoft. Elk AKS-cluster heeft een eigen, toegewezen Kubernetes-master met één tenant om de API-server, Scheduler, enzovoort te bieden. Zie Beheer van beveiligingsproblemen 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.

U kunt de toegang tot de API-server beheren met behulp van op rollen gebaseerd toegangsbeheer van Kubernetes (Kubernetes RBAC) en Azure RBAC. Zie Microsoft Entra-integratie met AKS voor meer informatie.

Knooppuntbeveiliging

AKS-knooppunten zijn virtuele Azure-machines (VM's) die u beheert en onderhoudt.

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

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

Notitie

AKS-clusters die worden uitgevoerd:

  • Kubernetes versie 1.19 en hoger: Linux-knooppuntgroepen worden gebruikt containerd als containerruntime. Windows Server 2019-knooppuntgroepen worden gebruikt containerd als containerruntime, die momenteel in preview is. Zie Een Windows Server-knooppuntgroep toevoegen met containerdvoor meer informatie.
  • Kubernetes versie 1.19 en eerder: Linux-knooppuntgroepen gebruiken Docker als containerruntime. Windows Server 2019-knooppuntgroepen gebruiken Docker voor de standaardcontainerruntime.

Zie Beveiligingspatchingknooppunten voor meer informatie over het beveiligingsupgradeproces voor Linux- en Windows-werkknooppunten.

AKS-clusters waarop Virtuele Machines van de Azure-generatie 2 worden uitgevoerd, bevatten ondersteuning voor Vertrouwde lancering (preview), die beschermt tegen geavanceerde en permanente aanvalstechnieken door technologieën te combineren die onafhankelijk kunnen worden ingeschakeld, zoals beveiligde opstart- en gevirtualiseerde versie van de vertrouwde platformmodule (vTPM). Beheer istrators 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.

Knooppuntautorisatie

Knooppuntautorisatie is een speciaal doelautorisatiemodus die specifiek kubelet API-aanvragen autoriseert om bescherming te bieden tegen aanvallen in oost-West. 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 voor een bestaand cluster of knooppuntgroep, is in preview. Zie SSH-toegang beheren voor meer informatie.

Knooppuntopslag

Voor opslag 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.

Rekenisolatie

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

  • Kernel-geïsoleerde containers die moeten worden gebruikt 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 toegewezen 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, evenals 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 subnetten van virtuele Azure-netwerken. Deze virtuele netwerken maken verbinding met uw on-premises netwerk met behulp van Azure Site-to-Site VPN of Express Route. Definieer Kubernetes-toegangsbeheerobjectcontrollers met persoonlijke, interne IP-adressen om de toegang tot services tot de interne netwerkverbinding te beperken.

Netwerkbeveiligingsgroepen in Azure

Azure gebruikt regels voor netwerkbeveiligingsgroepen om de verkeersstroom van virtuele netwerken te filteren. 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 verkeersstromen.

Als u uw eigen subnet opgeeft voor uw AKS-cluster (ongeacht of u Azure CNI of Kubenet gebruikt), wijzigt u de netwerkbeveiligingsgroep op NIC-niveau die wordt beheerd door AKS niet . 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 Microsoft Defender for Containers overwegen om cyberaanvallen te detecteren en te beperken tegen uw toepassingen die in uw pods worden uitgevoerd. 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.

Kubernetes Secrets

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 geheim aan.
    • Geheimen worden alleen verstrekt aan knooppunten met een geplande pod waarvoor ze zijn vereist.
    • Het geheim wordt opgeslagen in tmpfs, niet naar schijf geschreven.
  3. Wanneer u de laatste pod op een knooppunt verwijdert waarvoor een geheim is vereist, wordt het geheim verwijderd uit de tmpfs van het knooppunt.
    • Geheimen worden opgeslagen in een bepaalde naamruimte en zijn alleen toegankelijk vanuit pods binnen dezelfde naamruimte.

Het gebruik van Geheimen vermindert de gevoelige informatie die is gedefinieerd 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.

Notitie

De onbewerkte manifestbestanden van het geheim bevatten de geheime gegevens in base64-indeling. Zie de officiële documentatie voor meer informatie. Behandel deze bestanden als gevoelige informatie en voer ze nooit door naar broncodebeheer.

Kubernetes-geheimen worden opgeslagen in enzovoort, een gedistribueerd sleutel-waardearchief. AKS beheert het etcd-archief volledig en gegevens worden in rust versleuteld binnen het Azure-platform.

Volgende stappen

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

Zie Best practices voor clusterbeveiliging en -upgrades in AKS en aanbevolen procedures voor podbeveiliging in AKS voor gekoppelde aanbevolen procedures.

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