KSPM Kubernetes with Dynatrace: enable it and read the checks

A week before an audit, a security reviewer asks for the list of namespaces that accept any inbound traffic. You have no answer to hand, and no latency graph holds it. That is the gap KSPM Kubernetes (Kubernetes Security Posture Management) fills in Dynatrace: a running inventory of configuration drift, kept by the platform you already use for monitoring.

I treat it here as an operations decision rather than a recipe: what the tool reads, what it costs in privileges, how to wire it through the DynaKube, and which rules to open first. Everything applies to Dynatrace SaaS, based on the « Latest Dynatrace » pages I read. I checked nothing for Dynatrace Managed and will not pretend otherwise.

KSPM Kubernetes: two sources, one pool of events

KSPM does not scan the cluster from outside. It combines two separate reads. A node configuration collector, run as a DaemonSet, re-reads each machine every minute. The ActiveGate queries the Kubernetes API once an hour. Both feed compliance events kept in the Grail bucket default_securityevents_builtin.

Why does the collector matter? Without it, roughly 30% of the checks return no verdict. The one exception is the Security Essentials standard, which ignores fine-grained node configuration and so works without it.

Before you say yes: the privilege bill

This is the point I would put to the security lead first. To read a node’s configuration, the collector has to mount the host root filesystem, hold specific Linux capabilities and reach the host PID namespace, according to the Operator security page. A security tool that widens the attack surface deserves an explicit conversation.

Two size ceilings apply: up to 100 nodes and 3,000 pods per cluster. On cost, billing runs in host-hours under the Dynatrace Platform Subscription model; for any other licence the documentation sends you to Dynatrace.

• Minimum versions: Dynatrace 1.305, Operator 1.5.0, ActiveGate 1.321.
• Kubernetes monitoring must already be running (see deploying OneAgent with the Operator).
• An Operator token in a secret in the dynatrace namespace.

Wiring KSPM into the DynaKube

If the token secret does not exist yet, create it with your own value, and keep it out of Git:

kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>"

The manifest below is for Operator 1.11.0 or later (v1beta6). I show it as the vendor publishes it, in a screenshot, then comment on the blocks that matter.

Source : docs.dynatrace.com

• mappedHostPaths is the exact list of what the collector may read on the host. Seven paths: /boot, /etc, /proc/sys/kernel, /sys/fs, /sys/kernel/security/apparmor, /usr/lib/systemd/system, /var/lib. Review it with your security team: it is your exposure perimeter.
• kubernetesMonitoring replaces, from Operator 1.11.0, the activeGate.capabilities plus kubernetes-monitoring declaration you must keep on older versions.
• kspmNodeConfigurationCollector carries the image (public.ecr.aws/dynatrace/dynatrace-k8s-node-config-collector, 1.6.3 in the example) and two tolerations so it can land on control-plane nodes. From 1.11.0 the image resolves by itself from the public registry.
• With an ActiveGate older than 1.311 you also need two properties under [kubernetes_monitoring]: kubernetes_configuration_dataset_pipeline_enabled = true and kubernetes_configuration_dataset_pipeline_include_node_config = true.

kubectl apply -f dynakube.yaml

How to check that it works

I rely on three observations, in this order: the DynaKube reports Running, the collector DaemonSet (label app.kubernetes.io/component=kspm) has every pod ready, and the ActiveGate StatefulSet is ready. The screenshot below reuses the documentation’s sample output, not output from a span.observer cluster.

Source : docs.dynatrace.com

Then the interface: Settings, Analyze and alert, Application security, Kubernetes Security Posture Management. An Enable Security Posture Management button turns the feature on for the environment, and a twin screen exists per cluster, with Test configuration. One handy detail: from Operator 1.9.0, a first DynaKube written for KSPM switches it on without any click.

Where to start when reading the results

Open Assessment results. Rules are sorted from the worst failures to the least important, with four possible outcomes: Failed, Passed, Manual, Not relevant. A rule is « Failed » as soon as a single assessed resource breaks it; the Findings tab tells you which one.

Severity (Critical, High, Medium, Low) comes from the Common Configuration Scoring System. Clicking a rule unfolds its details, the resources involved and the offending properties. The screenshot shows that panel with a DORA-standard rule, taken from the documentation for lack of a better one; the layout is the same for a Kubernetes rule.

Source : docs.dynatrace.com

To answer our reviewer from the opening, the network rules in the Security Essentials standard (maintained by Dynatrace) are the most telling:

• Namespaces should have at least one network policy (Medium, DTSE-83171): any namespace without a NetworkPolicy is flagged. That is literally the list requested.
• Workloads should not use the host network (High, DTSE-83175).
• Workloads should not use host ports (Medium, DTSE-83201).
• Workloads should not use the NET_RAW capability (Medium, DTSE-83203).

The same standard covers RBAC rights (reading secrets, wildcards), privileged or root containers and hostPath volumes. One example of a « Manual » result: without the node collector, the kubelet staticPodPath rule cannot be settled. To dig into the events themselves, Investigations and Notebooks are the entry points; the matching DQL query page was not read in detail for this article.

What KSPM will not do for you

• « Manual » results cannot yet be acted on inside the tool, according to the concepts page.
• Support level varies by distribution and version for each standard; Security Essentials aims at all those Kubernetes monitoring accepts.
• A « Passed » is not a certificate. No page promises compliance: it is a review aid.
• It judges configuration, never code or images. For that, a scan such as Trivy or Application Security takes over.

My rollout order

• A test cluster first, since the collector reads sensitive host paths.
• Critical and High first, then namespaces lacking a network policy.
• The DynaKube in Git, and the Operator kept current through the update procedure.

Frequently asked questions

Does KSPM work on Dynatrace Managed?

I cannot say: the pages I read cover the SaaS version. Look for the equivalent page for your Managed version before planning anything.

Do I have to deploy the node configuration collector?

In practice, yes. Without it roughly 30% of the checks get no verdict and some rules fall to « Manual ». Only the Security Essentials standard can do without.

Where do I find the compliance events?

In the Grail bucket default_securityevents_builtin. Investigations queries them, Notebooks shares reports.

Conclusion

A few DynaKube fields, one collector per node and an ActiveGate are enough to answer the audit question. The real trade-off is not technical: it is accepting elevated privileges on your nodes in exchange for visibility. Try it on a test cluster, read the network and critical rules first, then decide.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Content written from the official documentation (KSPM page), read on 8 November 2026; the screenshots reuse its examples. Features change quickly: check versions and fields in the documentation for your environment.

---

Originally published on span.observer. French version: https://span.observer/fr/kspm-kubernetes-dynatrace-dynakube/.