Kubernetes-cluster beveiligen 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 NetworkPolicy een pod voor ingress en/of egress isoleert, is in die betreffende richting alleen verkeer toegestaan dat expliciet door een toepasselijke policy wordt 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.

Kubernetes Network Policy in de praktijk 

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. Geen FQDN-gebaseerde regels. De standaard Kubernetes NetworkPolicy kan externe bestemmingen niet op domeinnaam selecteren. Hiervoor moet worden gewerkt met IP-adressen of CIDR-ranges. 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 ingebouwde encryptie of observability. Kubernetes NetworkPolicy bepaalt welk netwerkverkeer is toegestaan, maar verzorgt zelf geen encryptie van het netwerkverkeer of uitgebreide observability. 

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

Wat is Calico en wat voegt het toe aan Kubernetes?

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.

Calico versus standaard Kubernetes NetworkPolicy 

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. Bekijk de officiële Calico-documentatie over GlobalNetworkPolicy.

Policies richten op Kubernetes Services 

In tegenstelling tot de standaard Kubernetes NetworkPolicy kan Calico policies laten matchen op een specifieke Kubernetes Service. Deze service matching wordt ondersteund bij gebruik van de Kubernetes datastore driver; bij de etcd datastore driver wordt deze niet ondersteund. Zo kan bijvoorbeeld toegang vanuit de frontend-namespace naar de backend-service worden gedefinieerd.  

Bekijk de officiële Calico-documentatie over service matching. 

DNS/FQDN-gebaseerde egressregels

Calico Cloud ondersteunt FQDN-gebaseerde egress-allowregels, waarmee verkeer naar externe domeinen zoals api.example.com kan worden toegestaan zonder vaste IP-adressen in de policy op te nemen. Deze functionaliteit is gericht op uitgaand verkeer. Bekijk de officiële Calico Cloud-documentatie over DNS/FQDN-policy.

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 ondersteund inter-node verkeer via WireGuard, waarmee verkeer tussen Kubernetes-nodes tijdens transport kan worden versleuteld. 

Lees meer over WireGuard-encryptie in de officiële Calico-documentatie.

Observability

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

Calico voegt observability toe bovenop standaard Kubernetes NetworkPolicy. Calico Open Source biedt onder meer flow logs en het Calico Whisker dashboard Calico Cloud en Enterprise bieden aanvullende observability- en beheerfuncties. 

Kenmerk	Vanilla Network Policy	Calico Network Policy
Scope	Policies beperkt tot één namespace	Ondersteunt zowel namespace-scoped (Network Policy) als clusterbrede (Global Network Policy) regels
Default-deny gedrag	Moet expliciet worden gedefinieerd	Eenvoudig in te stellen als baseline voor zowel ingress- als egress-verkeer
Deny-regels	Alleen allow-regels worden ondersteund	Volledige ondersteuning voor deny-regels bij zowel ingress als egress
DNS / FQDN-regels	Niet ondersteund	Ondersteunt DNS- en FQDN-gebaseerde egress-regels
Policy-ordering	Geen tiers; alle policies worden gelijk toegepast	Ondersteunt tiered policy-ordering (bijv. infrastructuur vs. applicatieniveau)
Advanced matching	Beperkt tot basis pod- en namespace-selectors	Ondersteunt IP-blocks, named ports, service accounts en andere geavanceerde matchcriteria
Custom Resources (CRD’s)	Alleen de ingebouwde Network Policy is beschikbaar	Extra CRD’s zoals Global Network Policy, NetworkSet en HostEndpoint

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 kan ondersteund inter-node verkeer versleutelen zonder sidecars. Het gaat daarbij niet om volledige end-to-end encryptie van al het podverkeer. 

• 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 en Calico Cloud vergelijken

Calico is beschikbaar in meerdere edities, waaronder Calico Open Source, Calico Cloud Free Tier, Calico Cloud en Calico Enterprise. In deze vergelijking richten we ons op twee veelgebruikte opties: Calico Open Source en Calico Cloud. 

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 vraagt meer interne beheerinspanning, omdat de organisatie zelf verantwoordelijk is voor upgrades, monitoring, troubleshooting en 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 neemt een groter deel van het platformbeheer uit handen en biedt aanvullende beveiligings-, observability- en beheerfuncties. 

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:

Aspect	Calico Open Source	Calico Cloud
Beheer- en implementatie-inspanning	Meer intern beheer en configuratie	Meer managed functionaliteit en centraal beheer
Onderhoud	Hoger (je team beheert updates, schaalbaarheid en monitoring)	Lager (Tigera beheert upgrades, schaalbaarheid en integraties)
Kosten	Geen licentiekosten; infrastructuur- en beheerkosten blijven	Abonnementsmodel (extra kosten, maar voorspelbaar budget)
Flexibiliteit	Maximum (volledige controle, open ecosysteem)	Gebalanceerd (minder DIY-inspanning, meer out-of-the-box-functionaliteit)
Zichtbaarheid	Beperkt (vereist extra tooling voor flow monitoring)	Ingebouwde visualisatie van netwerkverkeer en auditmogelijkheden
Beveiliging	Geavanceerde network policies en configureerbare netwerkbeveiliging	Aanvullende managed security-, observability- en compliancefuncties

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.

Werk je met Kubernetes en wil je cloudinfrastructuur, observability en security verder pofessionaliseren? Bekijk onze Enablement Services voor ondersteuning bij cloud-native architectuur, cloud security en infrastructuur.