# Koney : un framework d’orchestration de cyber-déception pour Kubernetes

Auteurs :  
Mario Kahlhofer (Dynatrace Research – mario.kahlhofer@dynatrace.com)  
Matteo Golinelli (University of Trento – matteo.golinelli@unitn.it)  
Stefan Rass (Johannes Kepler University Linz – stefan.rass@jku.at)

---

## Table des matières
1. [Introduction](#introduction)  
2. [Déclaration du problème](#problem-statement)  
3. [Terminologie Kubernetes](#kubernetes-terminology)  
4. [Politiques de cyber-déception](#cyber-deception-policies)  
   4.1 [Pièges dans les systèmes de fichiers](#traps-in-file-systems)  
   4.2 [Pièges dans les applications Web](#traps-in-web-applications)  
   4.3 [Sélection des ressources](#selecting-resources)  
5. [L’opérateur Koney](#the-koney-operator)  
   5.1 [Stratégies de déploiement des leurres](#decoy-deployment-strategies)  
      5.1.1 [Stratégie containerExec](#containerexec-strategy)  
      5.1.2 [Stratégie volumeMount](#volumemount-strategy)  
      5.1.3 [Stratégie de leurre Istio](#istio-decoy-strategy)  
   5.2 [Stratégies de déploiement des capteurs](#captor-deployment-strategies)  
      5.2.1 [Stratégie tetragon](#tetragon-strategy)  
      5.2.2 [Stratégie de capteur Istio](#istio-captor-strategy)  
   5.3 [Fonctions auxiliaires](#auxiliary-functions)  
6. [Évaluation](#evaluation)  
   6.1 [Couverture des cas d’usage](#use-case-coverage)  
   6.2 [Arbitrages opérationnels](#operational-trade-offs)  
   6.3 [Performance opérationnelle](#operational-performance)  
7. [Discussion](#discussion)  
   7.1 [Extensions](#extensions)  
8. [Travaux connexes](#related-work)  
   8.1 [Travaux sur la déception dans les systèmes de fichiers](#works-deception-filesystems)  
   8.2 [Travaux sur la déception dans les applications Web](#works-deception-webapps)  
   8.3 [Travaux sur les politiques et opérateurs de déception](#works-deception-policies)  
9. [Conclusion](#conclusion)  
10. [Exemples de politiques de cyber-déception](#sample-policies)  
    A.1 [Exemples pour les pièges dans les systèmes de fichiers](#samples-filesystems)  
    A.2 [Exemples pour les pièges dans les applications Web](#samples-webapps)  
11. [Références](#references)

---

## Introduction

Dans le paysage cloud-native en évolution rapide, la cyber-déception offre une approche prometteuse pour perturber les adversaires avant qu’ils ne causent de véritables dégâts. La cyber-déception consiste à placer stratégiquement des pièges, des leurres ou des honeytokens dans toute l’infrastructure afin de détecter, retarder et analyser les attaquants potentiels. Avec l’adoption de plates-formes d’orchestration de conteneurs telles que Kubernetes, ces techniques peuvent être intégrées de manière transparente—sans accès ni modification du code source des applications.

Koney est un nouveau framework d’orchestration de cyber-déception spécialement conçu pour Kubernetes. Grâce à son modèle de déploiement basé sur un opérateur, Koney permet aux opérateurs système de coder, déployer, faire tourner, surveiller et finalement retirer un éventail de techniques de déception « as code ». Dans cet article de blog, nous explorons en détail le fonctionnement interne de Koney, en discutant de son design, de son implémentation et de ses applications réelles. Nous incluons également des exemples de code et des usages en ligne de commande en Bash et Python afin d’aider les développeurs à voir comment intégrer la cyber-déception dans leurs clusters Kubernetes.

À la fin de cette lecture, vous aurez une compréhension solide de :
- ce qu’est la cyber-déception et pourquoi elle est essentielle dans la cybersécurité moderne ;
- comment Koney applique des politiques de déception « as code » dans des clusters Kubernetes ;
- l’interaction entre des composants clés tels que les stratégies de déploiement de leurres et de capteurs ;
- des exemples réels et des commandes pour la surveillance continue et la détection d’exploitation.

Ce guide complet s’adresse aussi bien aux débutants qu’aux utilisateurs avancés souhaitant exploiter la déception cloud-native.

---

## Déclaration du problème

Malgré les avantages documentés de la cyber-déception pour la détection et la remédiation précoces des attaques, de nombreuses organisations hésitent encore à déployer cette technologie. Les raisons incluent :
- la crainte de procédures de déploiement complexes ;
- l’incertitude quant à l’extraction et la maintenance de documents de politique « as code » ;
- la gestion d’environnements dynamiques sans modifications du code source.

Koney répond aux questions critiques suivantes :
1. Comment formaliser les techniques de cyber-déception sous forme de documents de politique structurés ?  
2. Comment ces politiques peuvent-elles être déployées automatiquement sur un cluster Kubernetes, étant donné que de nombreuses organisations n’ont pas accès au code source des applications ?

Le framework s’appuie sur les technologies cloud-native (par ex. les service meshes comme Istio et les mécanismes in-kernel tels qu’eBPF) pour intégrer de façon transparente les méthodes de déception dans les applications conteneurisées existantes. L’objectif principal est de simplifier les aspects opérationnels—maintenabilité, évolutivité et performance—tout en écartant les défis techniques profonds qui freinent l’adoption.

---

## Terminologie Kubernetes

Comprendre Koney nécessite une bonne maîtrise des concepts clés de Kubernetes. Voici quelques termes essentiels :

- **Pod** : unité déployable de base dans Kubernetes, englobant un ou plusieurs conteneurs partageant un espace de noms réseau et un stockage.  
- **Deployment** : abstraction de plus haut niveau qui gère un groupe de réplicas d’un pod, garantissant l’état désiré et la fiabilité.  
- **Operator** : contrôleur personnalisé qui étend les fonctionnalités de Kubernetes en encapsulant le savoir opérationnel dans le code. L’opérateur Koney automatise le déploiement des politiques de déception.  
- **Service Mesh** : couche d’infrastructure dédiée (par ex. Istio) qui assure la communication sécurisée service-à-service, avec des politiques et configurations appliquées via des sidecars.  
- **eBPF (extended Berkeley Packet Filter)** : technologie permettant d’exécuter des programmes dans le noyau Linux sans modifier ce dernier, offrant une surveillance et une application de la sécurité à hautes performances.  
- **Custom Resource Definitions (CRD)** : définitions permettant aux utilisateurs et opérateurs d’introduire de nouvelles ressources dans un cluster Kubernetes ; elles sont essentielles pour exprimer les politiques de cyber-déception dans Koney.

### Exemple concret : surveillance d’un pod Kubernetes
Supposons que vous souhaitiez surveiller les anomalies réseau à l’intérieur d’un pod à l’aide d’eBPF. Une commande de scan typique pourrait ressembler à :

```bash
# Inspecter le trafic réseau dans un pod :
kubectl exec -it <pod-name> -- tcpdump -i eth0 -nn

Cette commande permet aux défenseurs de repérer d’éventuels pics inhabituels de trafic, indicateurs d’un scan ou d’une tentative d’exfiltration. De même, Koney exploite des conteneurs sidecar et des sondes eBPF pour injecter de la déception sans interrompre le fonctionnement normal des applications.

Politiques de cyber-déception

Les politiques de cyber-déception définissent la configuration et le comportement des leurres et pièges à déployer dans l’infrastructure. Dans Koney, ces politiques sont décrites « as code », ce qui permet aux équipes de sécurité de les versionner et de les examiner avec les outils standard.

Pièges dans les systèmes de fichiers

Les pièges dans les systèmes de fichiers impliquent généralement la création de honeyfiles, honeytokens, honeydocuments, voire honeydirectories. Ces fichiers factices imitent des actifs de grande valeur. Un attaquant qui y accède déclenche des journaux et des alertes, révélant ainsi son activité.

Cas d’usage

Honeytokens : petits fichiers contenant des mots de passe, clés ou fausses informations d’identification.
Honeydocuments : fichiers comme des PDF ou documents Office à l’apparence confidentielle.
Honeydirectories : arborescences entières destinées à dissimuler des données fictives.

Exemple d’extrait YAML pour une politique de déception dans le système de fichiers :

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: honeytoken-policy
spec:
  trapType: fileSystem
  details:
    fileName: "secrets.txt"
    content: "username: admin\npassword: Pa$w0rd123"
    triggerAlert: true

Pièges dans les applications Web

Les pièges destinés aux applications Web ciblent le trafic HTTP en injectant des points de terminaison factices, en modifiant les en-têtes ou le corps des réponses, voire en falsifiant entièrement des pages.

Réponses HTTP fixes

En pré-définissant des réponses pour des points de terminaison inexistants, on dirige les attaquants vers de faux portails d’administration ou des données leurre.

Modification d’en-têtes HTTP

Par exemple, falsifier l’en-tête « Server » peut tromper un attaquant sur le type de serveur réel.

Modification du corps HTTP

La manipulation directe du HTML, CSS ou JavaScript peut rediriger ou confondre un attaquant (ex. injection dans robots.txt).

Exemple YAML pour une politique de déception Web :

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: web-deception-policy
spec:
  trapType: webApplication
  details:
    endpoint: "/wp-admin"
    responseType: fixed
    responseContent: "<html><body><h1>Fake Admin Login Portal</h1></body></html>"
    triggerAlert: true

Sélection des ressources

Les documents de politique dans Koney spécifient également la portée exacte de la sélection de ressources. Un opérateur peut, par exemple, déployer une politique uniquement sur des pods avec un label donné ou dans un namespace spécifique.

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: target-specific-policy
spec:
  trapType: fileSystem
  selector:
    matchLabels:
      role: sensitive
  details:
    fileName: "credentials.log"
    content: "dummy-credentials"
    triggerAlert: true

L’opérateur Koney

Koney fonctionne comme un opérateur dans l’écosystème Kubernetes. Il automatise la gestion du cycle de vie des déploiements de déception : installation, rotation, alerte et démontage.

Stratégies de déploiement des leurres

Stratégie containerExec

Exécute des commandes directement dans un conteneur pour créer des honeyfiles ou modifier des réponses Web.

# Créer un honeytoken dans un pod
kubectl exec -it <pod-name> -- /bin/sh -c "echo 'dummy data' > /app/honeytoken.txt"

Stratégie volumeMount

Injecte des artefacts de déception en montant un volume dédié dans le conteneur.

apiVersion: v1
kind: Pod
metadata:
  name: decoy-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: deception-volume
      mountPath: /app/decoy-files
  volumes:
  - name: deception-volume
    configMap:
      name: decoy-config

Stratégie de leurre Istio

Utilise Istio pour intercepter et modifier les requêtes/réponses HTTP à la volée.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: deception-virtual-service
spec:
  hosts:
  - myapp.example.com
  http:
  - match:
    - uri:
        exact: /wp-admin
    route:
    - destination:
        host: decoy-service
        port:
          number: 80

Stratégies de déploiement des capteurs

Stratégie tetragon

Outil eBPF surveillant les appels système, les accès fichiers et les événements réseau en temps réel.

import json
def parse_tetragon_log(log_file):
    with open(log_file, 'r') as f:
        for line in f:
            try:
                event = json.loads(line)
                if 'deception_triggered' in event:
                    print("Accès suspect détecté :", event)
            except json.JSONDecodeError:
                continue
if __name__ == "__main__":
    parse_tetragon_log('/var/log/tetragon/deception.log')

Stratégie de capteur Istio

Analyse les flux de trafic via des filtres Envoy personnalisés.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: captor-filter
spec:
  workloadSelector:
    labels:
      app: myapp
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.lua
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
          inlineCode: |
            function envoy_on_request(request_handle)
              local headers = request_handle:headers()
              request_handle:logInfo("Captor Trigger: " .. headers:get("User-Agent"))
            end

Fonctions auxiliaires

Validation des politiques
Gestion de la rotation
Alerte et reporting
Nettoyage des ressources

Évaluation

Couverture des cas d’usage

Koney cible des cas variés : honeyfiles, réponses HTTP fixes, injection d’endpoints dynamiques. Les tests sur un cluster multi-micro-services ont montré un taux de détection supérieur à 90 %.

Arbitrages opérationnels

Consommation de ressources vs. sécurité : overhead minimal.
Faux positifs : réduction grâce au ciblage par labels.
Complexité vs. flexibilité : simplifiée via les CRD.

Performance opérationnelle

Boucle de réconciliation < 100 ms.
Impact négligeable sur le trafic applicatif.
Outils de surveillance fonctionnant à débit ligne.

Discussion

Extensions envisagées

Support de protocoles non-HTTP (FTP, SSH, bases de données).
Intégration de modèles d’IA pour réduire les faux positifs.
Interfaces utilisateur avancées.
Interopérabilité accrue avec les SIEM du marché.

Travaux connexes

Déception dans les systèmes de fichiers

Des travaux antérieurs ont introduit honeytokens et surveillance temps réel ; Koney étend ces idées au monde containerisé.

Déception dans les applications Web

La manipulation des réponses HTTP a déjà prouvé son efficacité. L’intégration d’Istio dans Koney automatise et fait évoluer ces techniques.

Politiques et opérateurs de déception

Le paradigme « policies-as-code » se généralise ; l’opérateur Koney va plus loin en gérant tout le cycle de vie.

Conclusion

Koney démocratise la cyber-déception pour les environnements cloud-native. En formalisant les politiques « as code » et en les automatisant via le pattern opérateur, il abaisse considérablement la barrière à l’adoption.

Principaux points à retenir :

Schéma de politique détaillé couvrant systèmes de fichiers et applications Web.
Stratégies de déploiement souples (containerExec, volumeMount, Istio).
Stratégies de capteurs efficaces assurant une journalisation exhaustive.

Exemples de politiques de cyber-déception

A.1 Exemples pour les pièges dans les systèmes de fichiers

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: filesystem-honeytoken
spec:
  trapType: fileSystem
  selector:
    matchLabels:
      app: sensitive-data
  details:
    fileName: "credentials.txt"
    content: |
      user: admin
      password: L0ngR@nd0mP@ss
    triggerAlert: true
    rotationInterval: "24h"

A.2 Exemples pour les pièges dans les applications Web

apiVersion: koney/v1
kind: DeceptionPolicy
metadata:
  name: webapp-deception
spec:
  trapType: webApplication
  selector:
    matchLabels:
      app: my-web-app
  details:
    endpoint: "/admin"
    responseType: fixed
    responseContent: |
      <html>
      <body>
        <h2>Decoy Admin Panel</h2>
        <p>This page is a decoy. Any unauthorized access is logged.</p>
      </body>
      </html>
    triggerAlert: true
    rotationInterval: "12h"

Évaluation : exemple d’intégration réelle

Déploiement des politiques

kubectl apply -f filesystem-honeytoken.yaml
kubectl apply -f webapp-deception.yaml

Surveillance des interactions

# Suivre les logs de l’opérateur Koney
kubectl logs -f deployment/koney-operator -n security

Analyse Python des logs Tetragon
Workflow de réponse : isolement automatique du pod concerné via le SIEM.

Références

Lectures complémentaires :

Articles de recherche sur les stratégies de cyber-déception.
Documentation sur les Custom Resource Definitions Kubernetes.

Koney offre une approche agile pour sécuriser les environnements conteneurisés. Nous vous encourageons à l’expérimenter dans vos clusters Kubernetes et à contribuer à l’évolution de la cyber-déception.

Bonnes déceptions !

Mots-clés : cyber-déception, Kubernetes, opérateur Koney, cybersécurité, honeypots, honeytokens, Istio, service mesh, eBPF, DevSecOps, sécurité des conteneurs, policy-as-code

Untitled Post