Run exec commands as specified user

[groeges]

When running exec commands from a devFile within a container we may need to run the commands as a different user to the user that is the default user within the container. I am therefore proposing we have a runAsUser within the exec, for example:

commands:
  - exec:
      id: init-deps
      name: init image dependancies
      component: java-openliberty-build
      commandLine: /project/bin/init-stack.sh
      runAsUser: root 
 - exec:
      id: stack-prep
      name: stack-prep
      component: java-openliberty-build
      commandLine: /project/bin/run-stack.sh prep
      runAsUser: java_user 
  - composite:
      id: setupContainer
      commands:
        - init-deps
        - stack-prep
      parallel: false
      group:
        name: init
        isDefault: true

So in this example there is a need to run some setup that requires to be run as root, and then some other setup that needs to be run as java_user.

It is not easy to switch userids within a shell script (bash) then different shell scripts need to be run and need to be run as different userids.

[l0rd]

That would be useful but we need to be cautious. Running as root may work on some Kubernetes clusters and not on others with more restrictive security policies. That would lead in situations where a devfile works on one cluster and fails on another one...

cc @elsony @kadel @davidfestal what do you think?

[amisevsk]

I see the usefulness here as well, but agree with @l0rd; this would be exclusively Kubernetes functionality, as runAsUser is typically not possible on OpenShift clusters (nor Kubernetes clusters for some configurations). The general recommendation on Kubernetes is to not allow running as root, as well. In general, relying on the default user for a container has been nothing but a headache for me.

However, it might also unblock some use cases, so it's definitely worth considering.

[l0rd]

Reviewed and approved

[l0rd]

For the records PodSecurityContext has runAsGroup and others fields. I think that for our use case and to keep things simple enough I would not add those ones in this first 2.0.0 release.

[davidfestal]

I started implementing the mode here, but now I have a question:
The exec command is mainly to execute a command line in an already-existing and already started container.
How could we change the userId the container is running as ?
Shouldn't this runAsUser information be in the container component itself ?

[l0rd]

@davidfestal yes you are right

[kadel]

How could we change the userId the container is running as ?

we cant' The only way how we could execute the command as a different user would be using sudo or su. But we can't do that, those binaries might not be in the container, and also I'm not sure if OpenShift with default securityContext would allow this.

Shouldn't this runAsUser information be in the container component itself ?

+1

[elsony]

Community call discussion 3/28:

1. No plan to implement. In general, it is problematic to implement running as a specific user. Some of the managed Kubernetes may not even allow switching to some users, e.g. root.
2. It is generally not a good practice to run containers as root users and it should be avoided if possible. See https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container for reference.