Technical Tutorials

Le modèle de sécurité périmétrique traditionnel est obsolète. Dans les architectures cloud natives modernes, s'appuyer sur les frontières réseau pour isoler les charges de travail sensibles n'est plus suffisant. Les attaquants qui s'infiltrent dans le cluster peuvent souvent se déplacer latéralement sur l'ensemble du réseau. Pour y faire face, nous devons adopter une architecture Zero-Trust, où chaque paquet est considéré comme non fiable jusqu'à ce qu'il soit explicitement autorisé.

Sous Linux, la technologie du filtre de paquets Berkeley étendu (eBPF) du noyau a révolutionné la sécurité réseau. En exécutant des programmes sandboxés directement dans le noyau, eBPF permet une application de politiques à haute performance et à faible surcharge, sans les changements de contexte associés aux proxies iptables traditionnels ou à l'espace utilisateur. Ce billet de blog explore comment exploiter eBPF pour une micro-segmentation granulaire dans les clusters Kubernetes.

Pourquoi eBPF pour la micro-segmentation ?

Les règles de pare-feu Linux traditionnelles, telles que celles gérées par iptables, souffrent d'une complexité de recherche en O(N). À mesure que le nombre de règles augmente, les performances se dégradent considérablement. eBPF, en revanche, permet des recherches en O(1) à l'aide de tables de hachage. Plus important encore, les programmes eBPF peuvent opérer au niveau des sockets (avant que le paquet ne soit entièrement formé) ou au niveau XDP (eXpress Data Path), offrant une visibilité et un contrôle impossibles avec netfilter seul.

Dans le contexte de Kubernetes, des projets comme Cilium et Calico ont intégré eBPF pour fournir un réseau basé sur l'identité. Au lieu de s'appuyer uniquement sur les adresses IP, qui sont dynamiques et difficiles à gérer, eBPF nous permet d'attacher des métadonnées (identités de sécurité) aux charges de travail. Les politiques sont alors évaluées sur la base de ces identités, garantissant qu'un pod « frontend » ne peut communiquer qu'avec un pod « backend », quelle que soit leur adresse IP sous-jacente.

Implémentation des politiques avec Cilium

Cilium est la norme de fait pour le réseau basé sur eBPF dans Kubernetes. Il fournit une API déclarative pour définir les politiques réseau. Examinons un exemple pratique d'application de la micro-segmentation entre deux déploiements.

D'abord, nous définissons une politique réseau en YAML qui restreint le trafic entrant vers backend-service pour n'autoriser que le trafic provenant de frontend-service.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-restrict
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend-service
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

Lorsque cette politique est appliquée, Cilium compile ces règles en tables eBPF. Le programme eBPF attaché à la couche socket des pods backend-service vérifie l'identité source de chaque paquet entrant. Si l'identité source ne correspond pas à l'étiquette frontend-service, le paquet est abandonné silencieusement. Cette application se fait dans le noyau, ajoutant une latence négligeable par rapport aux proxys L7 de l'espace utilisateur.

Vérification de l'application des politiques

L'un des aspects les plus puissants des systèmes basés sur eBPF est l'observabilité. Vous pouvez vérifier que les politiques sont appliquées en inspectant les tables eBPF ou en utilisant le CLI Cilium pour suivre les flux réseau.

cilium monitor --follow --related-to-endpoint production/backend-service

Cette commande affichera des événements en temps réel montrant les paquets acceptés ou refusés. Vous verrez des entrées indiquant que le trafic provenant de sources non autorisées est abandonné, confirmant que la politique Zero-Trust est active. De plus, vous pouvez tracer l'exécution du programme eBPF lui-même à l'aide d'outils comme bpftool pour déboguer des problèmes de politique complexes au niveau du noyau.

Défis et bonnes pratiques

Bien qu'eBPF offre des performances supérieures, son implémentation nécessite une réflexion approfondie sur les versions du noyau et la compatibilité des pilotes. Toutes les fonctionnalités du noyau requises pour les fonctionnalités eBPF avancées ne sont pas disponibles sur les distributions plus anciennes. Il est recommandé d'exécuter les nœuds Kubernetes sur des versions de noyau 4.19 ou supérieures, avec 5.4+ étant idéal pour une parité fonctionnelle complète.

De plus, la gestion des programmes eBPF nécessite un nouvel ensemble de compétences. Les développeurs doivent comprendre les cycles de vie des tables, les contraintes du vérificateur et la sécurité mémoire. Des outils comme BCC et BPFtrace sont inestimables pour le débogage et la compréhension du comportement de ces programmes du noyau. Enfin, commencez toujours en mode audit avant d'appliquer les politiques pour vous assurer de ne pas rompre les chemins de communication critiques.

Conclusion

La segmentation réseau Zero-Trust n'est plus seulement une bonne pratique théorique ; c'est une exigence pour sécuriser les environnements cloud modernes. En exploitant eBPF sur Linux, nous pouvons appliquer une micro-segmentation granulaire et basée sur l'identité à la vitesse du câble. Des outils comme Cilium rendent cette technologie accessible aux utilisateurs de Kubernetes, fournissant la garantie de sécurité que nos charges de travail sont isolées par conception, et non seulement par défaut.

À mesure qu'eBPF continue d'évoluer, nous pouvons nous attendre à des capacités de sécurité encore plus sophistiquées, y compris la prise en charge L7 et une intégration plus profonde avec les technologies de service mesh. Pour les développeurs Linux et cloud natives, maîtriser eBPF devient une compétence essentielle dans le parcours vers une infrastructure sécurisée et résiliente.