AWS VPC CNI + Cilium chaining : le meilleur des deux mondes

Sur EKS, le CNI par défaut est le VPC CNI. Il attache directement des IP du VPC aux Pods, pratique pour garder l'intégration native AWS : security groups, VPC Flow Logs, Network ACLs.

Revers : il est limité pour les Network Policies, l'observabilité et le chiffrement. Cilium excelle sur ces trois points grâce à eBPF, mais en standalone il reprend l'IPAM à son compte et on perd l'intégration VPC.

Le mode chaining (ou hybrid mode) permet de garder le meilleur des deux : Cilium se greffe sur le VPC CNI pour les IP, et apporte ses propres Network Policies, sa visibilité et son chiffrement via eBPF. C'est l'option que je recommande dès qu'un cluster EKS doit dépasser le setup minimal sans se couper d'AWS.

Pourquoi utiliser le mode chaining ?

Critère	VPC CNI seul	Cilium standalone	Cilium chaining
IP native AWS	Oui	Non	Oui
Security groups par Pod	Oui (sauf en Auto Mode)	Non	Oui
Network Policies	Limitée	Avancée (L3-L7)	Avancée (L3-L7)
Observabilité	Minimale	Hubble (L3-L7)	Hubble (L3-L7)
Chiffrement	Non	Wireguard / IPsec	Wireguard / IPsec
VPC Flow Logs	Oui	Non	Oui
Compatibilité AWS	Maximale	Partielle	Maximale

En pratique, je le conseille quand vous avez besoin de l'un de ces cas :

des security groups par Pod (natif AWS)
des Network Policies L7 (HTTP, gRPC, Kafka)
une observabilité fine avec Hubble
du chiffrement du trafic sans sidecar

Architecture

Le fonctionnement est assez direct : la chaîne CNI exécute d'abord le VPC CNI (branchement de l'interface, allocation IP), puis Cilium applique ses programmes eBPF sur l'interface déjà configurée.

Cilium n'intervient pas dans l'allocation des IP. Il se contente de :

détecter l'interface créée par le VPC CNI
attacher ses programmes eBPF (tc / XDP)
appliquer les policies réseau
collecter les métriques et les flows pour Hubble

Installation

Prérequis

Cluster EKS (ou tout cluster AWS avec VPC CNI)
AWS VPC CNI v1.18+ (recommendé v1.19+)
Cilium ≥ 1.16 (recommandé 1.17+)
Nœuds avec kernel ≥ 5.10 (Amazon Linux 2023 recommandé)

1. Configurer le VPC CNI

Le VPC CNI doit être configuré pour déléguer les Network Policies à Cilium.

bash

# Désactiver les Network Policies du VPC CNI
kubectl set env daemonset aws-node -n kube-system \
  NETWORK_POLICY_ENFORCING_MODE=disabled

# Configurer l'ENABLE_POD_ENI si vous voulez les security groups par Pod
kubectl set env daemonset aws-node -n kube-system \
  ENABLE_POD_ENI=true

2. Installer Cilium en mode chaining

Créez un fichier cilium-values.yaml :

yaml

cni:
  chainingMode: aws-cni
  chainingTarget: aws-node
ipam:
  mode: kubernetes
identityAllocationMode: crd
enableIPv4Masquerade: false
bpf:
  masquerade: true
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true
encryption:
  enabled: true
  type: wireguard
l7Proxy: true
rollOutCiliumPods: true

Points clés :

chainingMode: aws-cni : active le chaining avec le VPC CNI
ipam: kubernetes : Cilium n'alloue pas les IP, il reprend l'IPAM du VPC CNI
enableIPv4Masquerade: false : le VPC CNI gère le masquerade via son propre SNAT
bpf.masquerade: true : Cilium peut optimiser le masquerade via BPF si besoin

Appliquez avec Helm :

bash

helm repo add cilium https://helm.cilium.io
helm repo update

helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --values cilium-values.yaml

3. Vérifier l'installation

bash

# Vérifier que les pods Cilium sont bien démarrés
kubectl -n kube-system get pods -l k8s-app=cilium

# Vérifier le status de l'agent Cilium
kubectl -n kube-system exec daemonset/cilium -- cilium status

# Vérifier le mode chaining
kubectl -n kube-system exec daemonset/cilium -- cilium status | grep Chaining

Sortie attendue :

Chaining: aws-cni

Network Policies

En chaining, les Network Policies sont gérées uniquement par Cilium. Les NetworkPolicy Kubernetes standards continuent de fonctionner, mais vous pouvez aussi utiliser les CRD Cilium plus avancées.

Policy L3/L4 standard

Une policy classique fonctionne sans modification :

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

Policy L7 (HTTP)

Cilium permet de filtrer par méthode HTTP, path, et headers :

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/users/.*"
        - method: POST
          path: "/users"
        - method: "GET"
          path: "/healthz"

Policy DNS

Cilium peut aussi filtrer les requêtes DNS :

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: dns-allow
spec:
  endpointSelector:
    matchLabels:
      app: worker
  egress:
  - toFQDNs:
    - matchPattern: "*.amazonaws.com"
    - matchName: "api.mon-saas.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

Observabilité avec Hubble

Hubble est l'observabilité réseau de Cilium. Il donne une visibilité L3/L7 sur tout le trafic.

Installation (déjà activée dans les valeurs ci-dessus)

bash

# Activer le port-forward vers Hubble UI
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

# Utiliser Hubble CLI
hubble observe --namespace production --protocol http

Exemple de sortie Hubble :

Jul  9 10:23:45.123  frontend-7f8b9c  →  api-6d4f8a   http GET /users/123  200
Jul  9 10:23:46.456  api-6d4f8a       →  redis-2b3c1a  tcp   6379           allowed
Jul  9 10:23:47.789  worker-9e1f2d    →  api.amazonaws.com  dns AAAA  NXDOMAIN

Métriques Prometheus

Cilium expose des métriques Prometheus pour le monitoring :

bash

kubectl -n kube-system exec daemonset/cilium -- cilium metrics list

Métriques utiles en chaining :

cilium_forward_count_total : paquets forwardés
cilium_drop_count_total : paquets bloqués par policy
cilium_policy_l7_total : requêtes HTTP filtrées par policy

Chiffrement du trafic

En chaining, Cilium peut chiffrer le trafic entre les nœuds via WireGuard (recommandé) ou IPsec.

WireGuard

Pour WireGuard, vérifiez que le module wireguard est chargé sur les nœuds (Amazon Linux 2023 l'inclut nativement) :

yaml

encryption:
  enabled: true
  type: wireguard

Vérification :

bash

# Vérifier les clés WireGuard sur un nœud
kubectl -n kube-system exec daemonset/cilium -- cilium encrypt status

# Tester le chiffrement en capturant un paquet entre deux nœuds
kubectl -n kube-system exec daemonset/cilium -- tcpdump -i any -c 10 udp port 51871

Migration depuis une installation VPC CNI seule

La migration est transparente et sans interruption de service si elle est bien préparée.

bash

# 1. Installer Cilium avec chaining (les pods existants ne sont pas impactés)
helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --values cilium-values.yaml

# 2. Redémarrer les pods pour qu'ils utilisent la nouvelle chaîne CNI
kubectl rollout restart deployment -n production --all

# 3. Désactiver les Network Policies du VPC CNI
kubectl set env daemonset aws-node -n kube-system \
  NETWORK_POLICY_ENFORCING_MODE=disabled

Important : Les Network Policies existantes (standard Kubernetes) restent appliquées. Cilium les prend en charge automatiquement via le mode chaining.

Pièges à éviter

VPC CNI préfixe / max-pods

En chaining, Cilium ne gère pas l'IPAM. La limite de Pods par nœud reste celle du VPC CNI. Si vous êtes coincé, activez les préfixes /28 (VPC CNI v1.16+) pour gagner de la capacité :

bash

kubectl set env daemonset aws-node -n kube-system \
  ENABLE_PREFIX_DELEGATION=true
kubectl set env daemonset aws-node -n kube-system \
  WARM_PREFIX_TARGET=1

Security groups par Pod (SGPP)

Si vous utilisez les security groups par Pod, assurez-vous que ENABLE_POD_ENI=true est configuré sur le VPC CNI. Cilium n'interfère pas avec ce mécanisme.

⚠️ Non compatible EKS Auto Mode : les security groups par Pod demandent de pouvoir modifier le daemonset aws-node. En Auto Mode, AWS gère le CNI de bout en bout et ENABLE_POD_ENI n'est pas configurable. Pour SGPP, restez sur un cluster EKS standard (node groups gérés ou self-managed).

Masquerade (SNAT)

Ne pas activer ipMasqAgent de Cilium si vous avez déjà aws-node configuré pour le SNAT. Les deux risquent de créer des conflits sur les règles iptables.

yaml

# Désactiver le SNAT Cilium si le VPC CNI le gère déjà
enableIPv4Masquerade: false

Noeuds Windows

Le chaining ne fonctionne pas sur les nœuds Windows. Cilium repose sur eBPF, donc Linux uniquement. Les nœuds Windows restent sur VPC CNI seul.

Résumé

Fonctionnalité	VPC CNI seul	VPC CNI + Cilium chaining
IP native AWS	Oui	Oui
Security groups par Pod	Oui (sauf en Auto Mode)	Oui
Network Policies	Limitée	L3/L4/L7
Observabilité	CloudWatch	Hubble (flows, HTTP, DNS)
Chiffrement	Non	WireGuard / IPsec
ClusterMesh (multi-cluster)	Non	Oui
CLI diagnostic	aws CLI	`cilium connectivity test`
Complexité opérationnelle	Faible	Moyenne

Le chaining est la config que je recommande pour les clusters EKS qui veulent sortir du minimum viable sans perdre l'intégration AWS. Il ne remplace pas le VPC CNI, il le complète.

Retour d'expérience : la première fois, on avait laissé enableIPv4Masquerade: true côté Cilium alors que le VPC CNI faisait déjà le SNAT. Résultat, des règles iptables en doublon et des timeouts intermittents. Depuis, on désactive systématiquement le masquerade Cilium en chaining.

Sources

Sur EKS, le CNI par défaut est le VPC CNI. Il attache directement des IP du VPC aux Pods, pratique pour garder l'intégration native AWS : security groups, VPC Flow Logs, Network ACLs.

Pourquoi utiliser le mode chaining ?

Critère	VPC CNI seul	Cilium standalone	Cilium chaining
IP native AWS	Oui	Non	Oui
Security groups par Pod	Oui (sauf en Auto Mode)	Non	Oui
Network Policies	Limitée	Avancée (L3-L7)	Avancée (L3-L7)
Observabilité	Minimale	Hubble (L3-L7)	Hubble (L3-L7)
Chiffrement	Non	Wireguard / IPsec	Wireguard / IPsec
VPC Flow Logs	Oui	Non	Oui
Compatibilité AWS	Maximale	Partielle	Maximale

En pratique, je le conseille quand vous avez besoin de l'un de ces cas :

des security groups par Pod (natif AWS)
des Network Policies L7 (HTTP, gRPC, Kafka)
une observabilité fine avec Hubble
du chiffrement du trafic sans sidecar

Architecture

Cilium n'intervient pas dans l'allocation des IP. Il se contente de :

détecter l'interface créée par le VPC CNI
attacher ses programmes eBPF (tc / XDP)
appliquer les policies réseau
collecter les métriques et les flows pour Hubble

Installation

Prérequis

Cluster EKS (ou tout cluster AWS avec VPC CNI)
AWS VPC CNI v1.18+ (recommendé v1.19+)
Cilium ≥ 1.16 (recommandé 1.17+)
Nœuds avec kernel ≥ 5.10 (Amazon Linux 2023 recommandé)

1. Configurer le VPC CNI

Le VPC CNI doit être configuré pour déléguer les Network Policies à Cilium.

bash

# Désactiver les Network Policies du VPC CNI
kubectl set env daemonset aws-node -n kube-system \
  NETWORK_POLICY_ENFORCING_MODE=disabled

# Configurer l'ENABLE_POD_ENI si vous voulez les security groups par Pod
kubectl set env daemonset aws-node -n kube-system \
  ENABLE_POD_ENI=true

2. Installer Cilium en mode chaining

Créez un fichier cilium-values.yaml :

yaml

cni:
  chainingMode: aws-cni
  chainingTarget: aws-node
ipam:
  mode: kubernetes
identityAllocationMode: crd
enableIPv4Masquerade: false
bpf:
  masquerade: true
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true
encryption:
  enabled: true
  type: wireguard
l7Proxy: true
rollOutCiliumPods: true

Points clés :

chainingMode: aws-cni : active le chaining avec le VPC CNI
ipam: kubernetes : Cilium n'alloue pas les IP, il reprend l'IPAM du VPC CNI
enableIPv4Masquerade: false : le VPC CNI gère le masquerade via son propre SNAT
bpf.masquerade: true : Cilium peut optimiser le masquerade via BPF si besoin

Appliquez avec Helm :

bash

helm repo add cilium https://helm.cilium.io
helm repo update

helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --values cilium-values.yaml

3. Vérifier l'installation

bash

# Vérifier que les pods Cilium sont bien démarrés
kubectl -n kube-system get pods -l k8s-app=cilium

# Vérifier le status de l'agent Cilium
kubectl -n kube-system exec daemonset/cilium -- cilium status

# Vérifier le mode chaining
kubectl -n kube-system exec daemonset/cilium -- cilium status | grep Chaining

Sortie attendue :

Chaining: aws-cni

Network Policies

Policy L3/L4 standard

Une policy classique fonctionne sans modification :

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

Policy L7 (HTTP)

Cilium permet de filtrer par méthode HTTP, path, et headers :

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/users/.*"
        - method: POST
          path: "/users"
        - method: "GET"
          path: "/healthz"

Policy DNS

Cilium peut aussi filtrer les requêtes DNS :

yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: dns-allow
spec:
  endpointSelector:
    matchLabels:
      app: worker
  egress:
  - toFQDNs:
    - matchPattern: "*.amazonaws.com"
    - matchName: "api.mon-saas.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

Observabilité avec Hubble

Hubble est l'observabilité réseau de Cilium. Il donne une visibilité L3/L7 sur tout le trafic.

Installation (déjà activée dans les valeurs ci-dessus)

bash

# Activer le port-forward vers Hubble UI
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

# Utiliser Hubble CLI
hubble observe --namespace production --protocol http

Exemple de sortie Hubble :

Jul  9 10:23:45.123  frontend-7f8b9c  →  api-6d4f8a   http GET /users/123  200
Jul  9 10:23:46.456  api-6d4f8a       →  redis-2b3c1a  tcp   6379           allowed
Jul  9 10:23:47.789  worker-9e1f2d    →  api.amazonaws.com  dns AAAA  NXDOMAIN

Métriques Prometheus

Cilium expose des métriques Prometheus pour le monitoring :

bash

kubectl -n kube-system exec daemonset/cilium -- cilium metrics list

Métriques utiles en chaining :

cilium_forward_count_total : paquets forwardés
cilium_drop_count_total : paquets bloqués par policy
cilium_policy_l7_total : requêtes HTTP filtrées par policy

Chiffrement du trafic

En chaining, Cilium peut chiffrer le trafic entre les nœuds via WireGuard (recommandé) ou IPsec.

WireGuard

Pour WireGuard, vérifiez que le module wireguard est chargé sur les nœuds (Amazon Linux 2023 l'inclut nativement) :

yaml

encryption:
  enabled: true
  type: wireguard

Vérification :

bash

# Vérifier les clés WireGuard sur un nœud
kubectl -n kube-system exec daemonset/cilium -- cilium encrypt status

# Tester le chiffrement en capturant un paquet entre deux nœuds
kubectl -n kube-system exec daemonset/cilium -- tcpdump -i any -c 10 udp port 51871

Migration depuis une installation VPC CNI seule

La migration est transparente et sans interruption de service si elle est bien préparée.

bash

# 1. Installer Cilium avec chaining (les pods existants ne sont pas impactés)
helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --values cilium-values.yaml

# 2. Redémarrer les pods pour qu'ils utilisent la nouvelle chaîne CNI
kubectl rollout restart deployment -n production --all

# 3. Désactiver les Network Policies du VPC CNI
kubectl set env daemonset aws-node -n kube-system \
  NETWORK_POLICY_ENFORCING_MODE=disabled

Important : Les Network Policies existantes (standard Kubernetes) restent appliquées. Cilium les prend en charge automatiquement via le mode chaining.

Pièges à éviter

VPC CNI préfixe / max-pods

En chaining, Cilium ne gère pas l'IPAM. La limite de Pods par nœud reste celle du VPC CNI. Si vous êtes coincé, activez les préfixes /28 (VPC CNI v1.16+) pour gagner de la capacité :

bash

kubectl set env daemonset aws-node -n kube-system \
  ENABLE_PREFIX_DELEGATION=true
kubectl set env daemonset aws-node -n kube-system \
  WARM_PREFIX_TARGET=1

Security groups par Pod (SGPP)

Si vous utilisez les security groups par Pod, assurez-vous que ENABLE_POD_ENI=true est configuré sur le VPC CNI. Cilium n'interfère pas avec ce mécanisme.

⚠️ Non compatible EKS Auto Mode : les security groups par Pod demandent de pouvoir modifier le daemonset aws-node. En Auto Mode, AWS gère le CNI de bout en bout et ENABLE_POD_ENI n'est pas configurable. Pour SGPP, restez sur un cluster EKS standard (node groups gérés ou self-managed).

Masquerade (SNAT)

Ne pas activer ipMasqAgent de Cilium si vous avez déjà aws-node configuré pour le SNAT. Les deux risquent de créer des conflits sur les règles iptables.

yaml

# Désactiver le SNAT Cilium si le VPC CNI le gère déjà
enableIPv4Masquerade: false

Noeuds Windows

Le chaining ne fonctionne pas sur les nœuds Windows. Cilium repose sur eBPF, donc Linux uniquement. Les nœuds Windows restent sur VPC CNI seul.

Résumé

Fonctionnalité	VPC CNI seul	VPC CNI + Cilium chaining
IP native AWS	Oui	Oui
Security groups par Pod	Oui (sauf en Auto Mode)	Oui
Network Policies	Limitée	L3/L4/L7
Observabilité	CloudWatch	Hubble (flows, HTTP, DNS)
Chiffrement	Non	WireGuard / IPsec
ClusterMesh (multi-cluster)	Non	Oui
CLI diagnostic	aws CLI	`cilium connectivity test`
Complexité opérationnelle	Faible	Moyenne

Le chaining est la config que je recommande pour les clusters EKS qui veulent sortir du minimum viable sans perdre l'intégration AWS. Il ne remplace pas le VPC CNI, il le complète.

Retour d'expérience : la première fois, on avait laissé enableIPv4Masquerade: true côté Cilium alors que le VPC CNI faisait déjà le SNAT. Résultat, des règles iptables en doublon et des timeouts intermittents. Depuis, on désactive systématiquement le masquerade Cilium en chaining.