Delen via

Beveiliging voor AKS

  • Artikel

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.

Kwetsbaarheid voor aanvallen

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

  • Build
  • Register
  • Cluster
  • Knooppunt
  • Toepassing

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

Beveiliging bouwen

Buildbeveiliging gaat over het juiste gebruik van DevSecOps met containerinstallatiekopieën.

Grote risico's

Slechte configuratie van installatiekopieën kan leiden tot beveiligingsproblemen in de pijplijn. U hebt bijvoorbeeld containers met meer bevoegdheden dan ze nodig hebben. 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.

Risicometeritems

Build-beveiliging gaat over de implementatie van DevSecOps om de beveiliging naar links te verplaatsen en de meeste problemen op te lossen voordat ze de pijplijn gaan verplaatsen. Het gaat niet om het allemaal eigendom van ontwikkelaars te plaatsen, maar om het eigendom te delen met bewerkingen. 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 evaluatie van beveiligingsproblemen is de nalevingsevaluatie. Als u bijvoorbeeld een installatiekopie toestaat als hoofdmap of SSH weergeeft, wordt de nalevingspostuur van de meeste ondernemingen verbroken. Los dit probleem op tijdens de build in plaats van tijdens de implementatie.

Normaal gesproken scant u uw installatiekopieën op basis van de Docker CIS-benchmark. Wanneer u deze typen stromen gebruikt, breekt u de ontwikkeling niet door beveiligingsherstel in te voeren, maar u kunt het beveiligingspostuur van uw bedrijf inline 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 installatiekopieën, vanaf het begin van het buildproces tot het register tot de runtime.
  • Zichtbaarheid van beveiligingsproblemen op alle lagen van de installatiekopieën, inclusief de basislaag van de installatiekopieën, toepassingsframeworks en aangepaste software.
  • Door beleid gestuurde afdwinging met het juiste granulariteitsniveau, waardoor uw organisatie kwaliteitspoorten kan maken in elke fase van de build- en implementatieprocessen.

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 op de juiste wijze zijn beveiligd, kan de inhoud van een installatiekopie vertrouwelijkheidsrisico's vormen als elke andere vorm van gegevens die binnen uw organisatie worden verzonden. Verouderde installatiekopieën met kwetsbare verouderde versies in het 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 eigendomsactiva in de installatiekopieën 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?

Risicometeritems

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 installatiekopieën:

  • Verwijder onveilige, kwetsbare installatiekopieën die niet meer mogen worden gebruikt uit containerregisters.
  • Dwing toegang tot installatiekopieën af met onveranderbare namen waarmee bepaalde versies van installatiekopieën worden opgegeven die moeten worden gebruikt. U kunt deze configuratie implementeren met behulp van een nieuwste tag of een specifieke versie van de installatiekopieën. Een tag garandeert geen versheid. Stel daarom een proces in om ervoor te zorgen dat de Kubernetes-orchestrator de meest recente unieke nummers gebruikt of dat de meest recente tag de meest recente versies vertegenwoordigt.

Toegang tot registers die gevoelige installatiekopieën bevatten, moeten verificatie en autorisatie vereisen. Alle schrijftoegang moet ook verificatie vereisen. Met uw beleid kunnen ontwikkelaars bijvoorbeeld alleen installatiekopieën 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 installatiekopieën alleen naar opslagplaatsen worden gepusht nadat ze nalevingsbeoordeling en kwaliteitscontroles voor het scannen van beveiligingsproblemen hebben doorstaan.

Containerregisters worden nu beschouwd als artefactregisters een primaire manier om elk inhoudstype te implementeren, niet alleen containerinstallatiekopieën. 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 hun eerste build naar hun productie-implementatie.

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.
  • Beveiligings- 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 werkbelastingen in gevaar komen die ze toegang hebben tot en andere assets in het cluster.

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 bevoorrechte en vaker zwevende accounts zijn, 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.

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

Risicometeritems

Gebruikerstoegang voor Kubernetes-clusters moet gebruikmaken van een toegangsmodel met minimale bevoegdheden. Verleent gebruikers alleen toegang om specifieke acties uit te voeren op specifieke hosts, containers en installatiekopieën die nodig zijn om hun taken uit te voeren. 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 toleranties gebruiken om implementaties te isoleren voor specifieke sets knooppunten op gevoeligheidsniveaus. Vermijd het hosten van zeer gevoelige workloads binnen hetzelfde knooppunt als die workloads met lagere vertrouwelijkheden. 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.
  • Beveiligings- en nalevingsbeheer.

Grote risico's

Een werkrolknooppunt 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 beveiligingsproblemen worden uitgevoerd via regelmatige updates van het besturingssysteem op knooppunten die worden uitgevoerd op AKS, en de nalevingsstatus van het werkknooppunt wordt gehandhaafd.

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.

Risicometeritems

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 clusterbeveiligingsprocedures.

Op het Azure-platform worden beveiligingspatches voor het besturingssysteem automatisch 's nachts toegepast op Linux- en Windows-knooppunten. Als voor een beveiligingsupdate van een Linux-besturingssysteem opnieuw moet worden opgestart, wordt deze niet automatisch opnieuw opgestart. 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.
  • Beveiligings- en nalevingsbeheer.

Grote risico's

Installatiekopieën zijn bestanden die alle onderdelen bevatten die nodig zijn om een toepassing 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 verder upstream door de installatiekopieën 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 verbindingsreeks s rechtstreeks in een installatiekopieënbestandssysteem. Deze procedure kan een beveiligingsrisico veroorzaken omdat iedereen met toegang tot de installatiekopieën toegang kan krijgen 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.

Risicometeritems

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 installatiekopieën en registers worden vertrouwd.
  • Identificeer elke afbeelding op discrete wijze op cryptografische handtekening.
  • Plaats beleidsregels die ervoor zorgen dat alle hosts alleen installatiekopieën uitvoeren die afkomstig zijn van de goedgekeurde set.
  • Valideer deze handtekeningen vóór de uitvoering.
  • Deze installatiekopieën en registers bewaken en bijwerken naarmate beveiligingsproblemen en configuratievereisten veranderen.

Beveiligde computingprofielen moeten worden gebruikt om containers te beperken en tijdens runtime 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.
  • Schrijfbewerkingen naar onverwachte locaties en bestandstypen.
  • Het maken 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 die zijn opgenomen in Azure-landingszones, naslaginformatie over implementaties voor meer informatie.
  • Evalueer het gebruik van seccomp (beveiligde computing) op procesniveau om de procesoproepen te beperken die containers kunnen uitvoeren. Het Azure Policy dat wordt toegepast als onderdeel van de algemene implementatie van landingszones op ondernemingsniveau in de beheergroep voor landingszones om escalatie van containerbevoegdheden naar hoofdgebruik seccomp te voorkomen via Azure-beleid 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 voor Cloud scannen van installatiekopieën is niet compatibel met Container Registry-eindpunten. Zie Privé verbinding maken met een containerregister met behulp van Private Link voor meer informatie.