Dynatrace发布Koney开源Kubernetes蜜罐令牌研究项目博客

Imagine an attacker has breached your perimeter. They’ve gained access to a container in your Kubernetes cluster and are now searching through the file system, looking for secrets (credentials, tokens, keys) that they can use to further the attack.

What if those secrets were fake? What if, the moment the attacker attempts to read a fake credential, you get an alert? That’s the idea behind honeytokens: small, realistic-looking files placed in strategic locations to catch unauthorized access attempts. When someone touches them, you may have a very strong indicator of compromise (IoC) that warrants investigation because legitimate users would never interact with these decoys.

In this blog post, we introduce Koney , an open source research project that integrates seamlessly with Dynatrace. Koney is a Kubernetes operator that automates the deployment of honeytokens across your cluster. We’ll walk through the setup from scratch: installing Koney, writing your first deception policy, watching it scale across containers, and forwarding alerts directly to Dynatrace.

What is Koney?

Koney is a Kubernetes operator developed by the cloud-native security research team at Dynatrace, together with Matteo Golinelli from the University of Trento. It lets you define deception policies that describe which traps to deploy, where to deploy them, and how to monitor them. Currently, the open source version of Koney supports placing honeytokens in the file system. You can download or contribute on GitHub .

Why cyber deception?

Traditional security approaches focus on building walls and closing gaps: scanning for vulnerabilities with Runtime Vulnerability Analytics (RVA) , blocking attacks in real-time with Runtime Application Protection (RAP) , and fixing misconfigurations with Security Posture Management (SPM) . These are all essential. But they share a common limitation: defenders must close every hole, while attackers need to find just one .

With the rise of Generative AI , this asymmetry is getting worse. Attackers can increasingly use AI-assisted tools and automation to accelerate portions of the attack lifecycle.

Instead of trying to keep attackers out, cyber deception places traps on the inside. Now, the attacker, whether human or automated, must watch their steps to not trigger an alert. Honeytokens are one of the simplest deception techniques. Unlike noisy intrusion detection systems, a honeytoken generates a signal only when something truly suspicious happens: properly configured legitimate processes generally should not access a decoy credentials file planted by your security team.

Deception has a rich history in information security. Researchers like Lance Spitzner popularized the concept of honeypots in the early 2000s. Academic research has demonstrated that deception techniques can help detect and slow attacker activity in specific scenarios.

But widespread industry adoption has been held back by the operational burden: manually creating, deploying, monitoring, and rotating honeytokens across dozens of containers is tedious and error prone. Koney solves this by letting you express your deception strategy as a Kubernetes custom resource (a DeceptionPolicy object) and handling everything else automatically.

Using Koney for deception

When you apply a DeceptionPolicy , Koney:

Deploys the trap (the “decoy”) by mounting a volume or executing a shell command in the container.

Sets up monitoring (the “captor”) using Tetragon’s eBPF-based tracing policies to detect file access.

Collects alerts , logging them and optionally forwarding them to external systems like Dynatrace.

When you update a policy, Koney updates the traps. When you delete a policy, Koney removes them. When you spawn new pods that match the policy, Koney automatically deploys traps there too. It’s deception-as-code for Kubernetes.

Walkthrough: Honeytokens with Koney and Dynatrace

For this walkthrough, you’ll need:

A Kubernetes cluster.

kubectl installed and connected to your cluster.

helm , to install Koney and Tetragon.

Step 1: Install Koney

Install Koney with Helm in the koney-system namespace:

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

Verify that the Koney controller is running:

kubectl wait --for=condition=ready pod -n koney-system -l control-plane=controller-manager

That’s it. Koney is now watching for DeceptionPolicy custom resources in your cluster.

Step 2: Install Tetragon

Koney uses Tetragon for eBPF-based monitoring. Tetragon watches for file access events at the kernel level.

Add the Cilium Helm repository and install Tetragon:

helm repo add cilium https://helm.cilium.io

helm repo update

helm install tetragon cilium/tetragon -n kube-system --set dnsPolicy=ClusterFirstWithHostNet

The dnsPolicy=ClusterFirstWithHostNet setting is required so that Tetragon can resolve the addresses of Koney’s internal services to forward alerts. If you have Tetragon already installed, make sure to set this option.

Verify that Tetragon is running:

kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon

Step 3: Deploy a sample application

To see Koney in action, we need an application running in the cluster. Create and apply a demo-app.yaml manifest with label honeytoken: “ true ” set in the pod labels. Alternatively, you can also use any existing application in your cluster; just make sure the relevant pods carry the label honeytoken=true. We’ll use this in our deception policy to select which containers get honeytokens.

# demo-app.yaml   apiVersion :  apps/v1   kind :  Deployment   metadata :      name :  demo-app   spec :      selector :        matchLabels :          app :  demo-app      template :        metadata :          labels :            app :  demo-app            ho n ey t o k en :   "true"        spec :          containers :          -   name :  nginx            image :  nginx

kubectl apply -f demo-app.yaml

At this point, there are no honeytokens in the container. Let’s verify that:

kubectl exec -it deploy/demo-app -- ls /run/secrets/

You’ll only see the standard Kubernetes service account token but no traps … yet.

Step 4: Write a DeceptionPolicy

A  DeceptionPolicy  is a custom resource that describes what to deploy and where.

We’ll place a decoy credentials file at  /run/secrets/.aws/credentials . This is a common path that attackers look for when hunting for cloud provider secrets. Credential files in well-known paths are among the first things attackers look for after gaining a foothold.

Here’s the full policy:

#  ho n ey t o k en .yaml   apiVersion :  research.dynatr ac e.com/v1alpha1   kind :  DeceptionPolicy   metadata :      name :   aws - cred e n t ial s -trap   spec :      strictValidation :   true      mutateExisting :   true        traps :        -   filesystem Ho n ey t o k en :            filePath :  /run/secrets/. aws / cred e n t ial s            readOnly :   true            fileContent :  |             [default]              aws_ ac cess_key_id  = FZWGQYZRVMVQKCWXWJ              aws_secret_ ac cess_key  = ToDNS2V5wkEuPmfocmNDHiVBspaywo             region = us-east-1               [staging]              aws_ ac cess_key_id  = BPDHLBUJTYMKRVBMNB              aws_secret_ ac cess_key  = Jf4mTvTG5zbLksf464nYwEVyDkbjdp             region = eu-central-1               [prod]              aws_ ac cess_key_id  = GQRMYWAXADTVUPFMZJ              aws_secret_ ac cess_key  = gUFQzyJWJSkMkWpay4Umxzg4oFkkju             region = us-east-1            match :            any :              -   resources :                  selector :                    matchLabels :                      ho n ey t o k en :   "true"            decoyDeployment :            strategy :  containerExec          captorDeployment :            strategy :  tetragon

Let’s break this down:

filesystemHoneytoken defines the trap type and sets path and content for a realistic credentials file