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.

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.

that's true, i just try with this config:

the previous issue from enabling the plugins was solved, but it was an issue for the production-ready use.

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.

that's true, i just try with this config:

the previous issue from enabling the plugins was solved, but it was an issue for the production-ready use.

Back, when I posted this issue, I decided to fork the Helm Chart and create my own version, with my own image, etc... Very inconvenient workaround, but I needed it done.