Integrating Dynatrace Operator into OpenShift environments requires understanding the specifics of both platforms. This guide depicts the necessary configurations, focusing on Security Context Constraints (SCCs) and the use of the CSI driver in various scenarios.
In OpenShift, SCCs provide control over pod permissions in a manner akin to the built-in Role-Based Access Control (RBAC) system of Kubernetes. SCCs specify the actions a pod can perform and define its levels of resource access.
To get an overview of all default and custom SCCs in an OpenShift cluster, execute the following command:
oc get scc
OpenShift provides default SCCs for a more standardized approach, while also supporting custom SCCs to cover more specific requirements.
This section provides an overview of the SCCs used by Dynatrace Operator, varying by OpenShift version, and serves as a reference. It also delves into the relationship between SCCs and earlier versions of Dynatrace Operator.
Component
OpenShift version 4.10 or earlier
OpenShift version 4.11+
Operator
privileged
nonroot-v2
Webhook
privileged
nonroot-v2
CSI Driver
privileged
privileged
OneAgent
privileged
privileged
ActiveGate
privileged
nonroot-v2
Dynatrace Operator deployments include and use custom SCCs, and no default SCCs are used.
Component
SCC
Operator
dynatrace-operator
Webhook
dynatrace-webhook
CSI Driver
privileged
(built-in SCC)
OneAgent
dynatrace-dynakube-oneagent-privileged
, dynatrace-dynakube-oneagent-unprivileged
ActiveGate
nonroot-v2
cloudNativeFullStack applicationMonitoring
For effective application monitoring, Dynatrace Operator adds CSI volumes to application pods. These volumes, provided by the CSI driver, contain necessary code modules needed for OneAgent injection. Given that SCCs regulate resource access levels, their role is vital in facilitating this integration.
Below are scenarios detailing the use of SCCs and instances where configuration might be necessary.
Application uses custom SCC
The utilized SCC must include csi
volume as described in Configure custom SCC for application monitoring.
OpenShift version 4.12 or earlier
Applications require custom SCCs that must include csi
volume as described in Configure custom SCC for application monitoring.
OpenShift version 4.13+
Default SCCs allow csi
volume by default, eliminating the need for a custom SCC.
The instructions for altering SCCs are applicable only to custom SCCs. Default SCCs, such as restricted
or restricted-v2
, should never be modified.
The following code snippet explains how to add the csi
volume to a custom SCC:
apiVersion: security.openshift.io/v1kind: SecurityContextConstraintsmetadata:name: <custom>...volumes:...- csi
For further details on SCC configuration options, see security context constraints documentation.
OpenShift version 4.13+
The CSI driver requires specific labeling for validation by the CSI Volume Admission plugin.
The necessary label is automatically added to the csidriver
resource. It is required for enabling CSI volumes injected by Dynatrace Operator using Webhook-based injection modes.
Manually label the CSI driver for applicationMonitoring
, hostMonitoring
, or cloudNativefullStack
.
kubectl label csidriver csi.oneagent.dynatrace.com security.openshift.io/csi-ephemeral-volume-profile=restricted