[1] Proposed title of this feature request

-> Run MonitoringStack components with the least privileged SCC of restricted-v2 and dynamic UIDs.

 [2] What is the nature and description of the request?

-> One of my customer has there guidelines in there company for decentralized DevOps teams define that workload can only run with most restricted SCC `restricted-v2` and accordingly dynamic UIDs. Because the MonitoringStack use case is `multi-tenancy` the operation of (prometheus, alertmanager) it is the responsibility of the DevOps team and not the platform engineering team.

-> Cluster Observability Operator (COO): Run MonitoringStack components with SCC `restricted-v2`.

If you apply a MonitoringStack the components for prometheus and `alertmanager` run with SCC `nonroot-v2` by default.

apiVersion: monitoring.rhobs/v1alpha1
kind: MonitoringStack
metadata:
labels:
app: hack
name: example-hack-monitoring-stack
spec:
alertmanagerConfig:
disabled: false
logLevel: debug
prometheusConfig:
replicas: 2
resourceSelector: {}
resources:
limits:
cpu: 100m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
retention: 1d

-> It would be desirable that these components run with most restricted SCC `restricted-v2`.

 [3]Why does the customer need this? (List the business requirements here)

-> For decentralized DevOps teams define that workload can only run with most restricted SCC restricted-v2 and accordingly dynamic UIDs. Because the MonitoringStack use case is multi-tenancy the operation of (prometheus, alertmanager) it is the responsibility of the DevOps team and not the platform engineering team.

 [4] List any affected packages or components.