AWS EKS Calico: Complete Installatie & Netwerkbeleid Gids

De Harde Waarheid: 55% van Kubernetes-breaches door Netwerkfouten

Stel je voor: je productieomgeving draait op AWS EKS met drie kritieke microservices — een frontend op poort 80, een API-service op poort 8080, en een database op poort 5432. Op een maandagochtend ontdek je dat een gecompromitteerde container ongefilterde toegang heeft tot je volledige netwerk. De schade? Nog niet te overzien.

Volgens Verizon's Data Breach Investigations Report 2023 is 55% van alle Kubernetes-gerelateerde breaches te wijten aan misconfigureerde netwerktoegang. Dit betekent niet dat Kubernetes onveilig is — het betekent dat standaard netwerkconfiguraties een Karel doos aan mogelijkheden bieden voor kwaadwillenden.

In dit artikel leer je hoe je Calico installeert en configureert op AWS EKS, zodat je microservicecommunicatie volledig onder controle hebt. Je krijgt concrete voorbeelden, stapsgewijze handleidingen, en inzichten uit enterprise deployments die je direct kunt implementeren.

---

Waarom Standaard AWS VPC CNI Onvoldoende Is voor Productie

Wanneer je een EKS-cluster aanmaakt, gebruikt AWS standaard het Amazon VPC CNI-plug-in. Dit plug-in mappt pod-netwerken direct in je VPC-subnetten, wat prima werkt voor eenvoudige scenario's. Maar voor productie-omgevingen met strikte beveiligingseisen kom je al snel tekort.

De Beperkingen van AWS VPC CNI Alleen

Aspect	AWS VPC CNI	Calico op EKS
Netwerkpolicies	Alleen Security Groups op Node-niveau	Kubernetes NetworkPolicies (L3/L4/L7)
Namespace-isolatie	Niet native ondersteund	Volledig namespace-scoped beleid
Global policies	Nee	Ja, clusterbrede standaardregels
Deny-by-default	Handmatig complex	Native ondersteund
Observability	Basis CloudWatch metrics	Geavanceerde flow logs en netwerkvisibiliteit
Kosten	Inbegrepen bij EKS	Opensource, geen extra kosten

Wanneer Calico de Beste Keuze Is

Calico is ideaal in deze scenario's:

1. Multi-tenant clusters: Verschillende teams of klanten moeten volledig geïsoleerd opereren
2. Zero-trust architectuur: Alle verkeer moet expliciet worden toegestaan, niets op vertrouwen
3. Compliance-vereisten: GDPR, SOC 2, of PCI-DSS vereisen netwerksegmentatie
4. Microservice-mesh complexiteit: Meer dan 10 services met specifieke communicatiepatronen
5. Audit-vereisten: Je moet precies kunnen aantonen welke pods met welke andere pods communiceren

---

Wat is Project Calico Precies?

Calico is een opensource-netwerk- en netwerkbeveiligingsoplossing die specifiek is ontworpen voor Kubernetes en cloud-native workloads. In tegenstelling tot traditionele overlay-netwerken, gebruikt Calico BGP (Border Gateway Protocol) om routes direct te verspreiden tussen nodes — wat resulteert in betere prestaties zonder de overhead van encapsulatie.

Calico bestaat uit drie hoofdcomponenten:

• Felix: De agent die op elke node draait en netwerkpolicies afdwingt
• BIRD: De BGP-daemon die routes verspreidt tussen nodes
• ConfD: Een configuratiebeheerder die wijzigingen doorgeeft aan Felix

Op AWS EKS kun je Calico ook gebruiken met eBPF (Extended Berkeley Packet Filter) voor nog betere prestaties, maar de standaard BGP-modus is perfect voor de meeste enterprise deployments.

---

Stap-voor-Stap: Calico Installeren op AWS EKS

Vereisten

Voordat je begint, zorg ervoor dat je beschikt over:

• Een werkend EKS-cluster (versie 1.21 of hoger)
• kubectl geïnstalleerd en geconfigureerd met toegang tot je cluster
• voldoende IAM-permissies (cluster admin of vergelijkbaar)
• Helm 3.x (optioneel, maar aanbevolen voor productie)

Methode 1: Installatie met de Tigera Operator (Aanbevolen)

De Tigera Operator is de officiële manier om Calico te beheren op Kubernetes en biedt de beste ondersteuning voor enterprise features.

Stap 1: De Operator Installeren**

kubectl create namespace tigera-operator
kubectl apply -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml

Wacht tot de operator pods draaien:

kubectl get pods -n tigera-operator

Je zou twee pods moeten zien: één operator en één admission webhook pod. Dit duurt typisch 30-60 seconden.

Stap 2: Calico Custom Resources Installeren

Download en pas de custom-resources.yaml aan op basis van je netwerkconfiguratie:

kubectl apply -f https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml

Belangrijk: Controleer of het CIDR-bereik in deze manifest overeenkomt met je VPC-subnetten. Het standaardbereik is 192.168.0.0/16, maar je kunt dit aanpassen in de Installation-resource.

Stap 3: Installatie Verifiëren

Controleer de status van je Calico-installatie:

kubectl get pods -n calico-system

Na enkele minuten zou je alle pods in Running-status moeten zien. Typische pods zijn:

• calico-node (één per node)
• calico-kube-controllers
• calico-typha (voor grote clusters)

Methode 2: Installatie met Helm (Voor Automatisering)

Voor Infrastructure-as-Code en GitOps-workflows is Helm de beste keuze.

Stap 1: De Helm Repository Toevoegen

helm repo add projectcalico https://projectcalico.github.io/calico/helm-charts
helm repo update

Stap 2: Waarden Aanpassen

Maak een custom values-bestand aan (calico-values.yaml):

installation:
  kubernetesProvider: EKS
  cni:
    type: Calico
  calicoNetwork:
    ipPools:
    - name: default-ipv4-ippool
      cidr: 10.128.0.0/16
      encapsulation: VXLAN

typha:
  enabled: true
  replicas: 3

Stap 3: Installeren

helm install calico projectcalico/tigera-operator \
  --namespace tigera-operator \
  --create-namespace \
  -f calico-values.yaml

---

Praktische Calico Network Policies: Van Theoretisch naar Gerealiseerd

Nu Calico draait, is het tijd om echte netwerkpolicies te implementeren. Laten we terugkeren naar ons oorspronkelijke voorbeeld met drie microservices.

De Baseline: Deny-All Policy

Eerst creëren we een globale default-deny policy. Dit zorgt ervoor dat ALLE communicatie geblokkeerd wordt tenzij expliciet toegestaan.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-app-policy
spec:
  namespaceSelector: ''
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
  - action: Log
  egress:
  - action: Deny
  - action: Log

Pas dit toe met:

kubectl apply -f default-deny-policy.yaml

Stap 1: Database Toegang Beperken

De database (PostgreSQL op poort 5432) mag alleen verkeer accepteren van de API-service.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: database-ingress
  namespace: production
spec:
  selector: app == 'database'
  types:
  - Ingress
  ingress:
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 5432
      selector: app == 'api-service'

Stap 2: API-Service Beveiligen

De API-service mag verkeer accepteren van de frontend en uitgaand communiceren met de database.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-service-policy
  namespace: production
spec:
  selector: app == 'api-service'
  types:
  - Ingress
  - Egress
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: app == 'frontend'
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 8080
  egress:
  - action: Allow
    protocol: TCP
    destination:
      selector: app == 'database'
      ports:
      - 5432

Stap 3: Frontend Toegang Configureren

De frontend mag verkeer accepteren van externe gebruikers (HTTP/HTTPS) en uitgaand de API-service bereiken.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: production
spec:
  selector: app == 'frontend'
  types:
  - Ingress
  - Egress
  ingress:
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 80
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 443
  egress:
  - action: Allow
    protocol: TCP
    destination:
      selector: app == 'api-service'
      ports:
      - 8080

Uitgaand Verkeer naar Internet

Voor services die externe APIs moeten bereiken, kun je egress rules toevoegen:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-external-egress
spec:
  namespaceSelector: app == 'api-service'
  types:
  - Egress
  egress:
  - action: Allow
    destination:
      nets:
      - 0.0.0.0/0
      ports:
      - 443
      - 80

---

Calico in Actie: Observability en Troubleshooting

Een netwerk zonder zichtbaarheid is als autorijden met een blinddoek. Calico biedt robuuste tooling om je netwerkverkeer te monitoren en problemen snel op te lossen.

Flow Logs Inschakelen

Calico kan geavanceerde flow logs genereren die je kunt exporteren naar tools zoals Elasticsearch of S3.

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  flowLogsRenderedHostname: true
  flowLogsFileEnabled: true
  flowLogsFileMaxFiles: 7
  flowLogsFileMaxSizeBytes: 5000000

Traffic Analysis met Calico Enterprise

Voor enterprise deployments biedt Calico Enterprise (de betaalde variant) real-time traffic visibility, threat detection, en compliance reporting. Features zijn onder andere:

• Service Graph: Visualiseer alle communicatiepatronen tussen services
• Anomaly Detection: Machine learning detecteert verdacht verkeer
• DNS Dashboards: Monitor DNS-queries voor potentiële exfiltration

Troubleshooting Commands

Enkele essentiële kubectl-commands voor Calico troubleshooting:

# Bekijk alle network policies in een namespace
kubectl get networkpolicy -n production

# Gedetailleerde policy informatie
kubectl describe networkpolicy frontend-policy -n production

# Calico specifieke commands
calicoctl get nodes
calicoctl get workloads
calicoctl policy show

# Check Felix configuratie
kubectl get felixconfiguration default -o yaml

---

Enterprise Best Practices voor Calico op EKS

1. Gebruik Namespace-Scoped Policies als Default

In plaats van globale policies voor alles, werk namespace-specifiek. Dit verbetert maintainability en vermindert de impact van misconfiguraties.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  namespaceSelector: ''
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production

2. Implementeer een Staged Rollout

Neem nooit een heel cluster in één keer over op deny-by-default. Gebruik namespaces als staging:

1. Week 1: Monitor alle communicatie zonder policies te blokkeren
2. Week 2: Voeg deny-beleid toe aan niet-productie namespaces
3. Week 3: Valideer productie workloads met test-traffic
4. Week 4: Implementeer globale deny-by-default

3. Backup Altijd je Policies

Exporteer regelmatig je Calico policies:

calicoctl get policy -o yaml > calico-policies-backup-$(date +%Y%m%d).yaml

4. Integreer met AWS Security Groups

Calico policies werken naast AWS Security Groups, niet in plaats van. Gebruik Security Groups voor node-level bescherming en Calico voor pod-level granulariteit.

5. Automatiseer met GitOps

Tools zoals ArgoCD of Flux kunnen je Calico policies automatisch synchroniseren vanuit een Git-repository. Dit zorgt voor:

• Volledige audit trail van wijzigingen
• Automatische rollback bij fouten
• DRY-principe voor policy management

---

Cost-Benefit Analyse: Calico vs. Alternatieven

Feature	Calico	Cilium	AWS VPC CNI + SG
Licentiekosten	Opensource (Enterprise optioneel)	Opensource (Enterprise optioneel)	Inbegrepen bij EKS
Implementatiecomplexiteit	Gemiddeld	Hoog	Laag
L7 Filtering	Via Enterprise	Native	Nee
eBPF Support	Ja	Ja	Nee
BGP Routing	Ja	Nee	Nee
Kubernetes NetworkPolicy	Volledig	Volledig	Beperkt
Multi-cluster Support	Via Enterprise	Via Cilium Cluster Mesh	Nee

Voor de meeste organisaties biedt Calico de beste balans tussen functionaliteit en implementatiegemak. De opensource-versie dekt 90% van de enterprise-behoeften zonder licentiekosten.

---

Conclusie: Neem Controle over je Kubernetes Netwerk

Netwerkbeveiliging in Kubernetes is geen optie — het is een noodzaak. Met 55% van de breaches gerelateerd aan netwerkfouten, is de kostprijs van inactiviteit veel hoger dan de inspanning om Calico te implementeren.

In deze gids heb je geleerd hoe je:

• Calico installeert op AWS EKS via de Tigera Operator of Helm
• Granulaire network policies implementeert voor microservice-isolatie
• Je netwerkverkeer monitort en troubleshoott
• Enterprise best practices toepast voor productie-omgevingen

De volgende stappen zijn simpel: start in een niet-productie namespace, experimenteer met policies, meet de impact, en rol uit naar productie. Binnen een maand heb je een Kubernetes-cluster dat voldoet aan zero-trust principes en klaar is voor compliance-audits.

Wil je dieper duiken in specifieke Calico-scenario's? De officiële Calico documentatie en de Tigera Community Slack zijn uitstekende bronnen voor continue learning en ondersteuning.