Dynatrace Operator security

• Latest Dynatrace
• Reference
• 16-min read
• Updated on May 20, 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.

Deployment permissions

Installing and upgrading Dynatrace Operator require administrative privileges. If you don't use the cluster-admin cluster role, ensure the deploying subject has the permissions listed in this section. The required permissions also include patch to support helm upgrade and permissions to manage DynaKube and EdgeConnect custom resources.

Cluster-scoped resources

The deploying user or service account must be able to create, update, patch, and delete the following cluster-scoped resource types:

Namespace-scoped resources

The deploying user or service account must be able to create, update, patch, and delete the following resource types in the operator namespace:

For links to ClusterRole manifests for deploying Dynatrace Operator, see Deployer RBAC verbs.

Platform-specific resources

Depending on the target platform, the Helm chart creates additional resources that require extra deployer permissions.

GKE Autopilot

On GKE Autopilot clusters, the Helm chart automatically detects the auto.gke.io/v1/AllowlistSynchronizer API and creates an AllowlistSynchronizer resource as a Helm pre-install hook. This allowlists the CSI driver, log monitoring, and CSI job workloads required by the Operator.

The deploying user or service account needs the following additional permission:

OpenShift

On OpenShift clusters (detected via the security.openshift.io/v1 API or --set platform=openshift), the Helm chart creates additional ClusterRoles that grant use access to SecurityContextConstraints (privileged, nonroot, nonroot-v2). No additional deployer permissions are required if you use the recommended escalate approach described in Deployer RBAC verbs.

Deployer RBAC verbs: bind and escalate

Kubernetes enforces privilege escalation prevention: you can't create a ClusterRole granting permissions you don't already hold, and you can't create a ClusterRoleBinding referencing a ClusterRole whose permissions you don't hold.

The Dynatrace Operator Helm chart creates several ClusterRoles (for example, reading nodes, pods, and metrics). The deployer account needs to be able to create these ClusterRoles and their bindings. There are two approaches:

Option A: Use escalate and bind

Grant the escalate and bind verbs on RBAC resources to the deployer. This is a low-maintenance approach because the deployer's permissions don't need to be updated when the Operator's ClusterRoles change across versions.

Sample deployer ClusterRole manifest (includes CSI driver, GKE Autopilot, and OpenShift permissions):

With CSI driver

Option B: Expanded permissions if escalate or bind are prohibited

If your security policies prohibit the escalate or bind verbs, the deployer must already hold every permission that the Operator's runtime ClusterRoles grant. This means enumerating all Dynatrace Operator permissions in the deployer ClusterRole so that Kubernetes escalation prevention is never triggered.

Sample deployer ClusterRole manifest (no escalate, includes CSI driver, GKE Autopilot, and OpenShift permissions):

With CSI driver

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.

Cluster-wide permissions

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>