How to handle SCCs with Openshift <4.12 when monitoring using Cloud Native?

yanezza — Thu, 13 Jun 2024 16:30:34 GMT

Many customers, interested in Cloud Native mode, have come down on the hurdle of SCCs in case they had an Openshift version less than or equal to 4.12.

For those who don't know, but the Dynatrace doc explains it, in the case of OpenShift it is important to manage SCCs, in particular the coexistence between our CSI module (typical for Cloud Native mode deployment) and the default SCCs.

Cloud Native mode involves the use of CSI volumes to enable the injection of agents into application pods.

This requires that the CSI module be allowed from an SCC perspective used by the application pods themselves.

If the application pods are using a dedicated service account, this is not a particular problem, it would be sufficient to modify/add a custom SCC to allow the CSI volume to be mounted, as indicated by our doc.

The problem emerges when the application pods use a default service account, which in turn use the base SCCs.
With Openshift 4.12 or lower, these base SCCs however did not include CSI volume mount among the allowed ("fixed" by OpenShift 4.13) and RedHat advises against, in order not to lose support, modifying base SCCs (usually the restricted-v2) to include this permission.

What then are the possible solutions?
I here try to list a few, kindly ask for integration/correction:

Upgrade OpenShift to version 4.13 or higher
Create a dedicated service account with a custom SCC with the CSI permission. Then add this service account to the application workload (pod, deployment ...) - here is explained.
Is not suggested to edit the default service account.
If the application is using a dedicated service account, just bind a custom SCC with CSI enabled or edit an existing used SCC.
Use Classic FullStack.

topic How to handle SCCs with Openshift <4.12 when monitoring using Cloud Native? in Dynatrace tips

How to handle SCCs with Openshift <4.12 when monitoring using Cloud Native?