Skip to content

Détection réseau dans Kubernetes

Vue d’ensemble

Dans ce lab, vous allez explorer la détection des attaques réseau dans Kubernetes.

L’environnement est basé sur l’application Google Cloud Platform Online Boutique (Microservices Demo). Commencez par examiner l’architecture globale de l’application.

Trois outils seront utilisés :

  • Cilium
    • Pile réseau pour la communication entre Pods et conteneurs
    • Permet d’observer les flux réseau
  • Neuvector
    • Plateforme complète de sécurité Kubernetes
    • Inspection du trafic, monitoring et mitigation
  • Kubesonde
    • Simule des comportements d’attaquants (scan ports/protocoles)

Objectifs

  • Comprendre l’apprentissage comportemental en runtime
  • Identifier les communications inter-services anormales

Contexte

La détection repose sur l’identification de connexions réseau hors du comportement attendu.

  1. Apprentissage d’un état normal (baseline)
  2. Détection des écarts (anomalies réseau)

Prérequis

  • 4 vCPU / 8 Go RAM / 20 Go disque
  • Helm, Minikube, kubectl

Structure

  1. Monitoring
  2. Détection (alerting uniquement)

Setup

Démarrer Minikube
minikube start --cni= --cpus=4

Expérience 1 – Cilium

Installation
helm repo add cilium https://helm.cilium.io
helm repo update
helm install cilium cilium/cilium   --namespace kube-system   --set hubble.enabled=true   --set hubble.relay.enabled=true   --set hubble.ui.enabled=true --set operator.replicas=1
Attendre que les pods soient prêts
kubectl get po -nkube-system

Dans un terminal séparé :

kubectl port-forward -n kube-system svc/hubble-ui 12000:80
Déployer l’application demo
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/tags/v0.10.3/release/kubernetes-manifests.yaml
Attendre que les pods soient prêts
kubectl get po
NAME                                     READY   STATUS    RESTARTS      AGE
adservice-dbd9db68f-hh4t7                1/1     Running   0             8m27s
cartservice-7d446cd6cd-x6nfg             1/1     Running   0             8m28s
checkoutservice-b45957b77-msxlw          1/1     Running   0             8m28s
currencyservice-768c464f5-v5vr8          1/1     Running   0             8m27s
emailservice-5756ddcbb5-p24jt            1/1     Running   0             8m28s
frontend-6d47d98676-znbjx                1/1     Running   0             8m28s
loadgenerator-645dcc4d68-bw89s           1/1     Running   0             8m27s
paymentservice-69c9f447bf-nsl9m          1/1     Running   0             8m28s
productcatalogservice-66db9f456f-bks69   1/1     Running   0             8m28s
recommendationservice-5767cf4d97-kh874   1/1     Running   0             8m28s
redis-cart-c8ff86559-plsgh               1/1     Running   0             8m28s
shippingservice-7c44749569-cjwx9         1/1     Running   0             8m27s

Accès : http://127.0.0.1:12000/

Question

Lorsque vous y êtes invité, cliquez sur le namespace par défaut afin d’observer le trafic. Que constatez-vous ?

Le graphe réseau obtenu ressemble-t-il à celui créé par les développeurs ?

Réfléchissez à la manière dont vous pourriez utiliser ces informations pour détecter des attaques réseau.

Expérience 2 – Neuvector

Installation
helm repo add neuvector https://neuvector.github.io/neuvector-helm
helm repo update
kubectl create namespace neuvector
kubectl label namespace neuvector "pod-security.kubernetes.io/enforce=privileged"
helm install neuvector --namespace neuvector --create-namespace neuvector/core --set bootstrapPassword="admin" --set cve.scanner.enabled=false --set cve.updater.enabled=false --set controller.replicas=1
Attendre que les pods soient prêts
# kubectl get po -nneuvector                                                                                                                                                            


NAME                                        READY   STATUS      RESTARTS   AGE
neuvector-cert-upgrader-job-jr2m5           0/1     Completed   0          34s
neuvector-controller-pod-844bbd9567-8mfzs   1/1     Running     0          80s
neuvector-controller-pod-844bbd9567-d848r   1/1     Running     0          80s
neuvector-controller-pod-844bbd9567-khtf8   0/1     Running     0          80s
neuvector-enforcer-pod-rrtx7                1/1     Running     0          80s
neuvector-manager-pod-7fdd7f94fc-bppgm      1/1     Running     0          80s
neuvector-scanner-pod-64867cb894-5zprv      1/1     Running     0          80s
neuvector-scanner-pod-64867cb894-r87c6      1/1     Running     0          80s
neuvector-scanner-pod-64867cb894-z65bj      1/1     Running     0          80s
Accès UI

Dans un terminal distinct, exécutez :

kubectl port-forward service/neuvector-service-webui -n neuvector 8443:8443

Puis, accédez à https://localhost:8443 (identifiant et mot de passe: admin)

Warning

Certificat non reconnu → utiliser “Advanced” puis continuer

Note

Le mot de passe doit être changé après la première connexion

Vous pouvez utiliser, par exemple, Admin1~! ou un mot de passe plus complexe

Phase d’apprentissage / runtime learning

Neuvector :

  • Observe les flux
  • Apprend les patterns
  • Génère des règles

Aller dans Network Activity sélectionnez ensuite l'espace de nom (namespace) default comme indiqué dans l'image suivante:

neuvector filter

Question

Quelles informations sont visibles ?

Différences avec Cilium ?

Accédez maintenant à Notifications -> Security Events.

C'est l'emplacement où les événements de sécurité s'afficheront. Familiarisez-vous avec l'interface.

Expérience 3 – Mouvement latéral

Simulez du trafic anormal en établissant une communication inattendue entre services :

kubectl exec -it deployment/emailservice -- wget --server-response frontend:80 -O-

Regardez maintenant l'onglet des événements de sécurité et répondez aux questions ci-dessous:

Question

Pourquoi aucun événement de sécurité n'a-t-il été déclenché ?

Pouvez-vous identifier des problèmes de sécurité possibles causés par cela ?

Observez-vous le même comportement dans Cilium ?

Expérience 4 – Neuvector Monitor Mode

Dans cette expérience, nous allons activer le mode de surveillance de Neuvector**

Allez à Policy>Groups et configurez tous les groupes dans l'espace de noms "default" en mode Monitor Mode.

Dans ce mode, les communications suspectes sont enregistrées et signalées, mais pas bloquées.

Simulons maintenant du trafic plus suspect :

kubectl exec -it deployment/emailservice -- wget --server-response google.com -O-

Note

Suspicion : un service email ne devrait pas contacter Internet

Question

Quand utiliser Monitor Mode ?

Quand est-ce dangereux ?

D’autres violations apparaissent-elles ?

Expérience 5 – Kubesonde

Installation
kubectl apply -f https://raw.githubusercontent.com/kubesonde/kubesonde/refs/heads/main/kubesonde.yaml
Attendre que les pods soient prêts
kubectl get po -nkubesonde-system
Probe

Ecrivez ceci dans un fichier nommé probes.yaml:

apiVersion: security.kubesonde.io/v1
kind: Kubesonde
metadata:
  name: kubesonde-sample
spec:
  namespace: default
  probe: all

Puis déployez‑le sur le cluster:

kubectl apply -f probe.yaml
Récupération des probes:

Dans un terminal distinct, exécutez :

kubectl --namespace kubesonde-system port-forward deployment.apps/kubesonde-controller-manager 2709

Attendez 3 minutes, puis :

curl localhost:2709/probes > probes.json
Analyse

Naviguez vers https://kubesonde.jackops.dev/ et téléversez-y les probes.

Question

Pourquoi le graphe diffère ?

Comparaison

Partie B — Inspection avec Neuvector et Cilium

Retournez à l’interface Neuvector et à celle de Cilium.

Question

Voyez‑vous de nouvelles alertes dans Neuvector ?

Les graphiques de connectivité dans Neuvector et Cilium ont‑ils changé ? Pourquoi ?

Nettoyage du lab

minikube delete