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.
While Dynatrace permissions adhere to the principle of least privilege, make sure to secure the dynatrace namespace and limit access to a closed group of administrators and operators.
Purpose: Maintains the lifecycle of Dynatrace components. Replaces OneAgent Operator.
Default configuration: 1-replica-per-cluster
RBAC objects:
dynatrace-operatordynatrace-operatordynatrace-operatornodes""namespaces""secrets""secrets""dynatrace-bootstrapper-configdynatrace-dynakube-configdynatrace-metadata-enrichment-endpointmutatingwebhookconfigurationsadmissionregistration.k8s.iodynatrace-webhookvalidatingwebhookconfigurationsadmissionregistration.k8s.iodynatrace-webhookcustomresourcedefinitionsapiextensions.k8s.iodynakubes.dynatrace.comedgeconnects.dynatrace.comsecuritycontextconstraintssecurity.openshift.ioprivilegednonroot-v2dynatrace permissionsdynakubesdynatrace.comedgeconnectsdynatrace.comdynakubes/finalizersdynatrace.comedgeconnects/finalizersdynatrace.comdynakubes/statusdynatrace.comedgeconnects/statusdynatrace.comstatefulsetsappsdaemonsetsappsreplicasetsappsdeploymentsappsdeployments/finalizersappsconfigmaps""pods""secrets""events""services""serviceentriesnetworking.istio.iovirtualservicesnetworking.istio.ioleasescoordination.k8s.ioPurposes:
Default configuration: 1-replica-per-cluster, can be scaled
RBAC objects:
dynatrace-webhookdynatrace-webhookdynatrace-webhooknamespaces""secrets""secrets""dynatrace-dynakube-configdynatrace-bootstrapper-configdynatrace-metadata-enrichment-endpointreplicationcontrollers""replicasetsappsstatefulsetsappsdaemonsetsappsdeploymentsappsjobsbatchcronjobsbatchdeploymentconfigsapps.openshift.iosecuritycontextconstraintssecurity.openshift.ioprivilegednonroot-v2dynatrace permissionsevents""secrets""pods""configmaps""dynakubesdynatrace.comPurpose:
applicationMonitoring configurations, it provides the necessary OneAgent binary for application monitoring to the pods on each node.hostMonitoring configurations, it provides a writable folder for the OneAgent configurations when a read-only host file system is used.cloudNativeFullStack, it provides both of the above.Default configuration: 1-replica-per-node (deployed via a DaemonSet)
RBAC objects:
dynatrace-oneagent-csi-driverdynatrace-oneagent-csi-driverdynatrace-oneagent-csi-driversecuritycontextconstraintssecurity.openshift.ioprivilegeddynatrace permissionsdynakubesdynatrace.comsecrets""configmaps""dynakubes/finalizersdynatrace.comjobsbatchevents""Purpose: collects cluster and workload metrics, events, and status from the Kubernetes API.
Default configuration: 1-replica-per-cluster, can be scaled
RBAC objects:
dynatrace-activegatedynatrace-activegatenodes""pods""namespaces""replicationcontrollers""events""resourcequotas""pods/proxy""nodes/proxy""nodes/metrics""services""jobsbatchcronjobsbatchdeploymentsappsreplicasetsappsstatefulsetsappsdaemonsetsappsdeploymentconfigsapps.openshift.ioclusterversionsconfig.openshift.iodynakubesdynatrace.comsecuritycontextconstraintssecurity.openshift.ioprivilegednonroot-v2Purposes: 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:
dynatrace-node-config-collectordynatrace-kubernetes-monitoring-kspmevents""namespaces""nodes""nodes/metrics""nodes/proxy""pods""pods/proxy""replicationcontrollers""resourcequotas""serviceaccounts""services""cronjobsbatchjobsbatchdaemonsetsappsdeploymentsappsreplicasetsappsstatefulsetsappsnetworkpoliciesnetworking.k8s.ioclusterrolebindingsrbac.authorization.k8s.ioclusterrolesrbac.authorization.k8s.iorolebindingsrbac.authorization.k8s.iorolesrbac.authorization.k8s.ioPurposes:
Default configuration: 1-replica-per-node (deployed via a DaemonSet)
RBAC objects:
dynatrace-dynakube-oneagentdynatrace-dynakube-oneagentdynatrace-logmonitoringPolicy 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
nodes/proxy""securitycontextconstraintssecurity.openshift.ioprivilegedPurposes:
Default configuration: 1-replica-per-node (deployed via a DaemonSet)
RBAC objects:
dynatrace-logmonitoringdynatrace-logmonitoringLog monitoring requires the same cluster-wide permissions as OneAgent.
Purposes:
pods""namespaces""nodes""replicasetsappssecuritycontextconstraintssecurity.openshift.ioprivilegedThe 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:
Standard:
General:
Component needs to communicate with the Kubernetes API.
CSI:
CSI driver requires elevated permissions to create and manage mounts on the host system. For more details, see CSI driver privileges.
CSI driver communicates with kubelet using a socket on the host, to access this socket the CSI driver needs to run as root.
CSI driver stores/caches the OneAgent binaries on the host's filesystem, in order to do that it needs a hostVolume mount.
CSI driver needs seLinux level s0 for the application pods to see files from the volume created by the CSI driver.
The following table presents a detailed analysis of the security controls for Kubernetes components managed by Dynatrace Operator: ActiveGate, OneAgent (CloudNative), LogAgent. This report is based on:
Standard:
General:
Component needs to communicate with the Kubernetes API.
ActiveGate
The limits are highly dependent on the amount of data processed. Can be set via DynaKube.
OneAgent
Privilege escalation is needed for processes inside OneAgent container to get Linux capabilities.
Monitoring actions executed by OneAgent processes need the following capabilities.
Mounted host's root filesystem is accessed by all OneAgent modules and allows for log files access, disk metrics, and other host and process monitoring capabilities.
OneAgent needs access to host network namespace to provide host-level and process-level network health monitoring.
OneAgent needs access to host process table to collect performance metrics for all processes running on the host.
The limits are highly dependent on the amount of data processed. Can be set via DynaKube.
OneAgent needs access to kernel syscalls beyond the RuntimeDefault set for monitoring purposes.
OneAgent needs access to the mount command which is blocked by the default AppArmor profile.
OneAgent component needs to communicate with the kubelet /pods endpoint. The K8s token is not mounted to the Pod if LogMonitoring is turned off via Helm values.
OneAgent Log Module:
LogAgent needs to run as privileged container on OCP cluster to access its persistent storage. OCP persistent storage using hostPath.
AllowPrivilegeEscalation is always true when the container is run as privileged. Configure a Security Context for a Pod or Container.
LogAgent needs additional capability to get access to all monitored log files.
Needs access to log files on the host's filesystem.
The limits are highly dependent on the amount of data processed. Can be set via DynaKube.
The seccomp profile can be set via DynaKube in order to run in secure computing mode.
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 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.
dynatrace-operatornonroot-v2dynatrace-webhooknonroot-v2dynatrace-activegatenonroot-v2This SCC is the only built-in OpenShift SCC that allows usage of seccomp, which our components have set by default, and also the usage of CSI volumes.
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>