User Identity in Container¶
The identity of the user in the container determines its access to resources. For example, network file storage solutions typically use this identity to determine the container's access to network volumes. This document explains multiple ways for propagating the user identity into the container.
The Default: Root Access¶
In docker, as well as in Kubernetes, the default for running containers is running as root. The implication of running as root is that processes running within the container have enough permissions to change anything in the container, and if propagated to network resources - can have permissions outside the container as well.
This gives a lot of power to the Researcher but does not sit well with modern security standards of enterprise security.
By default, if you run:
runai submit -i ubuntu --attach --interactive -- bash
id, you will see the root user.
Use Run:ai flags to limit root access¶
There are two runai submit flags which control user identity at the Researcher level:
- The flag
--run-as-userstarts the container with a specific user. The user is the current Linux user (see below for other behaviors if used in conjunction with Single sign-on).
- The flag
--prevent-privilege-escalationprevents the container from elevating its own privileges into
sudoor changing system files.).
Equivalent flags exist in the Researcher User Interface.
Run as Current User¶
From a Linux/Mac box, run:
runai submit -i ubuntu --attach --interactive --run-as-user -- bash
id, you will see the users and groups of the box you have been using to launch the Job.
From a Linux/Mac box, run:
runai submit -i ubuntu --attach --interactive --run-as-user \ --prevent-privilege-escalation -- bash
then verify that you cannot run
su to become root within the container.
Setting a Cluster-Wide Default¶
The two flags are voluntary. They are not enforced by the system. It is however possible to set these flags as a cluster-wide default for the Run:ai CLI, such that all CLI users will be limited to non-root containers.
Save the following in a file (e.g
apiVersion: v1 data: config: | enforceRunAsUser: true enforcePreventPrivilegeEscalation: true kind: ConfigMap metadata: name: cluster-config namespace: runai labels: runai/cluster-config: "true"
kubectl apply -f cluster-config.yaml
Preventing privilege escalation at the cluster level limits non-root for all Run:ai CLI users. However, it does not prevent users or malicious actors from starting containers directly via Kubernetes API (e.g. via YAML files). To fully secure the system use Gatekeeper or work with OpenShift. See below for more information.
Another way to enforce the above flags is using Administrative templates. Templates allow you to force compliance on both the User Inteface and Command-line interface.
Passing user identity¶
Passing user identity from Identity Provider¶
A best practice is to store the user identifier (UID) and the group identifier (GID) in the organization's directory. Run:ai allows you to pass these values to the container and use them as the container identity.
To perform this, you must:
- Set up single sign-on. Perform the steps for UID/GID integration.
runai loginand enter your credentials
- Use the flag --run-as-user
id should show the identifier from the directory.
Passing user identity explicitly via the Researcher UI¶
Via the Researcher User Interface, it is possible to explicitly provide the user id and group id:
Using OpenShift or Gatekeeper to provide Cluster Level Controls¶
Run:ai supports OpenShift as a Kubernetes platform. In OpenShift the system will provide a random UID to containers. The flags
--prevent-privilege-escalation are disabled on OpenShift. It is possible to achieve a similar effect on Kubernetes systems that are not OpenShift. A leading tool is Gatekeeper. Gatekeeper similarly enforces non-root on containers at the system level.
Creating a Temporary Home Directory¶
When containers run as a specific user, the user needs to have a pre-created home directory within the image. Otherwise, when running a shell, you will not have a home directory:
runai submit -i ubuntu --attach --interactive --run-as-user -- bash The job 'job-0' has been submitted successfully You can run `runai describe job job-0 -p team-a` to check the job status Waiting for pod to start running... INFO Job started Connecting to pod job-0-0-0 If you don't see a command prompt, try pressing enter. I have no name!@job-0-0-0:/$
Adding home directories to an image per user is not a viable solution. To overcome this, Run:ai provides an additional flag
--create-home-dir. Adding this flag creates a temporary home directory for the user within the container.
- Data saved in this directory will not be saved when the container exits.
- This flag is set by default to true when the
--run-as-userflag is used, and false if not.