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

**URL:** <https://community.dynatrace.com/t/how-to-handle-sccs-with-openshift-4-12-when-monitoring-using-cloud-native/46110>\
**Category:** Dynatrace Tips\
**Tags:** openshift, kubernetes\
**Created:** [June 13, 2024, 4:20pm UTC](https://community.dynatrace.com/t/how-to-handle-sccs-with-openshift-4-12-when-monitoring-using-cloud-native/46110 "2024-06-13T16:20:36Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![yanezza](https://dub1.discourse-cdn.com/dynatrace/user_avatar/community.dynatrace.com/yanezza/32/5036_2.png) [@yanezza](https://community.dynatrace.com/u/yanezza)\
**Post date:** [June 13, 2024, 4:20pm UTC](https://community.dynatrace.com/t/how-to-handle-sccs-with-openshift-4-12-when-monitoring-using-cloud-native/46110/1 "2024-06-13T16:20:36Z")

</div>

Many customers, interested in **[Cloud Native](https://docs.dynatrace.com/docs/shortlink/how-it-works-k8s#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](https://docs.dynatrace.com/docs/shortlink/openshift-configuration#security-context-constraints-sccs), 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](https://docs.dynatrace.com/docs/shortlink/openshift-configuration#code-module-injection-for-application-monitoring).

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_)&nbsp;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](https://github.com/Azure/secrets-store-csi-driver-provider-azure/discussions/1062#discussioncomment-7267143) 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&nbsp;_SCC_.
- Use **Classic FullStack**.