Het beveiligen van je Kubernetes cluster met Calico

Naarmate organisaties Kubernetes steeds vaker inzetten, wordt het beveiligen van de communicatie tussen pods een essentiële vereiste voor het waarborgen van een betrouwbare en veerkrachtige infrastructuur. Kubernetes biedt een basisimplementatie van Network Policies om het verkeer tussen pods en services te beheren. Voor eenvoudige use cases is dit doorgaans voldoende, maar productieomgevingen vragen vaak om meer geavanceerde en fijnmazige beveiligingsmaatregelen.

In dit artikel wordt onderzocht hoe Calico voortbouwt op de native mogelijkheden van Kubernetes. Calico biedt uitgebreide functies die de overgang ondersteunen van eenvoudig verkeersbeheer naar een volledig beveiligingsmodel.

Kubernetes Network Policy regels

Een nuttige manier om over Kubernetes netwerken na te denken is via een analogie. Stel je een Kubernetes cluster voor als een land dat bestaat uit meerdere steden (namespaces). Elke stad bevat meerdere gebouwen (pods), verbonden door wegen die zowel binnen een stad als tussen steden verkeer mogelijk maken.

• Network Policies functioneren als verkeersregels die bij specifieke gebouwen zijn geplaatst. Ze bepalen wie naar binnen mag, wie naar buiten mag, en via welke routes (poorten).
• Ingress regels zijn te vergelijken met grensposten: ze controleren bezoekers van buitenaf die toegang willen krijgen tot specifieke gebouwen (pods).
• Egress regels werken als uitgaande controles: ze bepalen welk verkeer een gebouw mag verlaten, of dat nu naar andere steden (namespaces) gaat of naar externe bestemmingen zoals het internet.

Met deze analogie in gedachten is het nuttig om de formele concepten te bekijken die in dit artikel verder worden gebruikt.

Network Policy

• Een Kubernetes-resource die toestemmingsregels definieert voor geselecteerde pods, op basis van IP-adressen, poorten en protocollen.
• Standaard kunnen pods vrij communiceren met elk ander eindpunt. Zodra een policy van toepassing is op een pod, wordt al het verkeer geweigerd tenzij het expliciet is toegestaan.
• Network Policies zijn additief: elke regel specificeert welke pods, namespaces of IP-ranges zijn toegestaan, en via welke poorten en protocollen.

Ingress en egress in Network Policies

• Ingress regels bepalen het verkeer dat pods binnenkomt.
• Egress regels bepalen het verkeer dat pods verlaat.
• Beide worden altijd gedefinieerd vanuit het perspectief van de pods waarop de network policy van toepassing is.

Een praktisch voorbeeld

Nu de kernconcepten duidelijk zijn, is het nuttig om te bekijken hoe de standaard Kubernetes Network Policy in de praktijk werkt, inclusief de mogelijkheden en beperkingen.

Stel je een typische applicatiearchitectuur voor waarin Network Policies worden toegepast om de communicatie tussen pods in verschillende namespaces te beheersen.

In dit voorbeeld:

• Eindgebruikers hebben alleen toegang tot specifieke pods in de frontend-namespace. Deze beperking wordt afgedwongen door een default deny-all policy die in alle drie de namespaces is toegepast.
• Pods in de backend-namespace accepteren uitsluitend inkomende verbindingen vanuit de frontend-namespace. Uitgaand verkeer vanuit de backend is alleen toegestaan richting de db-namespace.
• Pods in de db-namespace zijn volledig geïsoleerd en accepteren uitsluitend inkomende verbindingen van pods in de backend-namespace.

Deze opzet laat zien hoe Network Policies gecontroleerde en voorspelbare verkeersstromen kunnen afdwingen, zodat elk onderdeel van de applicatie alleen communiceert met de beoogde services.

Beperkingen van de standaard Network Policy

Hoewel de eerder beschreven opzet voldoende kan zijn voor basisvereisten, worden in productieomgevingen (waar services gevoeliger zijn en de beveiliging zwaarder weegt) de beperkingen van de standaard (vanilla) Network Policy duidelijk. De belangrijkste zijn:

• Geen clusterbrede policy. Network Policies zijn namespace-gebonden. Zoals in het eerdere voorbeeld moest de default deny-all policy in elke namespace apart worden toegepast. Dit verhoogt de complexiteit bij het streven naar een gestandaardiseerde, clusterbrede aanpak.
• Pod-gecentreerd en namespace-gebonden. Policies richten zich op pods, niet op Services. Het is niet mogelijk een regel te definiëren zoals “allow to Service X.” In het eerdere voorbeeld werden alle policies toegepast op pods die via labels waren geselecteerd.
• Beperkte controle over extern verkeer. Er is geen DNS-gebaseerde regel voor inkomend verkeer (bijvoorbeeld het toestaan van verbindingen vanaf example.com). Alleen specifieke IP’s of CIDR-ranges kunnen worden gebruikt, wat problemen oplevert wanneer publieke of dynamische IP’s veranderen.
• Geen expliciete deny-regels of prioriteit. Alle policies functioneren als additieve allow-lijsten. Er is geen mechanisme om deny-regels toe te passen of prioriteiten te stellen die bestaande allow-regels overschrijven.
• Geen encryptie of observability. Network Policies bieden geen ondersteuning voor mTLS of IPsec. Hierdoor is er geen ingebouwde encryptie tussen netwerkcomponenten (pods, endpoints, enzovoort).
• Beperkte logging van beslissingen. Network Policies bieden geen logging-ondersteuning voor toegepaste regels of beslissingen, waardoor het lastig is communicatieproblemen te analyseren of op te lossen.

Afhankelijk van de eisen van je applicatie kunnen deze beperkingen een serieuze belemmering vormen. Een mogelijke oplossing hiervoor is het Calico project, ontwikkeld door Tigera.

Calico: doel en rol

Volgens Tigera is Calico één platform voor Kubernetes-netwerken, netwerkbeveiliging en observability, geschikt voor elke Kubernetes-distributie in de cloud, on-premises of aan de edge.

Of je nu net begint met Kubernetes of een volwassen, multi-node cluster beheert, Calico kan voorzien in de meeste netwerkvereisten die je applicatie of infrastructuur stelt.

Zoals het gezegde luidt: “een beeld zegt meer dan duizend woorden.” In dit geval biedt een overzichtsdiagram van Calico het meest bruikbare inzicht.

Zoals in het overzicht hierboven te zien is, heeft Calico een aantal opvallende kenmerken:

• Cross-platform beschikbaarheid: Calico ondersteunt zowel Windows- als Linux-containers.
• Flexibele implementatie-opties: Of de applicatie nu draait in een virtuele machine, op bare metal of in een container, Calico functioneert consistent in alle omgevingen.
• Plug-and-play-integratie: Applicatiecomponenten hoeven niet te worden aangepast. Netwerkbeveiliging kan volledig worden beheerd door het platform- of securityteam.
• High-performance dataplanes: Calico biedt de keuze tussen eBPF of iptables op Linux, gecombineerd met native routing om de prestaties te verbeteren en de platformcompatibiliteit te vergroten.
• Meerdere leveringsmodellen: Calico kan op verschillende manieren worden ingezet: als onderdeel van een zelfbeheerde Kubernetes-distributie of als SaaS-optie in Azure, AWS of Google Cloud.

Wat Calico anders maakt

Nu het doel van Calico is toegelicht, kunnen we teruggaan naar het eerdere voorbeeld en de beperkingen bekijken die zijn vastgesteld bij de standaard Kubernetes Network Policy.

Calico breidt de standaard Kubernetes Network Policy uit met extra mogelijkheden die meer controle geven over het verkeer binnen een cluster. Hieronder worden de eerder genoemde beperkingen opnieuw bekeken, samen met de manier waarop Calico deze aanpakt:

Global Network Policy

In tegenstelling tot Kubernetes Network Policy, die beperkt is tot een enkele namespace, kan Calico’s Global Network Policy regels toepassen over alle namespaces heen of specifieke namespaces targeten. Dit maakt het mogelijk om beveiligingsregels consistent clusterbreed af te dwingen.

Zo kan één enkele default deny-all policy worden gedefinieerd die voor het hele cluster geldt. Dit sluit aan bij het Zero Trust Network-model, waarbij al het verkeer standaard wordt geweigerd en toegang alleen wordt verleend waar dat expliciet nodig is. Meer details hier.

Targeting Kubernetes Services

In tegenstelling tot de standaard Network Policy, die alleen label selectors ondersteunt, maakt Calico het mogelijk om policies te richten op een specifieke Kubernetes Service binnen een namespace. Hierdoor kan bijvoorbeeld toegang vanuit de frontend-namespace direct naar de backend-service worden gedefinieerd. Meer details hier.

DNS/FQDN-gebaseerde egressregels

Calico ondersteunt DNS- of FQDN-gebaseerde egressregels, waardoor verkeer naar domeinnamen zoals api.example.com kan worden toegestaan. Dit biedt een controlemechanisme dat standaard Kubernetes policies niet bieden, en is vooral waardevol bij het reguleren van internettoegang. DNS-gebaseerde deny-regels worden nog niet ondersteund. Meer details hier.

Policy tiers

Calico introduceert policy tiers, zoals security, platform en application. Deze tiers bepalen de volgorde en prioriteit waarin regels worden toegepast. Een securityteam kan bijvoorbeeld policies beheren in een bovenliggende tier die altijd geldt voordat applicatiespecifieke regels worden toegepast.

Bij vanilla Network Policies kunnen alleen additieve regels worden toegepast, die allemaal op hetzelfde niveau functioneren.

Geavanceerde beveiligingsfuncties

Calico voegt verschillende geavanceerde mogelijkheden toe:

• Expliciete deny-regels, waarmee je nauwkeuriger kunt bepalen welk verkeer wordt geblokkeerd.
• Encryptie van data in transit, dankzij de integratie met WireGuard, waarmee communicatie tussen pods en nodes wordt beveiligd.

Lees meer over hoe je inter-node, in-cluster encryptie kunt inschakelen.

Observability

Bij vanilla Network Policies is de zichtbaarheid van communicatie binnen het cluster beperkt, wat het oplossen van problemen lastig maakt.

Calico biedt uitgebreide observability-functies, waaronder DNS-logs, flow-logs en Layer 7-logs. Hiermee kunnen beheerders policies effectief monitoren, valideren en debuggen. Zelfs in de open-sourceversie is er een dashboard beschikbaar via Calico Whisker, dat realtime netwerkactiviteit weergeeft op basis van flow-logs.

Belangrijke integraties: eBPF, WireGuard en Envoy

Calico integreert met verschillende technologieën om de beveiliging te versterken, de prestaties te verbeteren en meer inzicht te krijgen in Kubernetes-clusters:

• eBPF verplaatst netwerk- en beveiligingslogica rechtstreeks naar de Linux-kernel, wat zorgt voor hogere prestaties en gedetailleerd inzicht in packet flows.
• WireGuard biedt lichte, snelle encryptie voor pod-naar-pod- en pod-naar-servicecommunicatie.
• Envoy werkt samen met Calico om service-to-service-beveiligingsregels toe te passen en af te dwingen, waardoor applicaties worden beschermd op zowel netwerk- als applicatieniveau.

Gezamenlijk laten deze integraties zien hoe Calico verder gaat dan basis network policies en zich ontwikkelt tot een compleet netwerk- en beveiligingsplatform voor Kubernetes. Ze verbeteren de prestaties, bieden encryptie en vergroten de zichtbaarheid van netwerkverkeer.

Dit zijn echter niet de enige functies die Calico biedt, en er is ook niet slechts één editie beschikbaar. In de volgende sectie worden de verschillende productie-edities van Calico besproken en hun beoogde toepassingen.

Calico: Open Source vs. Cloud

Bij het kiezen van Calico zijn er twee hoofdvarianten om te overwegen: Calico Open Source en Calico Cloud. Beide zijn uitgebreid in functionaliteit, maar richten zich op verschillende behoeften, afhankelijk van de fase waarin een organisatie zich bevindt met de adoptie van Kubernetes.

Calico Open Source – DIY control

Voor organisaties die hun eigen infrastructuur willen beheren, biedt de open-source editie van Calico een solide basis voor Kubernetes-netwerken en -beveiliging. Belangrijke kenmerken zijn:

• Volledige ondersteuning voor Kubernetes Network Policies
• Flexibiliteit om aan te passen en uit te breiden naar de behoeften van het cluster
• Een actieve community voor ondersteuning en samenwerking
• Kosteloos beschikbaar, aantrekkelijk voor omgevingen waar kostenbeheersing belangrijk is

De keerzijde is dat de open-source editie intern beheer vereist van upgrades, monitoring en troubleshooting. Dit kan leiden tot een langere time-to-market voor geavanceerde functies en meer onderhoudsinspanning, omdat de organisatie zelf verantwoordelijk is voor de operationele stabiliteit.

Voorbeeld: Calico Whisker
De open-source editie bevat ook observability-functionaliteit. Zo biedt Calico Whisker een lichtgewicht dashboard dat realtime inzicht geeft in netwerkstromen.

Calico Cloud – Managed simplicity

Calico Cloud bouwt voort op de open-source basis en biedt een managed service die beschikbaar is op grote cloudplatforms zoals Azure, AWS en Google Cloud.

Naast de mogelijkheden van de open-source editie biedt Calico Cloud:

• Eén centrale beheeromgeving om meerdere clusters via één interface aan te sturen
• Realtime visualisatie van netwerkverkeer
• Ingebouwde compliance- en audittools om aan regelgeving te voldoen zonder extra ontwikkelinspanning
• Geavanceerde beveiligingsfuncties zoals intrusion detection, zero-trust enforcement en meer

Deze editie vereist een abonnementsvergoeding, maar levert in ruil daarvoor een snellere time-to-market, minder onderhoudslast en verbeterde beveiliging en observability.

Voorbeeld: Calico Cloud Dashboard
Het onderstaande voorbeeld laat de geavanceerde observability-functionaliteit zien die beschikbaar is in Calico Cloud.

De twee edities kunnen ook worden vergeleken vanuit een meer strategisch perspectief, gericht op bredere operationele criteria:

Voor een volledige lijst van beschikbare functies, bekijk de officiële vergelijkingsmatrix.

Conclusie

Vanilla Network Policies vormen een nuttig startpunt. In praktijkomgevingen met Kubernetes zijn echter vaak zwaardere maatregelen nodig om aan de beveiligingseisen van productie te voldoen. Calico breidt de native mogelijkheden uit en levert daarmee een meer compleet beveiligingskader dat geschikt is voor productiegebruik.

Door integratie met technologieën zoals eBPF, WireGuard en Envoy verbetert Calico bovendien de prestaties, biedt het encryptie en versterkt het de beveiliging op serviceniveau.