Running Spark processes as separate users
Spark processes can be configured to run as separate operating system users.
By default, processes started by DSE are run as the same OS user who started the DSE server process. This is called the DSE service user. One consequence of this is that all applications that are run on the cluster can access DSE data and configuration files, and access files of other applications.
You can delegate running Spark applications to runner processes and users by changing options in
Where is the
The location of the
dse.yaml file depends on the type of installation:
Package installations + Installer-Services installations
Tarball installations + Installer-No Services installations
run_as process runner allows you to run Spark applications as a different OS user than the DSE service user.
When this feature is enabled and configured:
All simultaneously running applications deployed by a single DSE service user are run as a single OS user.
Applications deployed by different DSE service users are run by different OS users.
All applications are run as a different OS user than the DSE service user.
This allows you to prevent an application from accessing DSE server private files, and prevent one application from accessing the private files of another application.
sudo to run Spark applications components (drivers and executors) as specific OS users.
DSE doesn’t link a DSE service user with a particular OS user.
Instead, a configurable number of spare user accounts or slots are used.
When a request to run an executor or a driver is received, DSE finds an unused slot, and locks it for that application.
Until the application is finished, all of that application’s processes run as that slot user.
When the application completes, the slot user is released and available to other applications.
Since the number of slots is limited, a single slot is shared among all the simultaneously running applications run by the same DSE service user. Such a slot is released once all the applications of that user are removed. When there are not enough slots to run an application, an error is logged and DSE tries to run the executor or driver on a different node. DSE does not limit the number of slots you can configure. If you need to run more applications simultaneously, create more slot users.
Slots assignment is done on a per node basis. Executors of a single application may run as different slot users on different DSE nodes. When DSE is run on a fat node, different DSE instances running within the same OS should be configured with different sets of slot users. If they use the same slot users, a single OS user may run the applications of two different DSE service users.
When a slot is released, all directories which are normally managed by Spark for the application are removed. If the application doesn’t finish, but all executors are done on a node, and a slot user is about to be released, all the application files are modified so that their ownership is changed to the DSE service user with owner-only permission. When a new executor for this application is run on this node, the application files are reassigned back to the slot user assigned to that application.
The administrator needs to prepare slot users in the OS before configuring DSE.
run_as process runner requires:
Each slot user has its own primary group, which name is the same as the name of slot user. This is typically the default behaviour of the OS. For example, the
slot1user’s primary group is
The DSE service user is a member of each slot’s primary group. For example, if the DSE service user is
cassandrauser is a member of the
The DSE service user is a member of a group with the same name as the service user. For example, if the DSE service user is
cassandrauser is a member of the
sudois configured so that the DSE service user can execute any command as any slot user without providing a password.
umask setting to
007 for slot users so that files created by sub-processes are not accessible by anyone else by default, and DSE configuration files are not visible to slot users.
You may further secure the DSE server environment by modifying the OS’s
limits.conf file to set exact disk space quotas for each slot user.
After adding the slot users and groups and configuring the OS, modify the
spark_process_runner section enable the
run_as process runner and set the list of slot users on each node.
spark_process_runner: # Allowed options are: default, run_as runner_type: run_as run_as_runner_options: user_slots: - slot1 - slot2
In this example, two slot users,
slot2 are created and configured with DSE.
The default DSE service user of
cassandra is used.
Create the slot users.
sudo useradd -r -s /bin/false slot1 && sudo useradd -r -s /bin/false slot2
Add the slot users to the DSE service user’s group.
sudo usermod -a -G slot1,slot2 cassandra
Make sure the DSE service user is a member of a group with the same name as the service user. For example, if the DSE service user is
cassandra : cassandra
Log out and back in again to make the group changes take effect.
sudoersfile with the slot users.
Runas_Alias SLOTS = slot1, slot2 Defaults>SLOTS umask=007 Defaults>SLOTS umask_override cassandra ALL=(SLOTS) NOPASSWD: ALL
dse.yamlto enable the
run_asprocess runner and add the new runners.
# Configure the way how the driver and executor processes are created and managed. spark_process_runner: # Allowed options are: default, run_as runner_type: run_as # RunAs runner uses sudo to start Spark drivers and executors. A set of predefined fake users, called slots, is used # for this purpose. All drivers and executors owned by some DSE user are run as some slot user x. At the same time # drivers and executors of any other DSE user use different slots. run_as_runner_options: user_slots: - slot1 - slot2