Dynatrace Operator security

• 16-min read
• Updated on Mar 10, 2026

Kubernetes observability relies on components with different purposes, default configurations, and permissions. These different components need permissions to perform and maintain operational function of Dynatrace within your cluster.

Permission list

Dynatrace Operator

Purpose: Maintains the lifecycle of Dynatrace components. Replaces OneAgent Operator.

Default configuration: 1-replica-per-cluster

RBAC objects:

Cluster-wide permissions

Namespace dynatrace permissions

Dynatrace Operator Webhook Server

Purposes:

Default configuration: 1-replica-per-cluster, can be scaled

RBAC objects:

Cluster-wide permissions

Namespace dynatrace permissions

Dynatrace Operator CSI driver

Purpose:

Default configuration: 1-replica-per-node (deployed via a DaemonSet)

RBAC objects:

Cluster-wide permission

Namespace dynatrace permissions

ActiveGate

Kubernetes Platform Monitoring

Purpose: collects cluster and workload metrics, events, and status from the Kubernetes API.

Default configuration: 1-replica-per-cluster, can be scaled

RBAC objects:

Cluster-wide permissions

Dynatrace Kubernetes Security Posture Management (KSPM)

Purposes: Kubernetes Security Posture Management detects, analyzes, and continuously watches for misconfigurations, security hardening guidelines, and potential compliance violations in Kubernetes.

Default configuration: 1-replica-per-node (deployed via a DaemonSet)

RBAC objects:

Cluster-wide permissions

OneAgent

Purposes:

Default configuration: 1-replica-per-node (deployed via a DaemonSet)

RBAC objects:

Policy settings: Allows HostNetwork, HostPID, to use any volume types.

Necessary capabilities: CHOWN, DAC_OVERRIDE, DAC_READ_SEARCH, FOWNER, FSETID, KILL, NET_ADMIN, NET_RAW, SETFCAP, SETGID, SETUID, SYS_ADMIN, SYS_CHROOT, SYS_PTRACE, SYS_RESOURCE

Cluster-wide permissions

Dynatrace Log Module

Purposes:

Default configuration: 1-replica-per-node (deployed via a DaemonSet)

RBAC objects:

Cluster-wide permissions

Log monitoring requires the same cluster-wide permissions as OneAgent.

Dynatrace telemetry ingest

Purposes:

RBAC objects:

Cluster-wide permissions

Extensions

Purposes:

Default configuration:

The following components are required, regardless of which extensions are used:

RBAC objects:

Depending on the used extension, the following RBAC objects are required.

Namespace dynatrace permissions

Prometheus extension

Database extension

Prometheus extension

Purpose:

Default configuration:

RBAC objects:

Cluster-wide permissions

Database extension

Purpose:

Default configuration:

RBAC objects:

Namespace dynatrace permissions

Dynatrace Operator supportability

Purposes:

RBAC objects:

Opt-out:

Namespace dynatrace permissions

Dynatrace Operator API upgrade support

Purposes:

RBAC objects:

Opt-in:

Cluster wide permissions

Namespace dynatrace permissions

Security Controls of Dynatrace Operator components

The following table presents a detailed analysis of the security controls for Kubernetes components: Dynatrace Operator, Dynatrace Operator webhook, and Dynatrace Operator CSI driver. This report is based on:

Standards and abbreviations:

The Standard column references these abbreviations.

Dynatrace Operator components

Satisfied
Exception (see expand below)
Planned improvement (see expand below)

Planned improvement:
Namespace-scoped Roles for the Operator, Webhook, and CSI driver currently allow access to all secrets within their namespace. Improvement planned to restrict these Roles to specific secret names, consistent with ClusterRole configuration.

Managed components

Satisfied
Exception (see expand below)
Planned improvement (see expand below)

Planned improvement:
Disallow Secrets mounted as env variable: Dynatrace Collector currently uses environment variables for tokens; migrating to secret files is planned.

Pod security policies

These permissions used to be managed using a PodSecurityPolicy (PSP), but in Kubernetes version 1.25 PSPs will be removed from the following components:

Dynatrace Operator version 0.2.1 is the last version in which PSPs are applied by default, so it's up to you to enforce these rules. As PSP alternatives, you can use other policy enforcement tools such as:

If you choose to use a PSP alternative, be sure to provide the necessary permissions to the Dynatrace components.

Dynatrace Operator security context constraints

Dynatrace Operator version 0.12.0+

Starting with Dynatrace Operator version 0.12.0, the built-in creation of custom security context constraints (SCCs) has been removed for Dynatrace Operator and Dynatrace Operator–managed components. This change was made to reduce complications caused by custom SCCs in unique OpenShift setups.

Despite this update, the components maintain the same permissions and security requirements as before.

The following tables show the SCCs used in different versions of Dynatrace Operator and OpenShift.

It is still possible to create your own more permissive or restrictive SCCs that take your specific setup into consideration. You can safely remove the old SCCs that were created by a previous Dynatrace Operator version.

To remove the old SCCs, use the following command:

oc delete scc <scc-name>