Veel organisaties zijn bezig met de integratie van containers in hun IT-infrastructuur of hebben deze al ingevoerd. Containers zijn nuttig omdat ze een soort technologie zijn die alles omvat wat nodig is om een applicatie uit te voeren, inclusief de runtime-afhankelijkheden. Deze eigenschap maakt een container herhaalbaar in verschillende cloud- en OS-omgevingen; het opnemen van afhankelijkheden betekent dat een container hetzelfde uitgevoerd wordt, ongeacht de hostinfrastructuur.
Dat is niet het enige voordeel van containers. Volgens NetApp hebben containers minder overhead nodig dan virtuele machines en andere traditionele IT-middelen, omdat ze geen OS images bevatten. Ze verbeteren ook de flexibiliteit van de organisatie om aan de veranderende bedrijfsbehoeften te voldoen doordat applicaties sneller geïmplementeerd, gepatcht en geschaald kunnen worden.
In de loop van de tijd kunnen containers zo talrijk worden dat het DevOps-team ze niet meer alleen kan controleren. Daar komt Kubernetes in beeld. Zoals uitgelegd op haar website fungeert Kubernetes als een platform waarmee organisaties hun containers kunnen beheren. Deze organisatiedienst helpt het netwerkverkeer te distribueren, zodat de uitrol stabiel blijft, waardoor de beschikbaarheid van de service gegarandeerd is. Het systeem start containers die falen ook opnieuw op en elimineert containers die niet reageren op een door de organisatie gedefinieerde gezondheidscontrole.
Zorgen over complexiteit
Ondanks de hierboven genoemde voordelen dragen containers en Kubernetes wel degelijk bij aan de complexiteit van het netwerk van een organisatie. Dergelijke complexiteit kan leiden tot veiligheidsuitdagingen.
Neem bijvoorbeeld containers. Zoals StackRox uitlegt, vergroot een instroom van containers het aantal onderdelen van de cloud-infrastructuur waarop beveiligingsteams toezicht moeten houden. Dit bemoeilijkt het proces van het consequent implementeren van fundamentele beveiligingsmaatregelen zoals het scannen op kwetsbaarheden en veilig configuratiebeheer. Meer containers betekent meer blinde vlekken die een aanvaller zou kunnen misbruiken.
Afhankelijk van hoe uitgebreid containers met andere containers en pods kunnen communiceren, kan een kwaadwillende acteur deze zwakke punten misbruiken om zich lateraal door de containeromgeving te bewegen en bepaalde containers met schadelijke code te compromitteren. Dat is een probleem. Zonder goed toezicht zou die malware samen met andere code, binaire bestanden en bibliotheken in een containerimage terecht kunnen komen. Gebruikers die dat image uit een opslagplaats halen, kunnen zich dan onbedoeld met die code besmetten.
Kubernetes is ontworpen om de implementatie van applicaties te versnellen en bewerkingen te vereenvoudigen. Omdat het platform deze snelheid en het gebruiksgemak verhoogt met een reeks netwerkbeleid die alle pods standaard met elkaar laat communiceren, kan dit het voor een aanvaller nog gemakkelijker maken om een pod te compromitteren en in de hierboven beschreven aanvalsketen te lanceren.
Het belang van weten wat te vertrouwen
De beveiligingsuitdagingen die in het vorige gedeelte zijn besproken, benadrukken de noodzaak voor organisaties om te weten wat ze kunnen vertrouwen. Een belangrijk onderdeel van het opbouwen van dit vertrouwen is het gebruik van digitale certificaten.
Venafi stelt specifiek dat organisaties hun containers en Kubernetes-omgevingen het best kunnen beveiligen door digitale certificaten te gebruiken als machine-identiteiten. Toch kunnen organisaties geen handmatige benadering kiezen voor het levenscyclusbeheer van certificaten met containers en Kubernetes. De constante noodzaak om X.509-certificaten aan te maken, te configureren en te implementeren in een poging om gelijke tred te houden met de veranderende containerbehoeften van de organisatie, kan het softwareontwikkelingsproces van de organisatie vertragen. Ze zouden dagen moeten wachten om een certificaat te krijgen. Dit is problematisch omdat veel containers niet eens zo lang actief blijven.
Als reactie hierop zouden DevOps-teams ervoor kunnen kiezen om beveiligingsprocessen te omzeilen om hun ontwikkelingsdoelen te blijven nastreven. Zoals opgemerkt door DZone:
“DevOps-teams proberen vaak een weg rond het probleem te vinden, in sommige gevallen met behulp van onbetrouwbare of niet-geautoriseerde certificaten … In andere gevallen gebruiken DevOps-teams helemaal geen certificaten. Beide benaderingen maken het lastig om bedreigingen tijdig te identificeren en te beperken. Zonder HTTPS-encryptie kunnen gegevens worden blootgesteld aan aanvallers.”
De uitdagingen van certificaten voor containers en Kubernetes aanpakken
Organisaties kunnen de bovenstaande uitdagingen het hoofd bieden door automatisering te integreren in hun implementatie van X.509-certificaten. Volgens DZone draagt automatisering bij aan de modernisering van het DevOps-proces. Het zorgt voor een effectieve overgang van DevOps naar DevSecOps door beveiliging in de levenscyclus van softwareontwikkeling te integreren. Het doet dit door beveiligings- en PKI-teams in te zetten en hen verantwoordelijk te maken voor digitale certificaten in plaats van DevOps-medewerkers te dwingen om het voortouw te nemen. Als zodanig kunnen beveiligings- en PKI-medewerkers ervoor zorgen dat alle certificaten gestandaardiseerd zijn om te voldoen aan de regelgeving en het beveiligingsbeleid van de organisatie.
Als het gaat om automatisering moeten organisaties ervoor zorgen dat hun Kubernetes-omgeving wordt geïntegreerd met een geautomatiseerd systeem voor het uitgeven van certificaten. Hiervoor kunnen ze de Jetstack Certificate Manager gebruiken om de levenscyclus van certificaten voor Kubernetes-clusters te automatiseren.
Klik hier voor stapsgewijze instructies over hoe u deze vorm van automatisering kunt implementeren voor de behoeften van uw organisatie op het gebied van certificaatbeheer.
