User Accounts#

Initially, a Determined installation has two user accounts: admin and determined. Both of these accounts have blank passwords by default.

The admin user has the sole privilege to create users, change other users’ passwords, and activate/deactivate users.

Use det user change-password via the CLI to set a password for the admin user. This is highly encouraged for new installs.

det -u admin user change-password

The determined user is designed for ease of use on a single-user installation. However, teams will benefit from creating a Determined user account for each individual. Namely, having individual user accounts provides clearer authorship and improved filtering of entities. To create users in a Determined installation, use the admin user to create user accounts for each individual that would like to use Determined:

det -u admin user create <username>

Then, the determined user can be deactivated:

det -u admin user deactivate determined

This ensures that no one can access the Determined cluster as the determined user (any objects that were created by this user will remain).

Authentication#

WebUI#

The WebUI will automatically redirect users to a sign-in page if there is no valid Determined session established on that browser. After signing in, the user will be redirected to the URL they initially attempted to access.

Users can end their Determined session by selecting their profile name in the upper left corner and choosing Sign Out.

CLI#

In the CLI, the user login subcommand can be used to authenticate a user:

det user login <username>

Logging in results in a persistent session, which lasts for 30 days. The session can be terminated using:

det user logout

Temporary authentication#

In some cases, it may be useful to execute a single command as a specific user without starting a persistent session for that user (think of the sudo command on a Unix-like system). In Determined, this can be achieved with the -u flag:

det -u <username> ...

This will execute the command as the given user without creating a permanent session for that user. Although no persistent session is created, an authentication token is stored for that user so that future attempts to execute commands as that user will not require re-authenticating. This token can be discarded using the user logout subcommand:

det -u <username> user logout

Change Passwords#

Users have blank passwords by default. This might be sufficient for low-security or experimental clusters, and it still provides the organizational benefits of associating each Determined object with the user that created it. If desired, a user can change their own password using the user change-password subcommand:

det user change-password

An admin can also change another user’s password:

det -u admin user change-password <target-user>

Warning

Although Determined supports password-based authentication, communication between the CLI, WebUI, and master does not take place over an encrypted channel by default. See Security for information on configuring secure connections over HTTPS. Users should not be assigned “valuable” passwords, and passwords used with Determined should not be reused for other purposes.

List Assets#

WebUI#

Just as in the CLI, by default the WebUI will only show assets created by the current user. To see assets belonging to all users, uncheck the “Show only mine” checkbox in the filter panel found in the tab for each asset type.

CLI#

When using the CLI to list experiments, commands, etc., the default behavior is to only show assets belonging to the current user. It is possible to show assets owned by all users by passing the -a flag to the respective commands:

det experiment list -a   # List all experiments.
det command list -a      # List all commands.
det notebook list -a     # List all notebooks.
det tensorboard list -a  # List all TensorBoards.

Activate and Deactivate Users#

When a user is created, they are designated as active by default. Only active users can interact with Determined. The admin user can deactivate a user with the user deactivate subcommand:

det -u admin user deactivate <target-user>

All assets created by a deactivated user will remain available through both the WebUI and the CLI.

To reactivate a user, user activate can be used:

det -u admin user activate <target-user>

Run Tasks as Specific Agent Users#

If an experiment, notebook, or command task uses the bind_mount option in its Experiment Configuration Reference, it is often useful to set the Unix user and group on the agent that the task runs as. This allows the file permissions on the agent to be reflected in the task and vice versa.

This can be configured by linking a Determined user with the user and group configuration on an agent:

det user link-with-agent-user <target-user> --agent-uid <uid> --agent-user <username> --agent-gid <gid> --agent-group <group-name>

All arguments are required. This command can only be run by a system administrator.

Once set, any tasks created by the target user will be run as the specified user and group.

Note

By default, if a user is not linked with a user and group on an agent, tasks created by that user will run as the root user on the agent. If deploying on a Slurm/PBS cluster, running as the root user is only permitted if the launcher user_name is also set to the root user, as described in Configure and Verify Determined Master on HPC Cluster. This behavior may change in the future.

If the task does not use bind_mount option, the effect of running as root will be limited to the task container and not intrude on the agent itself.

The default user and group that will be used when a Determined user is not explicitly linked to a user and group on an agent can be configured in the master.yaml file located at /usr/local/determined/etc on the Determined master instance:

security:
  default_task:
    user: root
    uid: 0
    group: root
    gid: 0

Run Unprivileged Tasks by Default#

Some administrators of Determined may wish to run tasks as unprivileged users by default. In Linux, unprivileged processes are sometimes run under the nobody user, which has very few privileges. However, the nobody user does not have a writable HOME directory, which causes problems for some common tools like gsutil.

For convenience, the default Determined environments contain an unprivileged user named det-nobody, which does have a writable HOME directory. The det-nobody user is a suitable default user when using the default Determined environment images and when running containers as root is not desired. To use det-nobody by default, add the following configuration to master.yaml:

security:
  default_task:
    user: det-nobody
    uid: 65533
    group: det-nobody
    gid: 65533

When combining the det-nobody user with custom Docker images, administrators should either build the custom image as layers on top of the default Determined Environments as illustrated in Custom Images, or they should create the det-nobody user themselves in their custom images using groupadd and useradd.