kimera 0.4.2

AI-agent-driven Kubernetes penetration testing via MCP

Note: This product is not officially supported by Dynatrace.

What is Kimera?

Kimera is a Kubernetes security testing toolkit that exposes attack techniques as MCP tools. An AI agent connects to kimera's MCP server, plans multi-step attack chains using MITRE ATT&CK techniques, executes them against a cluster, and validates whether defenses caught each attack.

40 techniques across 8 phases — reconnaissance, credential access, privilege escalation, lateral movement, defense evasion, persistence, execution, and defense validation — all defined as YAML configs and executable via MCP or CLI.

🚨 SECURITY WARNING & LIABILITY DISCLAIMER

Kimera executes real Kubernetes attack techniques — service-account token theft, privilege escalation, lateral movement, and defense evasion — against live clusters, strictly for authorized security testing, defensive validation, and academic research. • Authorized Targets Only: Run Kimera only on clusters you own or have explicit, written permission to test. It must never be pointed at production, public, or third-party infrastructure without authorization. • No Liability: Users assume all responsibility and liability for the execution, deployment, or utilization of this toolkit. • Reporting: Report a security issue in Kimera itself privately via GitHub Security Advisories, not a public issue.

Architecture

┌─────────────────┐     MCP (stdio/HTTP)      ┌──────────────┐
│   AI Agent      │◄───────────────────────►  │ kimera-mcp   │
│  (Claude, etc.) │                           │  7 tools     │
└─────────────────┘                           └──────┬───────┘
                                                     │
                                              ┌──────▼───────┐
                                              │  Svc Layer   │
                                              │  assessor    │
                                              │  technique   │
                                              │  engine      │
                                              │  enumerator  │
                                              └──────┬───────┘
                                                     │ K8s API
                                              ┌──────▼───────┐
                                              │  Target      │
                                              │  Cluster     │
                                              └──────────────┘

Quick Start

Prerequisites

• Kubernetes cluster (1.24+) with kubectl configured
• Python 3.11+ (3.11, 3.12 and 3.13 are tested)

Install

uv tool install 'kimera[all]'      # or: pipx install 'kimera[all]'
uvx --from 'kimera[all]' kimera --help   # one-shot, no install

Extras are optional: llm for remediation generation, litellm for a proxied model backend, mcp-server for the MCP server, all for every one.

Contributing to Kimera itself, rather than using it as a package? See Development.

MCP Server (for AI agents)

# stdio transport (Claude Desktop, Cursor)
kimera-mcp

# HTTP transport (remote agents, CI/CD)
kimera-mcp --http

Claude Desktop configuration:

{
  "mcpServers": {
    "kimera": {
      "command": "uvx",
      "args": ["--from", "kimera[mcp-server]", "kimera-mcp"]
    }
  }
}

CLI

# Assess workloads against CIS Kubernetes Benchmark
kimera -n target-namespace assess

# Assess with JSON output
kimera -n target-namespace assess --json

# Validate that security controls actually block attacks
kimera -n target-namespace validate-control --type all

MCP Tools

Tool	Description
list_techniques	Browse 22 attack techniques by phase, with MITRE ATT&CK mappings
assess_target	Scan namespace for misconfigurations (CIS checks, structured findings)
enumerate_attack_surface	Discover deployments, services, secrets, RBAC in a namespace
attempt_technique	Execute a specific technique (C1=SA token theft, L1=network probe, etc.)
validate_defense	Test admission controllers, NetworkPolicies, RBAC (production-safe)
get_remediation	Look up fix guidance for a specific finding
reload_techniques	Pick up new YAML technique definitions without restart

Technique Registry

40 techniques defined in src/kimera/config/techniques/, each a YAML file with probes, evidence markers, MITRE mappings, and remediation.

Phase	Count	Examples
Reconnaissance	10	Enumerate namespaces, services, RBAC, secrets metadata
Credential Access	6	SA token theft, secret enumeration, cloud metadata SSRF
Defense Validation	6	Admission, NetworkPolicy, RBAC validation; defense-tool version detection
Lateral Movement	5	Network probe, DNS enumeration, data store access, app-mediated request
Privilege Escalation	4	Privileged escape, SYS_ADMIN abuse, RBAC escalation
Defense Evasion	4	Delete events, disable PSA, Kyverno bypass, Cilium label mutation
Persistence	3	CronJob persistence, SA with role binding, backdoor pod
Execution	2	Exec into pod via API, ephemeral container injection

Add a technique: drop a YAML file in src/kimera/config/techniques/, add to registry.yaml, call reload_techniques.

In-Cluster Deployment

Helm Chart (MCP server mode)

helm install kimera deploy/helm/kimera \
  --namespace kimera-system --create-namespace \
  --set targetNamespace=my-app \
  --set mode=server

The MCP server runs as a Deployment, accessible via ClusterIP Service on port 8000.

Helm Chart (Job mode — CI/CD)

helm install kimera-scan deploy/helm/kimera \
  --namespace kimera-system --create-namespace \
  --set targetNamespace=my-app \
  --set mode=job \
  --set job.args="{assess,--json}"

One-shot scan. Results in pod logs. Job auto-deletes after 5 minutes.

Docker

docker build -t kimera .
docker run --rm -v ~/.kube:/home/kimera/.kube:ro kimera -n my-app assess

CLI Reference

Command	Description
assess [--json]	Scan namespace against CIS checks
validate-control --type all|admission|network-policy|rbac	Test defense controls
exploit <type> [--service <workload>]	Demonstrate a specific exploit; --service overrides the profile mapping
vuln-service <svc> <type>	Introduce a vulnerability for testing
generate --type <type> [--apply]	Generate remediations via LLM
generate --from-findings <file>	Remediate only the workload the exploit ran from
generate --enrich dynatrace	Enrich LLM context with Dynatrace data
technique list [--phase <phase>]	Browse the technique registry
technique run <id> --pod <pod>	Run one technique; --dry-run prints the probe
query '<query>' [--json]	Query an observability provider
revert [type]	Undo all kimera changes
verify	Confirm security posture

Configuration

Layered config: src/kimera/config/default.yaml → profile → environment variables → CLI flags.

-n <namespace> loads profiles/<namespace>.yaml automatically when that file exists; -p overrides it.

Assessment checks are defined in src/kimera/config/checks/workload.yaml — 14 checks covering privileged mode, dangerous capabilities, host namespaces, resource limits, RBAC, and network policies.

Environment variable overrides are defined in src/kimera/config/env_mappings.yaml.

Configuration ships inside the installed package. To supply your own profiles and checks without editing an installed package, point KIMERA_CONFIG_DIR at a directory laid out the same way — it replaces the packaged one wholesale, so it needs its own default.yaml.

Network topology

network_topology in a profile drives NetworkPolicy generation. The map key names the workload an entry applies to.

network_topology:
  unguard-mariadb:
    allowed_ingress_from:                      # omit the key to leave ingress undeclared;
      - {app.kubernetes.io/name: like-service} # an empty list means block all ingress
  unguard-user-simulator:
    allowed_egress_to:                         # destinations outside the namespace
      - cidr: 0.0.0.0/0
        except: [10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254/32]
        ports: [80, 443]
        protocol: TCP

A workload with an external dependency needs allowed_egress_to, or a default-deny set severs it — the workload then fails to start while every app-to-app flow still passes, which is easy to misread as a segmentation failure. Declared destinations are added to the generated set deterministically, not left to the model, and are checked by kimera validate-control --type network-policy. Nothing is inferred: a destination that is not declared is not permitted.

Remediation scope

A namespace-wide set constrains every pod, which is more collateral than one exploited workload justifies. Feed the findings back instead:

kimera -n unguard exploit missing-network-policies --json > findings.json
kimera -n unguard generate --from-findings findings.json          # targeted scope

Targeted scope emits policies for the findings' source workload only — no default-deny, no policy for any other workload — permitting DNS, the dependencies network_topology declares for it, and its declared external egress. Every observed path is reported first as DENY (denied by the set), KEEP (declared, so preserved) or REVIEW (an undeclared in-namespace destination, denied and listed for a decision — declare it and regenerate to keep it). A deterministic pass then corrects any emitted policy that permits a denied path or severs a declared one, and reports what it changed.

Scope defaults to targeted with findings and namespace without; --scope overrides either way.

Observability Enrichment

Kimera supports pluggable enrichment from observability platforms via the EnrichmentProvider protocol. Dynatrace is the built-in provider:

# Enrich remediation context with Dynatrace KSPM + Smartscape data
kimera generate --type network-policies --enrich dynatrace
kimera generate --type network-policies --enrich dynatrace --enrich-strategy llm-query

Providers can also answer direct queries, which is how you measure whether a control had the effect it claims rather than feeding an LLM prompt:

# Run a query in the provider's own query language
kimera query 'fetch spans, from: -1h | filter k8s.namespace.name == "unguard" | limit 10'
kimera query '<query>' --provider dynatrace --json > evidence.json

A provider that refuses the request (HTTP 403) is reported as a denial naming the gateway, and the command exits non-zero — a scope problem is a fact about the token, not an empty result.

The query language stays the provider's own — DQL for Dynatrace — because a common cross-platform query language would be a translation layer that could only ever expose the subset every backend shares.

Adding a new provider: implement EnrichmentProvider and/or QueryProvider in src/kimera/container/integrations/<provider>/. The two are separate protocols, so a provider can support either alone.

Development

git clone https://github.com/dynatrace-oss/kimera
cd kimera
uv sync --all-extras

uv run pytest                         # test suite with coverage
uv run ruff format . && uv run ruff check .   # format + lint
uv run mypy .                         # strict type check
pre-commit run --all-files            # the CI gate, run locally

Safety

• All destructive MCP operations default to dry_run=True
• Admission testing uses server-side dry-run (zero persistence)
• Probe pods have activeDeadlineSeconds TTLs
• Operation journal tracks all changes for reliable revert
• The in-cluster SA's RBAC permissions are deliberately part of the test

References

• MITRE ATT&CK for Containers
• CIS Kubernetes Benchmark
• Microsoft Kubernetes Threat Matrix
• Model Context Protocol