Community Voices
Explore thought pieces, announcements and product news
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mario_kahlhofer
Dynatrace Advocate
Dynatrace Advocate

TL;DR: We just released Koney 0.2.0, our open-source Kubernetes operator that automates cyber deception in your Kubernetes clusters. Define a DeceptionPolicy resource, and Koney plants honeytokens (fake credentials, decoy files) into matching containers, monitors them with eBPF via Tetragon, and forwards any access alert straight into Dynatrace as a security event. Install with Helm, write a few lines of YAML, and get a high-fidelity signal the moment an attacker touches a decoy.

Why deception, why now?

Traditional security is asymmetric: defenders have to close every hole, attackers only need to find one. With AI-powered attack agents now trying hundreds of vectors in the time it used to take a human to try one, that asymmetry is getting worse.

Deception flips the game. Instead of trying to keep attackers out, you place traps on the inside. A honeytoken (a realistic-looking decoy credential file in a path attackers commonly look for, like /run/secrets/.aws/credentials) only ever fires when something genuinely suspicious happens. No legitimate process reads a fake AWS key your security team planted. That makes it one of the highest-signal indicators of compromise you can deploy.

What has held back honeypots and honeytokens isn't the idea (which was coined by Lance Spitzner in the late 1990s and early 2000s); until now, no tool was capable of doing this end-to-end in Kubernetes. Manually creating, deploying, monitoring, and rotating decoys across dozens of containers is tedious and error-prone. Koney solves that.

What Koney does

Koney was developed by the Cloud-Native Research team at Dynatrace (with Matteo Golinelli from the University of Trento). You express your deception strategy as a custom resource, and Koney handles the rest:

  • Deploys the trap (the decoy) by mounting a volume or running a shell command inside matching containers.
  • Sets up monitoring (the captor) to detect file access at the kernel level, using Tetragon eBPF tracing policies, or alternatively the lightweight Kive operator by Giovanni Santini.
  • Collects alerts, and optionally forwards them to Dynatrace via a DeceptionAlertSink resource.

When you update a policy, Koney updates the traps. When you delete it, Koney removes them. When new pods spawn that match the selector, they automatically get the honeytoken too. It's deception-as-code.

A minimal policy looks like this:

apiVersion: research.dynatrace.com/v1alpha1
kind: DeceptionPolicy
metadata:
  name: aws-credentials-trap
spec:
  traps:
    - filesystemHoneytoken:
        filePath: /run/secrets/.aws/credentials
        readOnly: true
        fileContent: |
          [default]
          aws_access_key_id = FZWGQYZRVMVQKCWXWJ
          aws_secret_access_key = ToDNS2V5wkEuPmfocmNDHiVBspaywo
          region = us-east-1
      match:
        any:
          - resources:
              selector:
                matchLabels:
                  honeytoken: "true"
      decoyDeployment:
        strategy: containerExec
      captorDeployment:
        strategy: tetragon

Apply it, and any pod with the honeytoken: "true" label gets a believable-looking AWS credentials file that no legitimate process should ever touch.

Installing Koney

Koney installs in one line via Helm:

helm install koney --create-namespace -n koney-system --wait oci://ghcr.io/dynatrace-oss/koney/charts/koney --version 0.2.0

You'll also need an eBPF-based monitoring solution such as Tetragon running in the cluster. See the README for prerequisites, setup, and the full walkthrough.

Alerts in Dynatrace

The most useful part for Dynatrace users: alerts can flow directly into your Dynatrace environment. Add a DeceptionAlertSink pointing at your environment, and every honeytoken access becomes a security event visible in the Threats & Exploits app, with full context: pod, namespace, container, the process binary that read the file, PID, UID, and which policy was triggered.

image.png

From there, you can also run DQL:

fetch security.events
| filter event.provider == "Koney"

That means you can correlate honeytoken hits with the rest of your security and observability data, build Investigations around them, or wire them into Workflows. For example, you could automatically open a ticket against the namespace owner when a trap fires.

What's next

The current open-source release supports filesystem honeytokens. We're working on additional deception types for future releases.

If you want the full step-by-step walkthrough (installing Koney, deploying a demo app, triggering an alert, wiring up the Dynatrace sink), visit our GitHub repository. The research behind Koney was published in the Koney paper at the 4th Workshop on Active Defense and Deception (AD&D), co-located with EuroS&P '25; an open-access pre-print is also available on arXiv.

Koney is a research project by Dynatrace Research and is not officially supported by Dynatrace. Try it out, file issues, send PRs. We'd love your feedback.


This post was drafted with Claude (Anthropic) and revised by Mario Kahlhofer.