[mattermost-team-edition] Respect custom securityContext

See the initial issue:

https://forum.mattermost.com/t/permission-error-but-permissions-are-permissive/13080

Apparently, the user mattermost inside the Docker Image is hard-coded to user and group ID 2000. Even though, the mattermost process is clearly running as the user (ID) I desire, it still uses the mattermost user with the ID 2000 somewhere in-between.

This is clearly a bug, as it would mean, that this app can collide with any other map, which uses the same ID for its user.

It's necessary for the Chart setup to respect the provided securityContext. If I provide the user and group ID 123 and the mattermost process actually runs with those (it actually does, I checked), then the classic mattermost user with the ID 2000 shouldn't remain the user in charge.

Related Issues: #128 #142

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.