mimir
mimir copied to clipboard
grafana
Add `global.openshift.enabled` config option
Signed-off-by: Radu Domnu [email protected]
What this PR does
Introduces global.openshift.enabled config option. When set, the securityContexts will not be set for Mimir components.
Which issue(s) this PR fixes or relates to
Checklist
- [ ] Tests updated
- [ ] Documentation added
- [ ]
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]
Thanks for contributing @radudd! I'm not super familiar with OpenShift, can you help me understand why this is needed?
As far as I know, OpenShift does support and recommend using security contexts, it just requires using SecurityContextConstraints instead of PodSecurityPolicies to define what is allowed.
The CHANGELOG has just been cut to prepare for the next Mimir release. Please rebase main and eventually move the CHANGELOG entry added / updated in this PR to the top of the CHANGELOG document. Thanks!
Thanks for contributing @radudd! I'm not super familiar with OpenShift, can you help me understand why this is needed?
As far as I know, OpenShift does support and recommend using security contexts, it just requires using SecurityContextConstraints instead of PodSecurityPolicies to define what is allowed.
Yes, that's correct. However, there are some specific considerations in OpenShift: (to simplify, let's focus for example on runAsUser parameter of SCC/PSP)
- SCCs are enforced in OpenShift and the default (and the recommended one if there are no special requirements) is the so called, "restricted" SCC. In this SCC, the runAsUser is set to MustRunAsRange.
- When an OpenShift namespace is created, a random UID range is generated uniquely for it. This is defined in the following annotation for the namespace:
openshift.io/sa.scc.uid-range - If no securityContext is specified for a pod, OpenShift assigns an UID depending on SCC that emits the pod. If the pods runs under the restricted SCC, the
runAsUserparameter of securityContext defaults to the first value of the UID range of the namespace. If desired, a pod can run of course with a different UID, but this will require a different SCC which sets runAsUser asMustRunAs(predefined UID) orRunAsAny(any UID). This, of course will have security implications.
Same applies for other security context parameters. Bottom line: In OpenShift, under the restricted SCC, if there are no particular requirements, securityContext shall be left unset, as the values which are populated are already secure.
Reference: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#security-context-constraints-pre-allocated-values_configuring-internal-oauth
Is there anything in the SCC that mimir-distributed bundles that makes it incompatible with OpenShift's "restricted" SCC? There were some changes recently that made sure that the majority of pods can run under a restricted policy.
Is there anything in the SCC that mimir-distributed bundles that makes it incompatible with OpenShift's "restricted" SCC? There were some changes recently that made sure that the majority of pods can run under a restricted policy.
The PR https://github.com/grafana/mimir/pull/3007 sets default securityContext options in values.yaml file. For example, runAsUser is set to 1001. This will not work in OpenShift, unless a more privileged SCC is assigned (to run the pod as a specific user). Overriding these values will also not work as the UIDs to run the pods are assigned dynamically and are not known in advance. In order for the restricted SCC to work properly in OpenShift, it's recommended to have the securityContext unset.
From IRL discussion it seems the existing rbac.type==scc can be used to disable rendering the securityContext fields. Depending on that instead of introducing a new configuration option would be our preferred solution.
