Introduction

Users can run JS7 containers from for specific user accounts:

Depending on the container management system

• containers are started from the root account.
  • Containers are not necessarily operated for the root account, but can be configured to switch to an individual account during start-up.
• containers are started from a non-root account.
  • Containers are operated for the same non-root account.

Ownership of directories and files in JS7 containers is managed

• by default from the respective Dockerfile that creates the image.
• at run-time by the respective entrypoint.sh script:
  • The script can switch user account if started from the root account.
  • The script will use the indicated account if started from a non-root account.
• individually if users create their own Dockerfile, entrypoint.sh script and image, see JS7 - Build Container Images.

Consider changes to the start-up of JS7 containers:

Specifying User Accounts

Names of user accounts and groups are not relevant for the operating system of the container. Instead, the User ID and Group ID assigned the user account are specified.

• Examples for OS commands which return names and IDs of user accounts and groups:
  • User Account: id -u -n
  • Group Name: id -g -n
  • User ID: id -u
  • Group ID: id -g
• Syntactically user accounts are specified as <user-id>:<group-id>, for example 1000:1000.
• The name of the user account in any JS7 container is jobscheduler.
  • By default the jobscheduler user account is assigned the User ID 1000 and Group ID 0 (Group Name: root).
  • The name of the user account remains unchanged on start-up of a container. Instead, the container's user account is assigned the User ID and Group ID as specified on container start-up.

Accessing Volume Mounts

JS7 containers expose volumes

...

• If containers are operated for the root account then directories and files in exposed volumes are accessible to the root account only.
• If containers are operated for a specific account then directories and files in exposed volumes are accessible to the given account.

Starting Containers from the root Account

The default behavior for container management systems such as Kubernetes® is to start containers from the root account. However, this can be changed by security contexts (policies).

...

• Users are free to specify any user account for which the container will be operated.
• On start-up the container will actively own relevant directories and files to the user account specified.
• If a non-root Group ID is specified then group permissions will be handed over mapped to this group.

...

Using Run-time Accounts for Docker

Find examples for user account settings using the Docker run command:

...

# specify the root account's User ID and Group ID
docker run --user="0:0"

Using Run-time Accounts for Kubernetes

Find example for user account settings with Kubernetes® deployment files:

...

- name: RUN_JS_USER_ID
      value:  "0:0"

Starting Containers from non-root Accounts

The default behavior for container management systems such as OpenShift® is to start containers from a non-root user account that is assigned the root group.

...

• Users are free to specify any user account for which the container will be started and operated. Alternatively, This includes to specify temporary user accounts can be specified.
• The user account specified has to be assigned the root group.
• For OpenShift® policies see Adapting Docker and Kubernetes containers to run on Red Hat OpenShift Container Platform

Using Run-time Accounts for Docker

Find examples for user account settings using the Docker® run command:

# specify the account's User ID and the Group ID of the root account
docker run --user="100000:0"

Using Run-time Accounts for Kubernetes, OpenShift

Find examples for user account settings with Kubernetes® and OpenShift® deployment files:

...