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

  • Artikel
  • 8 minuten om te lezen

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

Secure Supply Chain bevat de buildomgeving en het register.

Kubernetes bevat beveiligingsonderdelen, zoals beveiligingsstandaarden voor pods en Geheimen. Ondertussen bevat Azure onderdelen zoals Active Directory, Microsoft Defender for Cloud, Azure Policy, Azure Key Vault, netwerkbeveiligingsgroepen en gegroepeerde clusterupgrades. In AKS worden deze beveiligingsonderdelen gecombineerd tot:

  • Geef een volledig verhaal over verificatie en autorisatie op.
  • Maak gebruik van ingebouwde AKS-Azure Policy uw toepassingen te beveiligen.
  • End-to-end-inzicht van bouwen via uw toepassing met Microsoft Defender for Containers.
  • Laat uw AKS-cluster de nieuwste beveiligingsupdates van het besturingssysteem en Kubernetes-releases uitvoeren.
  • Veilig podverkeer en toegang tot gevoelige referenties bieden.

In dit artikel worden de belangrijkste concepten beschreven voor het beveiligen van uw toepassingen in AKS:

Beveiliging bouwen

Als ingangspunt voor de toeleveringsketen is het belangrijk om statische analyse van builds van afbeeldingen uit te voeren voordat ze omlaag worden gepromoveerd. Dit omvat de evaluatie van beveiligings- en nalevingsvereisten. Het gaat niet om het mislukken van een build omdat deze een hoog beveiligingsprobleem heeft, omdat dit de ontwikkeling zal breken. Het gaat om het segmenteren van de 'Leveranciersstatus' op basis van beveiligingsproblemen die kunnen worden uitgevoerd door de ontwikkelteams. Maak ook gebruik van Respijtperioden om ontwikkelaars tijd te geven om geïdentificeerde problemen op te lossen.

Registerbeveiliging

Als u de status van het beveiligingsprobleem van de afbeelding in het register evalueert, wordt drift gedetecteerd en worden ook afbeeldingen gedetecteerd die niet afkomstig zijn uit uw build-omgeving. Gebruik Notaire V2 om handtekeningen te koppelen aan uw afbeeldingen 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 Kubernetes-master met één tenant om de API Server, Scheduler, enzovoort te leveren.

De Kubernetes API-server gebruikt standaard een openbaar IP-adres en een FQDN (Fully Qualified Domain Name). U kunt de toegang tot het API-server-eindpunt 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 op kubernetes-rollen gebaseerd toegangsbeheer (Kubernetes RBAC) en Azure RBAC. Zie Azure AD-integratie met AKS voor meer informatie.

Knooppuntbeveiliging

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

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

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

Notitie

AKS-clusters met:

  • Kubernetes versie 1.19 en hoger voor Linux-knooppuntgroepen gebruiken containerd als containerruntime. Gebruiken containerd met Windows Server 2019-knooppuntgroepen is momenteel in preview. Zie Een Windows Server-knooppuntgroep toevoegen met containerd voor meer informatie.
  • Kubernetes vóór v1.19 voor Linux-knooppuntgroepen gebruiken Docker als containerruntime. Voor Windows Server 2019-knooppuntgroepen is Docker de standaardcontainerruntime.

Beveiligingspatches voor knooppunt

Linux-knooppunten

Elke avond krijgen Linux-knooppunten in AKS beveiligingspatches via hun distributie-beveiligingsupdatekanaal. Dit gedrag wordt automatisch geconfigureerd wanneer de knooppunten worden geïmplementeerd in een AKS-cluster. Om onderbrekingen en mogelijke gevolgen voor het uitvoeren van workloads te minimaliseren, worden knooppunten niet automatisch opnieuw opgestart als dit vereist is voor een beveiligingspatch of kernelupdate. Zie Beveiligings- en kernelupdates toepassen op knooppunten in AKS voor meer informatie over het afhandelen van het opnieuw opstarten van knooppunten.

Beveiligingsupdates worden 's nachts toegepast op het besturingssysteem op het knooppunt, maar de knooppuntafbeelding die wordt gebruikt om knooppunten voor uw cluster te maken, blijft ongewijzigd. Als er een nieuw Linux-knooppunt wordt toegevoegd aan uw cluster, wordt de oorspronkelijke afbeelding gebruikt om het knooppunt te maken. Dit nieuwe knooppunt ontvangt elke nacht alle beveiligings- en kernelupdates die beschikbaar zijn tijdens de automatische controle, maar blijft ongepatcht totdat alle controles en herstarts zijn voltooid. U kunt upgraden van knooppuntafbeeldingen gebruiken om te controleren op knooppuntafbeeldingen die door uw cluster worden gebruikt en deze bij te werken. Zie voor meer informatie over upgraden van knooppuntafbeeldingen Azure Kubernetes Service (AKS) node image upgrade.

Windows serverknooppunten

Voor Windows Server-knooppunten wordt Windows Update niet automatisch uitgevoerd en worden de meest recente updates toegepast. Plan Windows upgrades van serverknooppuntgroep in uw AKS-cluster rond de reguliere releasecyclus Windows update en uw eigen validatieproces. Met dit upgradeproces worden knooppunten gemaakt die de meest recente Windows Server-afbeelding en patches uitvoeren en vervolgens de oudere knooppunten verwijderen. Zie Een knooppuntgroep upgraden in AKS voor meer informatie over dit proces.

Knooppuntimplementatie

Knooppunten worden geïmplementeerd in een subnet van een particulier virtueel netwerk, zonder dat er openbare IP-adressen zijn toegewezen. Voor probleemoplossing en beheer is SSH standaard ingeschakeld en alleen toegankelijk via het interne IP-adres.

Knooppuntopslag

Om opslag te bieden, gebruiken de knooppunten Azure Managed Disks. Voor de meeste VM-knooppuntgrootten worden Azure-Managed Disks Premium schijven worden gebacked door hoogwaardige SSD's. De gegevens die zijn opgeslagen op beheerde schijven, worden automatisch at-rest versleuteld binnen het Azure-platform. Om redundantie te verbeteren, worden Azure Managed Disks veilig gerepliceerd binnen het Azure-datacenter.

Onwerkbelastingen met meerdere tenants

Op dit moment zijn Kubernetes-omgevingen niet veilig voor onveilig gebruik van meerdere tenants. Extra beveiligingsfuncties, zoals Pod Security Policies of Kubernetes RBAC voor knooppunten, blokkeren op efficiënte wijze aanvallen. Voor echte beveiliging bij het uitvoeren van onveilige workloads met meerdere tenants vertrouwt u alleen een hypervisor. Het beveiligingsdomein voor Kubernetes wordt het hele cluster, geen afzonderlijk knooppunt.

Voor deze typen onverantwoordelijke workloads met meerdere tenants moet u fysiek geïsoleerde clusters gebruiken. Zie Best practices for cluster isolation in AKS (Best practices voor clusterisolatie in AKS)voor meer informatie over het isoleren van workloads.

Rekenisolatie

Vanwege nalevings- of regelgevingsvereisten is voor bepaalde workloads mogelijk een hoge mate van isolatie van andere workloads van klanten vereist. Voor deze workloads biedt Azure geïsoleerde VM's die kunnen worden gebruikt als de agentknooppunten in een AKS-cluster. Deze VM's zijn geïsoleerd voor een specifiek hardwaretype en toegewezen aan één klant.

Selecteer een van de geïsoleerde VM-grootten als knooppuntgrootte bij het maken van een AKS-cluster of het toevoegen van een knooppuntgroep.

Clusterupgrades

Azure biedt hulpprogramma's voor upgrade-orchestration om een AKS-cluster en -onderdelen te upgraden, beveiliging en naleving te onderhouden en toegang te krijgen tot de nieuwste functies. Deze upgrade-orchestration omvat zowel de Kubernetes-hoofdonderdelen als de agentonderdelen.

Geef een van de vermelde beschikbare Kubernetes-versiesop om het upgradeproces te starten. Azure kan vervolgens elk AKS-knooppunt veilig snoeren en leeglaten en upgrades uitvoeren.

Cordon en drain

Tijdens het upgradeproces worden AKS-knooppunten afzonderlijk van het cluster om te voorkomen dat er nieuwe pods op worden gepland. De knooppunten worden vervolgens als volgt leeggeleind en bijgewerkt:

  1. Er wordt een nieuw knooppunt geïmplementeerd in de knooppuntgroep.
    • Op dit knooppunt worden de meest recente besturingssysteemafbeelding en patches uitgevoerd.
  2. Een van de bestaande knooppunten wordt geïdentificeerd voor de upgrade.
  3. Pods op het geïdentificeerde knooppunt worden probleemloos beëindigd en gepland op de andere knooppunten in de knooppuntgroep.
  4. Het lege knooppunt wordt verwijderd uit het AKS-cluster.
  5. Stap 1-4 wordt herhaald totdat alle knooppunten zijn vervangen als onderdeel van het upgradeproces.

Zie Een AKS-cluster upgraden voor meer informatie.

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 weer verbinding met uw on-premises netwerk met behulp van Azure Site-to-Site VPN of Express Route. Definieer Kubernetes-toegangscontrollers met privé, interne IP-adressen om de toegang van services tot de interne netwerkverbinding te beperken.

Netwerkbeveiligingsgroepen in Azure

Azure gebruikt regels voor netwerkbeveiligingsgroep 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. Er worden standaardregels gemaakt om TLS-verkeer naar de Kubernetes-API-server toe te staan. U maakt services met load balancers, poorttoewijzingen of toegangsroutes. AKS wijzigt automatisch de netwerkbeveiligingsgroep voor de verkeersstroom.

Als u uw eigen subnet voor uw AKS-cluster op geeft (of u nu 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 geen invloed hebben op het benodigde verkeer dat het cluster beheert, zoals load balancer toegang, communicatie met het besturingsvlak en het verlaten van.

Kubernetes-netwerkbeleid

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

Toepassingsbeveiliging

Als u pods wilt beveiligen die worden uitgevoerd op AKS, gebruikt u Microsoft Defender voor Kubernetes om cyberaanvallen te detecteren en te beperken tegen uw toepassingen die in uw pods worden uitgevoerd. Voer doorlopend scannen uit om drift in de beveiligingsprobleemtoestand van uw toepassing te detecteren en implementeert een 'blauw/groen/canary'-proces 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 die ze nodig heeft.
    • Het geheim wordt opgeslagen in tmpfs, niet geschreven naar schijf.
  3. Wanneer u de laatste pod op een knooppunt verwijdert waarvoor een geheim is vereist, wordt het geheim verwijderd uit tmpfs van het knooppunt.
    • Geheimen worden opgeslagen in een bepaalde naamruimte en zijn alleen toegankelijk voor 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 aanpak biedt alleen de specifieke pod toegang tot het geheim.

Notitie

De onbewerkte geheime manifestbestanden bevatten de geheime gegevens in base64-indeling (zie de officiële documentatie voor meer informatie). Behandel deze bestanden als gevoelige informatie en commit ze nooit in broncodebeheer.

Kubernetes-geheimen worden opgeslagen in enzovoort, een gedistribueerd sleutel-waarde-opslag. Opslag in etcd wordt volledig beheerd door AKS en data-at-restwordt 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 for cluster security and upgrades in AKS (Best practices voor beveiliging van clusters en upgrades in AKS) en Best practices for pod security in AKS (Best practices voor podbeveiliging in AKS)voor de bijbehorende best practices.

Zie voor meer informatie over kubernetes- en AKS-kernconcepten: