Open theAkito opened 2 years ago
Is this already solved?
@lucasscheepers
No, it's not officially fixed, yet.
However, if you need help setting up a workaround, by using a custom image, then I can help you with that. 🙂
@lucasscheepers
No, it's not officially fixed, yet.
However, if you need help setting up a workaround, by using a custom image, then I can help you with that. 🙂
Yeah I'm very interested in your workaround! So you set up your security context while building the image I suppose? I've to add that I'm using the Mattermost Operator Helm chart including the manifest file to deploy Mattermost. We decided to use this method instead of the Team or Enterprise Helm charts.
@theAkito Do you have time to share this with me?
@lucasscheepers
I'm truly sorry for answering so late. At first I forgot about this, then I didn't have enough time. 😞
If you still need help, you could for example send me a message at a -k i-- t- o.k - i- - - -t- - - s- - -u- ---- n- -- - -----e -- - - -- - -(at) p r o --- t o-- n- . ---m e---
(without the dashes and spaces, replacing (at)
with @
.
Once I understand your use case, I will probably just create a Github Gist with the solution for your setup.
I've to add that I'm using the Mattermost Operator Helm chart including the manifest file to deploy Mattermost.
Most likely, does not matter. My solution is based on the Docker image itself, so it's irrelevant in what way the Helm Chart or Mattermost is deployed, as long as it is based on the same type of Docker image, the Mattermost Helm Chart is using.
Thanks for answering. I was hoping you've had a solution that doesn't need to edit the Docker image because of lifecycle purposes. I came across a way to add the securityContext via the Mattermost manifest file, but unfortunately I've never accomplished this.
Looking something like this:
apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
spec:
# ...
resourcePatch:
deployment:
patch: '[{"op":"add","path":"/spec/template/spec/initContainers/0/securityContext","value":{"runAsUser": 1337}}]'
Nevertheless the priority to fix this decreased since PSP is deprecated and possibly we're going to use Policy Agent instead of PSP. In the meantime we're running containers as root.
BUT, if you've a working example like something above; I'm all ears!
Thanks for answering. I was hoping you've had a solution that doesn't need to edit the Docker image because of lifecycle purposes.
Yes, that's the problem. The problem is, that the user is hard-coded into the image, so to be able to actually run operations as an arbitrary user, you need to change the Dockerfile for that, unfortunately.
if you've a working example like something above; I'm all ears!
Since the securityContext
depends on what the image is using, there is no direct solution to this problem, other than fixing the Dockerfile.
At least, that's the case if you truly want the user you select in the securityContext
to be the lord over every operation. If you only need partial support for the specific user you want to configure, it may be enough to change the Helm Chart or apply a similar approach through a manifest file, as you suggested.
See the initial issue:
https://forum.mattermost.com/t/permission-error-but-permissions-are-permissive/13080
It's necessary for the Chart setup to respect the provided
securityContext
. If I provide the user and group ID123
and themattermost
process actually runs with those (it actually does, I checked), then the classicmattermost
user with the ID2000
shouldn't remain the user in charge.Related Issues:
128
142