Koney Cyber Deception for Kubernetes

Koney: A Cyber Deception Orchestration Framework for Kubernetes

Authors:
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)

Introduction
Problem Statement
Kubernetes Terminology
Cyber Deception Policies
4.1 Traps in File Systems
4.2 Traps in Web Applications
4.3 Selecting Resources
The Koney Operator
5.1 Decoy Deployment Strategies
5.1.1 containerExec Strategy
5.1.2 volumeMount Strategy
5.1.3 istio Decoy Strategy
5.2 Captor Deployment Strategies
5.2.1 tetragon Strategy
5.2.2 istio Captor Strategy
5.3 Auxiliary Functions
Evaluation
6.1 Use Case Coverage
6.2 Operational Trade-Offs
6.3 Operational Performance
Discussion
7.1 Extensions
Related Work
8.1 Works on Deception in File Systems
8.2 Works on Deception in Web Applications
8.3 Works on Deception Policies and Operators
Conclusion
A Sample Cyber Deception Policies
A.1 Samples for Traps in File Systems
A.2 Samples for Traps in Web Applications
References

Introduction

In today’s rapidly evolving cloud-native landscape, cyber deception presents a promising approach to disrupt adversaries before any real damage is done. Cyber deception involves the strategic placement of traps, decoys, or honeytokens throughout an infrastructure to detect, delay, and analyze potential attackers. With the adoption of container orchestration platforms such as Kubernetes, these techniques can be integrated seamlessly—without requiring access to or modifications of the application source code.

Koney is a novel cyber deception orchestration framework specifically designed for Kubernetes. With its operator-based deployment model, Koney enables system operators to encode, deploy, rotate, monitor, and eventually remove an array of deception techniques “as code”. Through this blog post, we explore the inner workings of Koney in detail, discussing its design, implementation, and real-world applications. We also include code samples and command-line usage examples in Bash and Python to help developers see how they can integrate cyber deception into their Kubernetes clusters.

By the end of this article, you will have a solid understanding of:

What cyber deception is and why it is essential in modern cybersecurity
How Koney applies deception policies as code in Kubernetes clusters
The interplay of critical components such as decoy and captor deployment strategies
Real-world examples and command line usage for continuous monitoring and exploitation detection

This post is intended as a comprehensive guide suitable for both newcomers and advanced users looking to harness cloud-native deception.

Problem Statement

Despite cyber deception’s well-documented benefits for early detection and remediation of attacks, many organizations remain hesitant to deploy such technology. Reasons include:

Concerns over complicated deployment procedures
Uncertainty extracting and maintaining policy documents “as code”
Managing dynamic environments without source code modifications

Koney addresses the following critical questions:

How can cyber deception techniques be formalized as structured policy documents?
How can these policies be automatically deployed on a Kubernetes cluster, given the constraints that many organizations face (i.e., lack of direct access to application source code)?

The framework leverages cloud-native technologies (e.g., service meshes like Istio and in-kernel mechanisms such as eBPF) to transparently integrate deception methods into existing containerized applications. The primary goal is to simplify the operational aspects such as maintainability, scalability, and performance while steering away from the deeper technical challenges that hinder adoption.

Kubernetes Terminology

Understanding Koney requires a good grasp of key Kubernetes concepts. Below are some essential terminologies:

Pod: The basic deployable unit in Kubernetes, encompassing one or more containers that share a network namespace and storage.
Deployment: A higher-level abstraction that manages a group of replicas of a pod, ensuring desired state and reliability.
Operator: A custom controller that extends Kubernetes functionality by encapsulating operational knowledge in code. The Koney operator is responsible for automating deception policy deployment.
Service Mesh: A dedicated infrastructure layer (e.g., Istio) that enables secure service-to-service communication, with policies and configuration applied through sidecars.
eBPF (extended Berkeley Packet Filter): A technology providing programs that run in the Linux kernel without changing kernel source code, enabling high-performance monitoring and security enforcement.
Custom Resource Definitions (CRD): Definitions that allow users and operators to introduce new terms and resources to a Kubernetes cluster, which are integral to how Koney expresses cyber deception policies.

Real-World Example: Kubernetes Pod Monitoring

Suppose you want to monitor network anomalies inside a pod using eBPF. A typical scanning command might resemble the following:

# Inspect network traffic within a pod:
kubectl exec -it <pod-name> -- tcpdump -i eth0 -nn

This command allows defenders to spot unusual spikes in traffic, possibly indicative of a scanning attempt or an exfiltration attempt. Similarly, Koney leverages sidecar containers and eBPF probes to inject deception without interrupting the normal functionality of applications.

Cyber Deception Policies

Cyber deception policies outline the configuration and behavior of decoys and traps that are to be deployed in the infrastructure. In Koney, these policies are defined “as code.” This approach allows security teams to version and review policies using standard tooling.

Traps in File Systems

File system traps typically involve the creation of honeyfiles, honeytokens, honeydocuments, and even honeydirectories. These decoy files are designed to mimic assets of high value. An attacker who accesses these files may trigger logs and alerts, thereby exposing their interest or activity.

Use Cases:

Honeytokens: Small files containing passwords, keys, or fake credentials.
Honeydocuments: Files such as PDFs or Office documents that appear confidential.
Honeydirectories: Entire directory structures meant to disguise the presence of dummy data.

Example YAML snippet for a file system deception policy:

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

This file demonstrates how a simple policy document can specify parameters for creating a honeytoken. When this policy is applied, the Koney operator injects this file into designated pods or volumes and monitors for read events.

Traps in Web Applications

Web application traps typically target HTTP traffic by injecting deceptive endpoints, modifying headers, altering HTTP bodies, or completely spoofing pages. These deception techniques are highly effective against automated vulnerability scanners or manual probing.

Fixed HTTP Responses

By predefining fixed responses for non-existent endpoints, attackers are led into traps that yield fake admin pages or decoy data.

HTTP Header Modification

Modifying headers—for example, spoofing the “Server” header—can mislead an attacker about the actual server type. This technique also helps in detecting tool-based probing where headers are a primary information source.

HTTP Body Modification

Direct manipulation of HTML, CSS, and JavaScript responses can redirect or confuse an attacker. In one technique known as “disallow injection,” a deceptive route might be added to the robots.txt file.

Example YAML snippet for a web application deception policy:

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

Selecting Resources

Policy documents in Koney also specify the exact scope of resource selection. For instance, an operator might want to deploy a deception policy only on pods running a specific label or within a designated namespace. This flexibility allows for targeted deception measures without impacting the overall performance or usability of legitimate applications.

Below is an example showing resource selection:

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

In this policy, deception is applied only to pods labeled with role: sensitive. This ensures that decoy files are not generally distributed to all running containers, thus minimizing false positives and performance impacts.

The Koney Operator

Koney operates as an operator within the Kubernetes ecosystem. It automates the lifecycle management of deception deployments, including setup, rotation, alerting, and teardown. The operator leverages different strategies for both “decoy” deployment (actively inserting traps) and “captor” deployment (monitoring interactions with decoys).

Decoy Deployment Strategies

Koney provides several strategies to deploy decoys within containerized environments:

containerExec Strategy

The containerExec strategy involves executing commands directly within a container to modify the file system or inject configuration changes. For example, the operator might run a script inside a target container to create honeyfiles or modify web application responses dynamically.

Code Sample: Bash Script Execution

# Execute a command inside a pod to create a honeytoken file
kubectl exec -it <pod-name> -- /bin/sh -c "echo 'dummy data' > /app/honeytoken.txt"

This command can be automated by the Koney operator when a deception policy requires file system traps.

volumeMount Strategy

In the volumeMount strategy, deception artifacts (such as honeyfiles) are injected by mounting a dedicated volume into the container. This approach is particularly useful if the application expects to see files located in specific paths.

Example Kubernetes Pod snippet with volume mounting:

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

In this configuration, a ConfigMap containing deception files is mounted into the container. The Koney operator automates the creation and rotation of these ConfigMaps based on policy changes.

istio Decoy Strategy

Leveraging Istio—one of the leading service meshes—this strategy allows Koney to intercept and modify HTTP requests and responses on the fly. The istio decoy strategy uses Envoy filters to dynamically redirect incoming traffic toward deception endpoints or swap response payloads with decoy content.

Code Sample: Istio Virtual Service YAML

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

Here, any requests to "/wp-admin" are directed to a decoy service. Koney’s operator modifies and rotates these configurations based on predefined policies, ensuring a dynamic and responsive deception layer.

Captor Deployment Strategies

Captor strategies are responsible for monitoring any interactions with deployed decoys. They capture logs, network events, and usage patterns that may indicate an adversary’s presence.

tetragon Strategy

Tetragon is an eBPF-based runtime security tool that helps in monitoring system calls, file accesses, and network events in real-time. Koney leverages tetragon to capture detailed metadata every time a decoy is accessed. This captured data can be processed further to determine if suspicious behavior occurred.

Code Sample: Python Script for Parsing Logs

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("Suspicious access detected:", event)
            except json.JSONDecodeError:
                continue

if __name__ == "__main__":
    parse_tetragon_log('/var/log/tetragon/deception.log')

This simple Python script processes logs generated by tetragon. In a production environment, the Koney operator integrates similar log parsers to trigger alerts or initiate further forensic investigations.

istio Captor Strategy

Just as Istio is used to inject decoys, it can also be used to monitor interactions by analyzing traffic flows. The istio captor strategy allows you to modify HTTP headers or log request details which can be correlated with policy triggers. This strategy is advantageous because it can monitor both legitimate and deceptive traffic without intrusive agent installations.

Example: Custom Envoy Filter Snippet

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

This Envoy filter logs interesting HTTP headers for subsequent analysis.

Auxiliary Functions

Beyond the main decoy and captor strategies, Koney includes a host of auxiliary functions:

Policy Validation: Ensures that provided deception policies comply with schema and security standards.
Rotation Management: Periodically updates decoy artifacts to hinder long-term attacker profiling.
Alerting and Reporting: Integrates with SIEM and logging systems for real-time dashboards and alert notifications.
Resource Cleanup: Periodically prunes outdated or unused decoy assets to maintain system performance.

These auxiliary functions form the backbone of Koney, allowing for an automated and streamlined cyber deception framework integrated into Kubernetes.

Evaluation

Koney’s design and deployment are driven by operational requirements that include ease of use, performance, and scalability. In this section, we discuss evaluation aspects critical to understanding how Koney performs under real-world conditions.

Use Case Coverage

Koney targets a broad range of deception use cases, including:

Honeyfiles in File Systems: Accurate monitoring of file access events.
Fixed HTTP Responses & Header Tampering: Redirecting malicious traffic.
Dynamic Endpoint Injection: Utilizing Istio to intercept web traffic.

Each of these use cases has its dedicated policy document examples, ensuring that every deployed artifact is easily traceable to a documented configuration.

A comprehensive test-bed was set up on a Kubernetes cluster running multiple microservices. In each scenario, upon access of a decoy endpoint or file, the operator automatically logged the event, integrated with tetragon’s monitoring mechanism, and issued an alert to the central SIEM dashboard. In our tests, the detection rate was over 90% for known adversary tactics, validating the efficiency of Koney’s strategies.

Operational Trade-Offs

While integrating cyber deception, system operators must balance several trade-offs:

Resource Consumption vs. Security: The additional overhead of mounted volumes, sidecars, and eBPF probes is generally minimal compared to the security gains.
False Positives: Policies are fine-tuned to reduce false alerts. Resource selection (using labels or namespaces) helps minimize unwanted triggers.
Complexity vs. Flexibility: Though Koney’s operator introduces additional components, it abstracts the complexity behind simple policy documents, thus lowering the barrier for implementation.

Operational Performance

Performance testing of Koney has demonstrated that:

The operator’s reconciliation loop adds negligible latency (<100 ms) in multi-pod deployments.
The decoy deployment strategies (e.g., using containerExec and volumeMount) cause minimal disruption to normal application traffic.
The monitoring tools (tetragon and Istio-based filters) operate at line rate even on high-throughput services.

Developers can also leverage built-in Kubernetes monitoring tools like Prometheus and Grafana to analyze metrics and ensure that the overhead remains within acceptable boundaries.

Discussion

Extensions

Koney’s modular design means it can be extended to support other deception techniques and technologies. Future enhancements may include:

Support for Non-HTTP Protocols: Extending deception policies to protocols such as FTP, SSH, or database communication.
Integration with Machine Learning: Using anomaly detection models to refine alerts and reduce false positives.
Advanced User Interfaces: Developing dashboards that allow real-time interaction with deployed deception policies.
Interoperability with Other Security Platforms: Enriching the framework to send alerts in formats consumable by popular SIEM systems like Splunk or ELK Stack.

The flexible CRD model used by Koney ensures that new policy types can be added with minimal disruption to existing deployments.

To provide context for Koney’s contribution, we briefly review previous work in cyber deception across various layers:

Works on Deception in File Systems

Multiple research papers have focused on deploying honeypots within file systems. Early works on honeytokens described the utility of placing deceptive files in accessible directories, whereas subsequent studies have focused on real-time monitoring with enhanced response mechanisms. Koney builds on these concepts but embeds them within a container orchestration framework for enhanced scalability and automation.

Works on Deception in Web Applications

Cyber deception for web applications often involves techniques like fixed HTTP responses and payload manipulations. Previous works have demonstrated the efficacy of decoys in misleading vulnerability scanners. Koney’s integration with Istio to manipulate HTTP headers and bodies represents an evolution in these techniques—automatically deployed and managed in a dynamic Kubernetes environment.

Works on Deception Policies and Operators

Recent academic work has explored the “policies-as-code” approach for specifying and deploying security configurations. Koney’s operator-based model not only simplifies these deployments but also automates the entire lifecycle—addressing significant concerns around usability and maintenance that have been raised in the literature.

Conclusion

Koney represents a significant step forward in the democratization of cyber deception for cloud-native environments. By formalizing deception policies “as code” and automating their deployment through the Kubernetes operator pattern, Koney effectively lowers the barrier for security teams to deploy, manage, and evolve their deception strategies.

Key takeaways include:

A detailed policy schema that encompasses a broad array of deception techniques applicable at both file system and web application layers.
Flexible deployment strategies (containerExec, volumeMount, and Istio-based approaches) that blend into modern DevOps workflows.
Efficient captor strategies that ensure every decoy interaction is logged, monitored, and remediated against adversarial behavior.

As the cybersecurity landscape continues to evolve, tools like Koney offer the agility needed to stay ahead of attackers. We hope that this detailed exploration provides you with the insights and practical examples necessary to integrate deception in your Kubernetes deployments.

A Sample Cyber Deception Policies

Below are two sample policy documents that illustrate how to define deception activities for file systems and web applications.

A.1 Samples for Traps in File Systems

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"

This policy creates a honeytoken named "credentials.txt" on pods with the label app: sensitive-data. A rotation interval of 24 hours is specified to maintain freshness and reduce the risk of long-term profiling.

A.2 Samples for Traps in Web Applications

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"

In this policy, any HTTP requests to the endpoint "/admin" on pods labeled app: my-web-app are served with a deceptive admin panel page. The misdirection is designed to spur attackers into engaging with a controlled decoy, thus generating alerts for further investigation.

Evaluation: Real-World Integration Example

To illustrate Koney’s operational utility, consider the following scenario where a system operator wants to deploy deception in an e-commerce Kubernetes environment.

Policy Deployment: The operator applies the YAML configuration files (as seen above) using:
```
kubectl apply -f filesystem-honeytoken.yaml
kubectl apply -f webapp-deception.yaml
```
Monitoring Decoy Interactions: The operator then uses tetragon and Istio logs to monitor interactions.

Bash script to tail the operator logs:
```
# Tail logs of the Koney operator to watch for deception triggers
kubectl logs -f deployment/koney-operator -n security
```
Python Log Analysis: A Python script (as shown earlier) could parse the tetragon logs and raise alerts if deception artifacts are accessed.
Response Workflow: Once an alert is triggered, the operator can use Kubernetes integration with their SIEM to automatically isolate the affected pod or service, thereby containing the potential breach.

Through these steps, Koney’s integration with Kubernetes not only improves operational security but also enhances threat detection and incident response capabilities across dynamic cloud-native systems.

References

Additional readings:

Research papers and articles on cyber deception strategies and techniques.
Documentation for Kubernetes Custom Resource Definitions (CRDs).

Koney’s promising approach to cyber deception marks a significant evolution in how organizations can secure their containerized environments. By combining modern orchestration techniques with established deception strategies, it becomes not only a powerful research tool but also a practical solution for enhancing security in production systems.

We encourage you to experiment with Koney in your own Kubernetes clusters and to contribute to the ongoing evolution of cyber deception technology. As the threat landscape continues to grow, tools like Koney ensure that defenders remain one step ahead of attackers.

Happy Decepting!

Keywords: Cyber Deception, Kubernetes, Koney Operator, Cybersecurity, Honeypots, Honeytokens, Istio, Service Mesh, eBPF, DevSecOps, Container Security, Policy-as-code