Depending on your Kubernetes distrib and the solution you're using for persistent volumes, MongoDB can face permissions related issues when accessing to the underlying volume. See this old issue: https://github.com/microcks/microcks/issues/322
Description
We should provide the ability to override the default non-privileged, empty security context of the MongoDB pod to adapt to such cases.
Implementation ideas
The idea is to provide the ability to specify it via the CR like below:
Reason/Context
Depending on your Kubernetes distrib and the solution you're using for persistent volumes, MongoDB can face permissions related issues when accessing to the underlying volume. See this old issue: https://github.com/microcks/microcks/issues/322
Description
We should provide the ability to override the default non-privileged, empty security context of the MongoDB pod to adapt to such cases.
Implementation ideas
The idea is to provide the ability to specify it via the CR like below: