OpenShift & fsGroup SecurityContext

[ArthurVardevanyan]

This change in Operator 0.0.8 causes the pods to not start start due to OpenShift requiring the use of Random UIDs

OpenShift will inject a given fsGroup for a given namespace:

REF:

• https://github.com/dragonflydb/dragonfly-operator/pull/98/commits/22040fea90b2bcc40b65fdeabc3fd5e6bfd60039
• https://docs.openshift.com/container-platform/4.13/authentication/managing-security-context-constraints.html

[Pothulapati]

Interesting but Dragonfly binary also requires a specific fsGroup to let the binary inside have the required permissions on volumes. Any ideas on what do you think we should do? We could attach that group only when backups are scheduled but this would still cause this problem when there are backups needed.

[ArthurVardevanyan]

The random UIDs are per namespace not per pod, I wouldn't expect there to be an issue.

[Pothulapati]

So, We are trying to fix this. First, we want to explore how other Operators that also have a fsGroup being set work with Openshift

@ArthurVardevanyan Do you have any ideas on how we should fix this?

[ArthurVardevanyan]

Here is an example from the Crunchy Postgres Operator:

In Code: https://github.com/CrunchyData/postgres-operator/blob/0f8d886f8f2d16b1310255884709e47613a7f115/internal/controller/standalone_pgadmin/pod.go#L360-L362

In Yaml: https://github.com/ArthurVardevanyan/HomeLab/blob/production/kubernetes/quay/base/postgres/quay/postgres.yaml#L118

[ArthurVardevanyan]

PR: https://github.com/dragonflydb/dragonfly-operator/pull/163

[Pothulapati]

163 merged, hence closing!