Delen via

Beveiliging voor AKS

In dit artikel worden aspecten van AKS-beveiligingsgovernance (Azure Kubernetes Service) beschreven die u moet overwegen voordat u een oplossing implementeert.

Het artikel richt zich op het implementeren van oplossingen met behulp van Azure en opensource-software. De beslissingen die u neemt wanneer u een landingszone op ondernemingsniveau maakt, kunnen gedeeltelijk vooraf worden gedefinieerd door uw governance. Zie Beveiligingsgovernance en naleving op ondernemingsniveau voor meer informatie over governanceprincipes.

Aanvalsoppervlakken

Houd rekening met de volgende vijf aanvallen wanneer u een beveiligingsstrategie voor Kubernetes-clusters maakt:

  • Bouwen
  • Registersysteem
  • groepering
  • Knooppunt
  • Applicatie

Voor elke categorie bespreken we de belangrijkste risico's die moeten worden overwogen en tegenmaatregelen voor deze risico's.

Beveiliging bouwen

Beveiliging bij het bouwen draait om het juiste gebruik van DevSecOps met containerafbeeldingen.

Grote risico's

Slechte configuratie van afbeeldingen kan leiden tot beveiligingsproblemen in het proces. Bijvoorbeeld, mogelijk heeft u containers die meer privileges hebben dan nodig is. De containers kunnen ook worden geconfigureerd om bepaalde netwerktoegang toe te staan, waardoor het systeem mogelijk risico loopt. Het niet beperken van de toegestane systeemoproepen tot deze aanroepen die vereist zijn voor de veilige werking van containers, kan het risico van een geïnfecteerde container verhogen.

Een ander beveiligingsprobleem kan zijn dat de container toegang krijgt tot een gevoelige map van de host of dat de containers de locaties kunnen wijzigen die de basisfunctie van de host beheren.

Rogue-containers zijn niet-geplande containers in een omgeving. Ze kunnen het resultaat zijn van ontwikkelaars die hun code testen in testomgevingen. Deze containers zijn mogelijk niet grondig gescand op beveiligingsproblemen of zijn correct geconfigureerd. Deze beveiligingsproblemen kunnen een toegangspunt openen voor aanvallers.

Het gebruik van basisinstallatiekopieën die niet afkomstig zijn van vertrouwde bronnen of die niet up-to-date zijn met beveiligingsupdates, kan ook leiden tot beveiligingsproblemen in de containers die ze gebruiken om te bouwen.

Risicobeheersmaatregelen

Build-beveiliging gaat over de implementatie van DevSecOps om beveiliging eerder in het ontwikkelproces te integreren en de meeste problemen op te lossen voordat ze verder in de pijplijn terechtkomen. Het gaat er niet om alle verantwoordelijkheid bij ontwikkelaars te leggen, maar om het eigenaarschap te delen met de operationele teams. Ontwikkelaars kunnen vervolgens beveiligingsproblemen en nalevingsproblemen zien en oplossen die ze daadwerkelijk kunnen oplossen.

U kunt een pijplijn bouwen waarmee builds worden gescand en mislukt, omdat deze een of 10 kritieke beveiligingsproblemen heeft. Een betere aanpak is misschien om de volgende laag omlaag te bekijken. U kunt beginnen met het segmenteren van het verantwoordelijkheidspunt op basis van de status van de leverancier.

Stel een drempelwaarde in op de statuslaag van het beveiligingsprobleem. Alles met de status Open, Will not fix of Deferred blijft omlaag stromen in de pijplijn waar SecOps toegang heeft tot het risico, zoals ze nu doen. Een beveiligingsprobleem met de status van beschikbare oplossingen voor leveranciers is iets wat een ontwikkelaar kan aanpakken. Met het gebruik van respijtperioden kunnen ontwikkelaars beveiligingsproblemen oplossen.

Samen met de kwetsbaarheidsbeoordeling is de nalevingsevaluatie. Als u bijvoorbeeld een installatiekopie toestaat om als root te draaien of SSH openstelt, wordt de nalevingshouding van de meeste ondernemingen geschonden. Los dit probleem op tijdens de build in plaats van tijdens de implementatie.

Normaal gesproken scant u uw images met de Docker CIS-benchmark. Wanneer u deze typen processen gebruikt, verstoort u de ontwikkeling niet door beveiligingsverbeteringen door te voeren, maar kunt u de beveiligingspositie van uw bedrijf in het algemeen verbeteren.

Het gebruik van een hulpprogramma dat deze mogelijkheden mogelijk maakt, is essentieel om effectief de juiste strategie voor uw onderneming te implementeren. Traditionele hulpprogramma's kunnen vaak geen beveiligingsproblemen binnen containers detecteren, wat kan leiden tot een onwaar gevoel van beveiliging. Hulpprogramma's die rekening houden met de op pijplijnen gebaseerde build-benadering en de onveranderbare en declaratieve aard van containertechnologieën zijn nodig om uw containerecosysteem goed te beveiligen.

Deze hulpprogramma's moeten de volgende eigenschappen hebben:

  • Integratie met de volledige levensduur van de images, vanaf het begin van het buildproces, naar het register en tot aan de runtime.
  • Zichtbaarheid van kwetsbaarheden op alle lagen van de afbeelding, inclusief de basislaag, toepassingsframeworks en aangepaste software.
  • Beleidsgestuurde afdwinging met het juiste granulariteitsniveau, waardoor uw organisatie kwaliteitscontroles kan maken in elke fase van de build- en deployprocessen.

Registerbeveiliging

Registerbeveiliging gaat over:

  • Driftbesturing van build.
  • Preventie van push/pull van verontreinigde afbeeldingen.
  • Afbeelding ondertekenen.

Grote risico's

Afbeeldingen bevatten vaak bedrijfseigen informatie, waaronder de broncode van een organisatie. Als verbindingen met registers niet adequaat zijn beveiligd, kan de inhoud van een installatiekopie net zo ernstige vertrouwelijkheidsrisico's vormen als elke andere vorm van gegevens die binnen uw organisatie worden verzonden. Verouderde afbeeldingen met kwetsbare, verouderde versies in de register kunnen beveiligingsrisico's verhogen als ze per ongeluk worden geïmplementeerd.

Een ander beveiligingsprobleem kan bestaan uit onvoldoende verificatie- en autorisatiebeperkingen voor containerregisters. Deze registers kunnen gevoelige eigendommen in de afbeeldingen bevatten.

Naarmate inhoud wordt gebouwd en geïmplementeerd, is de distributie van deze inhoud een van de vele aanvalsvectoren. Hoe zorgt u ervoor dat de inhoud die is gefaseerd voor distributie dezelfde inhoud is die wordt geleverd aan een bedoeld eindpunt?

Risicobeheersmaatregelen

Stel implementatieprocessen in om ervoor te zorgen dat ontwikkelhulpprogramma's, netwerken en containerruntimes alleen via versleutelde kanalen zijn verbonden met registers. Zorg er ook voor dat de inhoud afkomstig is van een vertrouwde bron. Om risico's te verminderen van het gebruik van verouderde afbeeldingen:

  • Verwijder onveilige, kwetsbare afbeeldingen die niet meer mogen worden gebruikt uit containerregisters.
  • Dwing toegang tot images af met onveranderbare namen die specifieke versies van images aangeven die moeten worden gebruikt. U kunt deze configuratie implementeren met behulp van een laatste tag of een specifieke versie van de images. Een tag garandeert geen versheid. Om deze reden moet u een proces opzetten om ervoor te zorgen dat de Kubernetes-orchestrator de meest recente unieke nummers gebruikt of dat de meest recente tag de meest up-tobijgewerkte versies vertegenwoordigt.

Toegang tot registers die gevoelige afbeeldingen bevatten, moet verificatie en autorisatie vereisen. Alle schrijftoegang moet ook verificatie vereisen. Met uw beleid kunnen ontwikkelaars bijvoorbeeld alleen afbeeldingen pushen naar de specifieke opslagplaatsen waarvoor ze verantwoordelijk zijn.

Toegang tot deze registers moet federatief zijn en profiteren van toegangsbeleid op bedrijfsniveau. U kunt uw CI/CD-pijplijn bijvoorbeeld zo configureren dat afbeeldingen alleen naar opslagplaatsen worden gepusht nadat ze hebben voldaan aan de nalevingsbeoordeling voor kwetsbaarheidsscans en kwaliteitscontroles hebben doorstaan.

Containerregisters worden tegenwoordig gezien als artefactregisters en worden een voornaamste middel om elk type inhoud te implementeren, niet alleen containerafbeeldingen. Elke cloud biedt een register met opensource-projecten en leveranciersproducten die beschikbaar zijn voor on-premises of privéhosting binnen cloudproviders. Inhoud wordt gepromoveerd binnen en tussen registers, van de eerste build naar de productie-uitrol.

Hoe kunt u ervoor zorgen dat de integriteit van de inhoud die in het register is ingevoerd, dezelfde inhoud is als die uit het register komt? Als u een oplossing voor het ondertekenen van installatiekopieën gebruikt, zorgt u ervoor dat implementaties alleen afkomstig zijn van vertrouwde registers en vertrouwde inhoud implementeren.

Clusterbeveiliging

Clusterbeveiliging gaat over:

  • Verificatie en autorisatie.
  • Netwerkbeveiliging.
  • Kwetsbaarheids- en nalevingsbeheer.

Grote risico's

Soms kan één Kubernetes-cluster worden gebruikt om verschillende toepassingen uit te voeren die worden beheerd door verschillende teams met verschillende vereisten op toegangsniveau. Als toegang wordt verleend aan personen zonder beperkingen of alleen op basis van hun behoeften, kan een kwaadwillende of onzorgvuldige gebruiker de werkbelastingen waartoe zij toegang hebben en andere assets in het cluster in gevaar brengen.

Er kan een ander beveiligingsprobleem optreden wanneer de eigen gebruikersmap van het cluster autorisatie en verificatie beheert. Een directory voor organisatieverificatie wordt vaak strenger beheerd. Omdat deze accounts zeer bevoorrecht zijn en vaker verweesd, neemt de kans op een gecompromitteerd account toe.

Dit scenario kan leiden tot cluster- of zelfs systeemomvattende beveiligingsproblemen. Gegevens die door containervolumes worden opgeslagen, worden beheerd door orchestrators, die toegang moeten hebben tot de gegevens, ongeacht het knooppunt waarop deze worden gehost.

Traditionele netwerkfilters kunnen een beveiligingsblindheid hebben vanwege een netwerkoverlay die is ontworpen om gegevens tijdens overdracht te versleutelen. Dit ontwerp maakt het lastig om verkeer binnen het cluster te bewaken, zodat er mogelijk speciale voorzieningen nodig zijn om Kubernetes-clusters te bewaken.

Verkeer van verschillende toepassingen die hetzelfde cluster delen, kan verschillende gevoeligheidsniveaus hebben, zoals een openbare website en een interne toepassing waarop kritieke gevoelige bedrijfsprocessen worden uitgevoerd. Het delen van hetzelfde virtuele netwerk binnen het cluster kan leiden tot gecompromitteerde gevoelige gegevens. Een aanvaller kan bijvoorbeeld het gedeelde netwerk gebruiken dat wordt blootgesteld aan internet om de interne toepassingen aan te vallen.

Bescherm onderdelen die het cluster zelf draaien tegen kwetsbaarheden en nalevingsproblemen. Zorg ervoor dat u de meest recente versie van Kubernetes gebruikt om te profiteren van het herstel.

Risicobeheersmaatregelen

Gebruikerstoegang voor Kubernetes-clusters moet gebruikmaken van een toegangsmodel met minimale bevoegdheden. Geef gebruikers alleen toegang om specifieke acties uit te voeren op specifieke hosts, containers en installatiekopieën die ze nodig hebben om hun werk te doen. Testteamleden moeten beperkte of geen toegang hebben tot containers in productie. Gebruikersaccounts met toegang voor het hele cluster moeten nauw worden beheerd en spaarzaam worden gebruikt.

Gebruik sterke verificatiemethoden zoals meervoudige verificatie om de toegang tot deze accounts te beveiligen. Een gebruikersmap van een organisatie moet worden gebruikt voor het beheren van clusters via eenmalige aanmelding in plaats van clusterspecifieke gebruikersaccounts die mogelijk niet hetzelfde niveau van beleid en besturingselementen hebben.

Gebruik versleutelingsmethoden waarmee containers toegang hebben tot gegevens, ongeacht de host waarop de containers worden uitgevoerd. Deze versleutelingshulpprogramma's moeten onbevoegde toegang tot gegevens door andere containers voorkomen, zelfs binnen hetzelfde knooppunt dat er geen toegang toe mag hebben.

Configureer Kubernetes-clusters om netwerkverkeer te scheiden in afzonderlijke virtuele netwerken of subnetten op gevoeligheidsniveau. Segmentatie per toepassing kan ook mogelijk zijn, maar het definiëren van netwerken op basis van gevoeligheidsniveaus kan voldoende zijn. Virtuele netwerken voor klantgerichte toepassingen, gescheiden van toepassingen die interne toepassingen bedienen met gevoelig verkeer, moeten bijvoorbeeld minimaal worden geïmplementeerd.

U kunt taints en tolerations gebruiken om implementaties te isoleren naar specifieke sets knooppunten op basis van gevoeligheidsniveaus. Vermijd het hosten van zeer gevoelige workloads op hetzelfde knooppunt als workloads met een lagere gevoeligheid. Het gebruik van afzonderlijke beheerde clusters is een veiligere optie.

Segmenteer containers op doel, gevoeligheid en threadpostuur om extra bescherming te bieden voor gevoelige workloads. Door containers op deze manier te segmenteren, is het moeilijker voor een aanvaller die toegang heeft verkregen tot één segment om toegang te krijgen tot andere segmenten. Deze configuratie heeft het extra voordeel dat restgegevens, zoals caches of volumekoppelingen, worden geïsoleerd op gevoeligheidsniveau.

Kubernetes-clusters moeten worden geconfigureerd voor:

  • Een beveiligde omgeving bieden voor toepassingen die erop worden uitgevoerd.
  • Zorg ervoor dat knooppunten veilig worden toegevoegd aan het cluster.
  • Permanente identiteiten hebben om de beveiliging gedurende hun hele levenscyclus te waarborgen.
  • Geef live, nauwkeurige informatie over de status van het cluster, inclusief netwerken en de knooppunten hierin.

Het moet eenvoudig zijn om een gecompromitteerd knooppunt te isoleren en te verwijderen uit het cluster zonder dat dit van invloed is op de prestaties van het cluster. AKS maakt dat eenvoudig.

Definieer configuratiestandaarden voor containerruntime om automatisch te zorgen voor naleving. Er zijn veel beleidsregels in Azure die dit proces eenvoudig maken en gebruikers kunnen ook hun eigen beleid maken. Gebruik Azure-beveiligingsfuncties om voortdurend configuratie-instellingen in de hele omgeving te evalueren en ze actief af te dwingen.

Zorg er automatisch voor dat beveiligingsproblemen van de Kubernetes-onderdelen worden aangepakt. Gebruik afzonderlijke omgevingen voor ontwikkeling, testen en productie, elk met hun eigen besturingselementen en op rollen gebaseerd toegangsbeheer (RBAC) voor containerbeheer. Koppel alle containers aan afzonderlijke gebruikersidentiteiten en moet worden geregistreerd voor controle. Deze configuratie helpt bij het verminderen van het risico van rogue containers.

Knooppuntbeveiliging

Knooppuntbeveiliging gaat over:

  • Runtimebeveiliging.
  • Kwetsbaarheids- en nalevingsbeheer.

Grote risico's

Een werkknop heeft uitgebreide toegang tot alle onderdelen op het knooppunt. Aanvallers kunnen elke service die toegankelijk is voor het netwerk gebruiken als toegangspunt, zodat het bieden van toegang tot de host vanaf meerdere punten de kwetsbaarheid voor aanvallen ernstig kan verhogen. Hoe groter de kwetsbaarheid voor aanvallen, hoe groter de kans dat een aanvaller toegang krijgt tot het knooppunt en het bijbehorende besturingssysteem.

Bovendien hebben containerspecifieke besturingssystemen zoals die worden gebruikt in AKS-knooppunten een kleinere kwetsbaarheid voor aanvallen, omdat ze geen bibliotheken bevatten waarmee reguliere besturingssystemen databases en webservers rechtstreeks kunnen uitvoeren. Het gebruik van een gedeelde kernel resulteert in een groter aanvalsoppervlak voor containers die in dezelfde omgeving worden uitgevoerd dan containers in afzonderlijke virtuele machines. Dit is zelfs het geval wanneer containerspecifieke besturingssystemen die worden uitgevoerd op AKS-knooppunten in gebruik zijn.

Hostbesturingssystemen bieden basissysteemonderdelen die beveiligingsproblemen en nalevingsrisico's kunnen hebben. Omdat ze onderdelen op laag niveau zijn, kunnen hun beveiligingsproblemen en configuratie van invloed zijn op alle containers die worden gehost. AKS beschermt gebruikers door ervoor te zorgen dat deze kwetsbaarheden worden aangepakt via regelmatige besturingssysteemupdates op de nodes die op AKS draaien, en de nalevingshouding van de werkernodes behouden blijft.

Onjuiste gebruikerstoegangsrechten kunnen ook leiden tot beveiligingsrisico's wanneer gebruikers zich rechtstreeks bij de knooppunten aanmelden om de containers te beheren in plaats van via het AKS-besturingsvlak. Als u zich rechtstreeks aanmeldt, kan de gebruiker wijzigingen aanbrengen in toepassingen die verder gaan dan de toepassingen waarvoor ze toegang moeten hebben.

Schadelijke containers kunnen ook leiden tot manipulatie van het bestandssysteem van het besturingssysteem. Als een container bijvoorbeeld een gevoelige map in het hostbesturingssystem mag koppelen, kan die container wijzigingen aanbrengen in de bestanden. De wijzigingen kunnen van invloed zijn op de beveiliging van andere containers die op de host worden uitgevoerd.

Risicobeheersmaatregelen

Beperk knooppunttoegang door SSH-toegang te beperken.

Het gebruik van het containerspecifieke besturingssysteem in AKS-knooppunten vermindert meestal de kwetsbaarheid voor aanvallen omdat andere services en functionaliteiten zijn uitgeschakeld. Ze hebben ook alleen-lezen bestandssystemen en maken standaard gebruik van andere clusterversterkingsmaatregelen.

Op het Azure-platform worden beveiligingspatches voor het besturingssysteem automatisch 's nachts toegepast op Linux- en Windows-knooppunten. Als een beveiligingsupdate van een Linux-besturingssysteem vereist dat opnieuw wordt opgestart, dan zal het niet automatisch opnieuw opstarten. AKS biedt mechanismen voor het opnieuw opstarten om deze specifieke patches toe te passen.

Microsoft Defender voor Servers is niet van toepassing op AKS Linux- en Windows-knooppunten omdat Microsoft het besturingssysteem beheert. Als er geen andere virtuele machines zijn in het abonnement waarin AKS is geïmplementeerd, kunt u Microsoft Defender voor Servers veilig uitschakelen.

Als de omgeving is geïmplementeerd, inclusief het aanbevolen Azure-beleid voor landingszones op ondernemingsniveau, kunt u een uitsluiting configureren voor de beleidstoewijzing in de beheergroep waarmee Microsoft Defender for Servers automatisch onnodige kosten voorkomt.

Toepassingsbeveiliging

Toepassingsbeveiliging gaat over:

  • Runtimebeveiliging.
  • Kwetsbaarheden- en nalevingsbeheer.

Grote risico's

Afbeeldingen zijn bestanden die alle componenten bevatten die nodig zijn om een applicatie uit te voeren. Wanneer de nieuwste versies van deze onderdelen worden gebruikt om installatiekopieën te maken, zijn ze mogelijk op dat moment vrij van bekende beveiligingsproblemen, maar kunnen ze snel veranderen.

U moet deze bestanden up-to-date houden met de nieuwste versies, omdat pakketontwikkelaars regelmatig beveiligingsproblemen identificeren. Breng containerupdates eerder in het proces aan door de afbeeldingen bij te werken die worden gebruikt om de containers te maken, in tegenstelling tot traditionele toepassingen, die doorgaans worden bijgewerkt op de host.

Schadelijke bestanden kunnen ook worden ingesloten in een afbeelding, die vervolgens kan worden gebruikt om andere containers of onderdelen van het systeem aan te vallen. Containers van derden kunnen een mogelijke aanvalsvector zijn. Specifieke details zijn mogelijk onbekend en ze kunnen gegevens lekken. Misschien zijn de containers niet up-to-date gehouden met vereiste beveiligingsupdates.

Een andere aanvalsvector is het gebruik van het insluiten van geheimen, zoals wachtwoorden en verbindingsreeksen, rechtstreeks in een installatiekopieënbestandssysteem. Deze procedure kan een beveiligingsrisico veroorzaken omdat iedereen met toegang tot de afbeelding toegang kan verkrijgen tot de geheimen.

Er kunnen fouten zijn in de toepassingen zelf, zoals toepassingen die kwetsbaar zijn voor cross-site scripting of SQL-injectie. Als er fouten zijn, kan het beveiligingsprobleem worden gebruikt om onbevoegde toegang tot gevoelige informatie in andere containers of zelfs het host-besturingssysteem in te schakelen.

Met de AKS-containerruntime kunt u eenvoudig controleren op beveiligingsproblemen met behulp van de verschillende beveiligingshulpprogramma's die beschikbaar zijn in Azure. Zie Inleiding tot Microsoft Defender voor Kubernetes voor meer informatie.

U moet ook uitgaand netwerkverkeer beheren dat naar containers wordt verzonden om ervoor te zorgen dat containers geen verkeer kunnen verzenden tussen netwerken met verschillende gevoeligheidsniveaus, zoals omgevingen die beveiligde gegevens of internet hosten. Azure maakt dit beheer eenvoudig met de verschillende netwerk- en AKS-beveiligingsfuncties.

Kubernetes-planners richten zich standaard op het stimuleren van schaalaanpassing en het maximaliseren van de dichtheid van workloads die worden uitgevoerd op knooppunten. Ze kunnen pods met verschillende gevoeligheidsniveaus in hetzelfde knooppunt plaatsen, alleen omdat die host de meest beschikbare resources heeft. Dit scenario kan mogelijk leiden tot beveiligingsincidenten wanneer aanvallers toegang gebruiken tot openbare workloads om containers aan te vallen die gevoeligere processen op dezelfde host uitvoeren. Een geïnfecteerde container kan ook worden gebruikt om het netwerk te scannen om andere beveiligingsproblemen te vinden die de aanvaller kan misbruiken.

Risicobeheersmaatregelen

Sla nooit geheimen op in toepassingscode of bestandssystemen. Geheimen moeten indien nodig worden opgeslagen in sleutelarchieven en aan containers worden verstrekt tijdens runtime. AKS kan ervoor zorgen dat alleen containers die toegang nodig hebben tot bepaalde sleutels toegang tot deze sleutels hebben en dat deze geheimen niet op schijf worden bewaard. Azure Key Vault kan deze geheimen bijvoorbeeld veilig opslaan en indien nodig aan het AKS-cluster verstrekken. Het is ook eenvoudig om ervoor te zorgen dat deze geheimen zowel in opslag als in transit worden versleuteld.

Vermijd het gebruik van niet-vertrouwde installatiekopieën en registers en zorg ervoor dat alleen installatiekopieën van vertrouwde sets mogen worden uitgevoerd in hun clusters. Voor een meerlaagse benadering:

  • Bepaal centraal welke afbeeldingen en registers worden vertrouwd.
  • Identificeer elke afbeelding op discrete wijze op cryptografische handtekening.
  • Stel beleid vast dat ervoor zorgt dat alle hosts alleen images uitvoeren die afkomstig zijn uit de goedgekeurde set.
  • Valideer deze handtekeningen vóór de uitvoering.
  • Deze installatiekopieën en registers bewaken en bijwerken naarmate beveiligingsproblemen en configuratievereisten veranderen.

Beveiligde computerprofielen moeten worden gebruikt om containers te beperken en tijdens de uitvoering toe te wijzen. Aangepaste profielen kunnen worden gemaakt en doorgegeven aan containerruntimes om hun mogelijkheden verder te beperken. Zorg er minimaal voor dat containers worden uitgevoerd met de standaardprofielen. Overweeg aangepaste, beperktere profielen te gebruiken voor containers met toepassingen met een hoog risico.

Hulpprogramma's kunnen toepassingen automatisch profileren met behulp van gedragsleer en afwijkingen detecteren. U kunt oplossingen van derden gebruiken om afwijkingen tijdens runtime te detecteren. Afwijkingen kunnen gebeurtenissen bevatten zoals:

  • Ongeldige of onverwachte procesuitvoering of systeemoproepen.
  • Wijzigingen in beveiligde configuratiebestanden en binaire bestanden.
  • Schrijft naar onverwachte locaties en bestandstypen.
  • Het creëren van onverwachte netwerklisteners.
  • Verkeer dat wordt verzonden naar onverwachte netwerkbestemmingen.
  • Opslag en uitvoering van malware.

Microsoft Defender voor Kubernetes investeert momenteel in dit gebied.

Containers moeten worden uitgevoerd met hun hoofdbestandssysteem in de modus Alleen-lezen om schrijfbewerkingen te isoleren naar gedefinieerde mappen, die deze hulpprogramma's eenvoudig kunnen bewaken. Deze configuratie maakt containers toleranter voor inbreuk, omdat u manipulatie op deze specifieke locaties isoleert. Ze kunnen eenvoudig worden gescheiden van de rest van de toepassing.

Ontwerpoverwegingen

AKS heeft verschillende interfaces voor andere Azure-services, zoals Microsoft Entra ID, Azure Storage en Azure Virtual Network. Het gebruik van deze services vereist speciale aandacht tijdens de planningsfase. AKS voegt ook extra complexiteit toe waarvoor u dezelfde beveiligingsgovernance- en nalevingsmechanismen en -controles moet toepassen als in de rest van uw infrastructuurlandschap.

Hier volgen enkele andere ontwerpoverwegingen voor AKS-beveiligingsgovernance en -naleving:

  • Als u een AKS-cluster maakt in een abonnement dat is geïmplementeerd volgens best practices voor landingszones op ondernemingsniveau, moet u vertrouwd raken met het Azure-beleid dat de clusters overnemen. Zie Beleidsregels die zijn opgenomen in Azure-landingszones, naslaginformatie over implementaties voor meer informatie.
  • Bepaal of het besturingsvlak van het cluster toegankelijk moet zijn via internet (ip-beperkingen wordt aanbevolen), wat de standaardinstelling is, of alleen vanuit uw privénetwerk in Azure of on-premises als een privécluster. Als uw organisatie de best practices voor landingszones op ondernemingsniveau volgt, heeft de Corp beheergroep een Azure Policy gekoppeld waarmee clusters privé moeten zijn. Zie Beleidsregels die zijn opgenomen in Azure-landingszones, naslaginformatie over implementaties voor meer informatie.
  • Evalueer het gebruik van de ingebouwde AppArmor Linux-beveiligingsmodule om acties te beperken die containers kunnen uitvoeren, zoals lezen, schrijven, uitvoeren of systeemfuncties zoals het koppelen van bestandssystemen. Alle abonnementen hebben bijvoorbeeld Azure-beleid waarmee wordt voorkomen dat pods in alle AKS-clusters bevoegde containers maken. Zie Beleidsregels opgenomen in referentie-implementaties van Azure-landingszones voor meer informatie.
  • Evalueer het gebruik vanseccomp (beveiligde computing) op procesniveau om de procesoproepen te beperken die containers kunnen uitvoeren. De Azure Policy die wordt toegepast als onderdeel van de generieke ondernemingsbrede implementatie van de landingszone in de beheergroep voor landingszones om te voorkomen dat containerprivileges escaleren naar root, gebruikt seccomp via Azure-policy's voor Kubernetes.
  • Bepaal of uw containerregister toegankelijk is via internet of alleen binnen een specifiek virtueel netwerk. Het uitschakelen van internettoegang in een containerregister kan negatieve gevolgen hebben voor andere systemen die afhankelijk zijn van openbare connectiviteit om er toegang toe te krijgen. Voorbeelden hiervan zijn pijplijnen voor continue integratie of Microsoft Defender voor het scannen van afbeeldingen. Zie Privé verbinding maken met een containerregister met behulp van Azure Private Link voor meer informatie.
  • Bepaal of uw privécontainerregister wordt gedeeld tussen meerdere landingszones of als u een toegewezen containerregister implementeert voor elk landingszoneabonnement.
  • Overweeg het gebruik van een beveiligingsoplossing zoals Microsoft Defender voor Kubernetes voor detectie van bedreigingen.
  • Overweeg uw containerinstallatiekopieën te scannen op beveiligingsproblemen.
  • Overweeg Om Microsoft Defender for Servers in het AKS-abonnement uit te schakelen als er geen niet-AKS virtuele machines zijn, om onnodige kosten te voorkomen.

Ontwerpaanaanvelingen

Belangrijk

Microsoft Defender for Cloud-afbeeldingsscanning is niet compatibel met Container Registry-eindpunten. Zie Privé verbinding maken met een containerregister met behulp van Private Link voor meer informatie.