Je hebt een deadline and je hebt klanten beloofd om je nieuwe platform beschikbaar te stellen. Iedereen werkt hard en je hebt moeite om de deadline te halen. En vlak voor die deadline vraagt iemand “Hebben we aan security gedacht?”
De kans is groot dat je een oplossing hebt gebouwd waarin data wordt verwerkt en in potentie ook opgeslagen. Heb je wel nagedacht over hoe je kwaadwillende buiten gaat houden? Wanneer je druk bezig bent om je oplossing te bouwen en om die deadline te halen, schiet het onderwerp security er nog wel eens bij in. Als het gaat om Azure Kubernetes Services, waar moet je dan aan denken en op letten?
Een Kubernetes cluster is niet “secure by default”. Wanneer je de standaard depoyment uitvoert (laten we het next, next, finish noemen), moet je nog een aantal keer terug naar de tekentafel om de juiste security maatregelen te implementeren. Klinkt toch als iets wat je vanaf het begin goed neer wilt zetten toch? Niet getreurd, dit scenario komt heel vaak voor en daarom willen we je meenemen in de best practices die wij zien, implementeren en adviseren.
Authenticatie en authorisatie
Standaard wordt er met de deployment van AKS ook een zogenaamde Kube Config file gecreëerd. Deze file bevat ook benodigde informatie om toegang tot het cluster te krijgen. Wanneer je deze file hebt betekent het doorgaans dat je admin-level toegang hebt tot het cluster. Super handig maar niet altijd wenselijk in productie scenarios. Deze file wil je in ieder geval niet laten slingeren. Om het risico te beperken zijn er additionele authenticatie en autorisatie technologieën benodigd. We kunnen dit bewerkstelligen door ons cluster te integreren met Azure Active Directory. Hiermee introduceren we de requirements om lid te zijn van een Azure AD groep en op basis van deze groepen toegang te verlenen tot functionaliteiten in het cluster. Het is een eenvoudig proces maar hiermee dwingen we wel Azure AD authenticatie af wanneer je met het cluster wilt verbinden voor beheerwerkzaamheden. Hiermee kun je ook namespaces op security niveau gaan scheiden. Eén team heeft toegang tot namespace A en één team heeft toegang tot namespace B.
Deze rollen configureren gebeurt op basis van de welkbekende YAML files. Door het configureren van Roles en RoleBindings kunnen we dit realiseren.
De zogenaamde Role legt vast welke toegang er is, de RoleBinding koppelt deze Role aan een user of group uit Azure Active Directory.
Het klinkt vrij simpel maar het is belangrijk dat je dit zo snel mogelijk na het bouwen van je cluster configureert. Het later aanpassen van rollen kan resulteren in onverwachte scenarios (want als iemand een deployment vanuit de pipeline op basis van zijn eigen user access heeft configureert), ik weet.. Dat mag eigenlijk niet maar het gebeurd toch. Wanneer je dan een dergelijke integratie en wijziging introduceert kan dit betekenen dat je pipeline stopt met werken. In een productiescenario een behoorlijk vervelende ervaring.
Op dit moment is Azure Role Based Access Control for AKS, in preview. Hiermee kun je ook Azure Rollen toekennen aan users waarmee dit proces nog veel eenvoudiger wordt. Houdt de releases en aankondigingen in de gaten om in de toekomst ook gebruik te maken van deze feature.
Gebruik Managed Identity
Wanneer je al gebruik maakt van Azure, zal wellicht al te maken hebben gehad met het concept van “managed identity”. Wanneer AKS communiceert met het Azure platform zelf (bijvoorbeeld om een Application Gateway te configureren of een Azure Container Registry benadert), dan heeft het cluster toegang nodig tot de subscription. Om dit te bewerkstelligen heb je twee opties: Sergice Principals of Managed Identity.
Het gebruikt van een Service Principal betekent dat je er eentje moet aanmaken, toegang moet geven en de lifecycle van de service principal moet beheren (bijvoorbeeld het wijzigen van de key wanneer deze verloopt). Wanneer je er meerdere gebruikt kan dit nog wel een een gecompliceerd scenario worden wat niemand meer durft aan te raken in een productiescenario en dat de keys van de service principal ergens zijn opgeslagen en misschien ook wel door users/admins zelf worden gebruikt. Het alternatief is het gebruik van een Managed Identity.
Een managed identity is in principe een wrapper over een Service Principal en het life cycle management wordt voor jou gedaan. Het configureren neemt niet meer tijd in beslag dan dat je een Service Principal zou aanmaken, maar je krijgt nu een lijstje aan voordelen. Het lifecycle management wordt voor jou gedaan, key rotation vindt automatisch plaats en users kunnen deze managed identity niet zomaar gebruiken. Het aanmaken van een managed identity voor AKS doe je doorgaans tijdens het uitrollen van je cluster en vergt niets meer dan het toevoegen van een parameter. Azure Resource Manager doet de rest.
Houdt er rekening mee dat een Managed Identity de lifecycle van het cluster deelt. Wanneer je het cluster verwijdert, wordt ook de identity verwijderd. Het gebruik van “bring your own identity” is op dit moment nog in preview voor een beperkt aantal features, hiermee zou je wel de lifecycle kunnen loskoppelen van het cluster.
Azure Policy
Azure Policy kan niet alleen worden gebruikt voor het managen van security en compliance op het niveau van Azure Resource Manager zelf. Wist je dat je dit ok kunt gebruiken om ervoor dat zorgen dat je pod specificaties voldoen aan de standaard?
Op dit moment kun je alleen nog built-in policies gebruiken maar het is wel een out-of-the-box instant improvement als het gaat om security en compliance. Het kost wel iets meer resource, maar dat is te overzien. Belangrijk om te weten: dit wordt ook in hybride scenarios met Azure Arc ondersteunt! Je kunt hier een overzicht vinden met de al beschikbare policies.
Deze policies bevatten onder andere checks op de configuratie van je Ingress (gebruik je HTTPS?), het niet beschikbaar stellen van publieke IP adressen op services en controle op het gebruik van labels.
Het kost weinig moeite maar neemt een hoop handmatige controles weg, gewoon configureren dus.
Netwerk beveiliging
Ik kom veel omgevingen tegen waar netwerk beveiliging en policies niet zijn geïmplementeerd. Om eerlijk te zijn; tijdens een project doe ik dat ook niet altijd. Waarom? Het beperken van toegang kan lastig zijn wanneer je een nieuwe omgeving gaat uitrollen en testen. Maar toch moeten we hiermee aan de slag want, moet iedere pod met het internet verbinden of moet iedere pod met elkaar kunnen communiceren? Waarschijnlijk niet. Als we dit goed configureren dan hoeft dit niet in de weg te zetten. Werk je met meerdere mensen in een project die hier minder ervaring mee hebben? De oplossing is communicatie en training, neem daar de tijd voor.
Het implementeren van netwerk doe je met behulp van network policy definitions. Wees niet bang, je hoeft dit niet voor iedere specifiek pod te doen. We kunnen wederom labels gebruiken om het netwerk te beveiligen. De policy kijkt naar welk label de policy moet ontvangen en configureert dit voor iedere pod welke een dergelijke label heeft.
Maar het gaat nog verder. We kunnen dit ook op namespace niveau doen waarmee in combinatie met de eerder beschreven role based access control maatregelen de namespace wel degelijk een serieuze security boundary wordt. Goed om in te verdiepen, liever eerder dan later ☹
Azure Defender voor Kubernetes
Dan hebben we ook nog threat detection nodig. Zoals dat voor veel andere Azure Services geldt, kan dit worden gerealiseerd met behulp van Azure Defender.
Met Azure Defender voor Kubernetes configureer je run-time beveiliging op twee verschillende niveaus:
- Host level;
- AKS Cluster level
Host Level
Op host level (de nodes), checkt Azure Defender voor events die mogelijk een impact hebben op je beveiliging. Denk bijvoorbeeld aan niet-vertrouwde IP adressen, containers die met teveel rechten worden gestart en SSH diensten die binnen een container draaien (ja dat wil je wel weten 😊). Hiervoor is wel de log analytics agent benodigd.
AKS Cluster Level
Op cluster niveau kunnen we agentless monitoren en de beveiliging is gebaseerd op analyse van de Kubernetes even logs. Verdacht gedrag op cluster niveau wordt gerapporteerd door Azure Defender. Denk dan aan het aanmaken van rollen met veel autorisaties, dashboards die gepubliceerd zijn, etc.
We adviseren altijd om beide niveaus Azure Defender in te schakelen. Inderdaad, het vergt de installatie van een agent, maar laten we eerlijk zijn: hoeveel inzicht heb je nu in je cluster en wil je dit alleen al om de logging zelf niet configureren? Waarschijnlijk wel.
Private clusters
Dan het scenario waar je eigenlijk helemaal geen publieke toegang tot je cluster wilt toestaan, of je wilt meer controle over het verkeer en de toegang. Ook dat kan. Met Private Clusters kun je het verkeer managen, beter retouren en heb je meer mogelijkheden als het gaat om hub-spoke networking. Het komt wel met een aantal beperkingen maar als deze beperkingen jou niet in de weg zitten dan is een private cluster wel degelijk een optie. Let er wel op dat je een huidig cluster niet naar een private cluster kunt converteren, dit vereist een re-deployment. Iets wat je van te voren dus wilt besluiten 😊
Private clusters zorgen ervoor dat al het verkeer tussen de API server en de nodes plaats vinden binnen het private network. Met behulp van Azure Private Link configureer je de communicatie tussen verschillende services (AKS en Azure). Door de beperkingen van private clusters zien we deze niet zo vaak als normale cluster, maar weet dat ze bestaan en een optie kunnen zijn voor jouw configuratie. Als je echt verkeer wilt isoleren van de buitenwereld, een firewall subnet/vnet wil gebruiken (hub-spoke) en complexere VPN configuraties wil toepassen dat is dit zeker een oplossing waar je in kunt duiken.
Let er wel op dat een goede combinatie van network security, pod security, vnet peering en network security je ook goed opweg helpen om dit te realiseren, daar is niet persé een private cluster voor nodig.
Conclusie
Er is nog veel meer informatie beschikbaar en kennis die je kunt opdoen als het gaat om security en (Azure) Kubernetes. Dit artikel is bedoeld om je een introductie te geven, de best practices die je sowieso moet implementeren en aan te geven dat security echt een onderwerp is waar je vanaf het begin van het project rekening mee moet houden. Elk onderwerp kan een studie op zichzelf zijn, maar zelfs als je alleen de absolute basis van deze practices implementeert heb je al meer dan geen security. Reden genoeg dus om deze best practices op te nemen in je standaard deployments.
Dit artikel is onderdeel van een reeks
Lees in dit vervolg artikel alles over Ingress, Services, Pods en Namespaces.
Vorige artikelen teruglezen? Klik hier:
1. De evolutie van AKS
2. Hybride deployments met Kubernetes
3. Microservices op AKS
4. Update scenario's AKS
5. Linux vs. Windows containers
Wil je niets missen? Schrijf je dan hier in voor onze Intercept Insights. Dan houden we je op de hoogte van de laatste nieuwsberichten.
Bezoek onze AKS workshop
Leer nog meer over AKS door onze interactieve AKS workshop. In 1.5 uur ontvang jij de voordelen en de best practices om jouw omgeving efficiënter te maken. Middels veelvoorkomende AKS uitdagingen ben jij klaar voor AKS. Klik hier voor data en meld je aan!
