Jacek Lewandowski

Recap from part 1 of this post -&nbsp;<a href="/blog/2017/05/dse-51-resource-manager-part-1-network-connections-security">DSE Resource Manager is a custom version of Spark Standalone cluster manager</a>. In the first part of this post we explained how the network security was improved in DSE 5.1 for Apache Spark™ applications. Here we will show how the executor processes are started and what we improved in DSE 5.1 in terms of security and processes separation.

DSE Resource Manager comes with a customizable implementation of the mechanism used to control the driver and executor lifecycles. In particular we provide an alternative to the default mechanism which allows processes to be run as separate system users. Follow this blog post to learn how this impacts the security of your DSE cluster, how it can be configured and how you can verify what it actually does. We will also show a step-by-step guide to demonstrate how it works.

<h2>OSS Spark Standalone Master - prior to DSE 5.1</h2>

Spark executors (and drivers when deployed in the cluster mode) are run on DSE nodes. By default these processes are started by DSE server and are run by the same OS user who runs DSE server. This obviously has some security implications - we need to fully trust the applications which are run on the cluster because they can access DSE data and configuration files. The applications can also access files of each others.

<a href="https://www.datastax.com/wp-content/uploads/2017/06/DSE-5-1-Resource-Manager-part-2-FIg-1.jpg"><img alt="" src="https://www.datastax.com/wp-content/uploads/2017/06/DSE-5-1-Resource-Manager-part-2-FIg-1.jpg" /><img alt="Resource Manager fig 1 (2)" data-entity-type="file" data-entity-uuid="101f5998-95cd-4424-a4ea-0a540c62ae2d" src="https://www.datastax.com/sites/default/files/inline-images/DSE-5-1-Resource-Manager-part-2-FIg-1.jpg" /></a>

Fig. 1 - Running executors and drivers in OSS Spark Deployment (DSE 5.0 and older) 
All processes are run as the same system user thus all of them have the same permissions

DSE 5.1 introduces a new feature which allows to delegate running Spark application components to a runner which can be chosen in DSE configuration, in&nbsp;dse.yaml. The legacy behaviour is now implemented as a “default” runner.

<h2>“RunAs” runner</h2>

DSE 5.1 brings also the&nbsp;run_as&nbsp;runner which allows to run Spark applications on behalf of a given OS user. Basically the system user,&nbsp;dse,&nbsp;cassandra, or whoever runs DSE server is not used to run users’ applications. Additionally applications of different DSE users are run as different system users on the host machine. That is:

<ul>
	<li>all the simultaneously running applications deployed by a single DSE user will be run as a single OS user</li>
	<li>applications deployed by different DSE users will be run by different OS users</li>
	<li>the DSE user will not be used to run applications</li>
</ul>

<img alt="Resource Manager fig 2 (2)" data-entity-type="file" data-entity-uuid="fdb2e4ea-621a-4f15-b96b-82e956380513" src="https://www.datastax.com/sites/default/files/inline-images/DSE-5-1-Resource-Manager-part-2-FIg-2.jpg" /><a href="https://www.datastax.com/wp-content/uploads/2017/06/DSE-5-1-Resource-Manager-part-2-FIg-2.jpg"><img alt="" src="https://www.datastax.com/wp-content/uploads/2017/06/DSE-5-1-Resource-Manager-part-2-FIg-2.jpg" /></a>

Fig. 2 - Running executors and drivers with RunAs runner / DSE Resource Manager (DSE 5.1) 
DSE node process and processes belonging to different DSE users are run as different OS users thus they may have different permissions

The above assumptions allows implementing security rules which protect DSE server private files and prevent accessing private files of other applications.

<h2>Mechanism</h2>

DSE leverages the sudo program to run Spark application components (driver, executors) as specific OS users. Unlike Hadoop/Yarn resource managers, DSE does not link a DSE user to a particular OS user. Instead, a certain number of spare user accounts (slots) are used. When a request to run an executor or a driver is received by DSE server, it looks up an unused slot, and locks it for that application. Until the application is finished, all of its processes will be run as that slot user. Then, the slot user will be released and can be used by another application.

Since the number of slots is limited, a single slot is shared among all the simultaneously running applications run by the same DSE 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, there will be error reported and DSE will try to run the executor or driver on a different node. DSE does not limit the number of slots you can configure so, if you need to run more applications simultaneously, simply create more slots. The most reasonable default is the number of cores available to the Spark Worker on that DSE node because there will never be more distinct executors running simultaneously than the number of available cores (each executor uses at least one core).

Slot assignment is done on per node basis, that is the executors of one application may run on different slots on different DSE nodes. An even more important implication is that when DSE is run on a fat node, different DSE instances running within the same OS should be configured with a disjoint sets of slot users. Otherwise, it may end up with a single OS user running applications of two different DSE users.

<a href="https://www.datastax.com/wp-content/uploads/2017/06/DSE-5-1-Resource-Manager-part-2-FIg-3.jpg"><img alt="" src="https://www.datastax.com/wp-content/uploads/2017/06/DSE-5-1-Resource-Manager-part-2-FIg-3.jpg" /><img alt="Resource Manager fig 3 (2)" data-entity-type="file" data-entity-uuid="fd90a923-fa7b-4d43-98e5-f0d4bc59f3a5" src="https://www.datastax.com/sites/default/files/inline-images/DSE-5-1-Resource-Manager-part-2-FIg-3.jpg" /></a>

Fig. 3 - Slot assignment on different nodes

Each DSE instance manages slot users independently. Make sure that if you run multiple DSE instances in a single OS they should use different slot users

<h2>Cleanup procedure</h2>

RunAs runner cleans up those files which are created in default locations such as the RDD cache files and the content of executor and driver work directories.

A slot user is used to run executors and drivers of one DSE user at one time. When the slot is released, it can be used by a different DSE user. Therefore we have to make sure that some files created by applications on each worker node are handled properly, in particular:

<ul>
	<li>When the slot is released, those files will not be accessible to newly started applications which will be run as the same slot user</li>
	<li>When we run executors or a driver of the application again on the same worker node (after the slot was previously released), the application files will be accessible again to that application</li>
</ul>

The runner we implemented does not follow what files are created by the application but there are two locations common to each Spark applications which we can control:

<ul>
	<li>Application work directory - it is created under Spark worker directory, which is defined in&nbsp;/etc/dse/spark/spark-env.sh&nbsp;as&nbsp;SPARK_WORKER_DIR&nbsp;and by default it is set to&nbsp;/var/lib/spark/worker. There is a subdirectory for each application, and then a subdirectory for each executor. For example, in those directories executor standard out and standard err streams are saved.</li>
	<li>RDD cache location - the location of cache is also defined in&nbsp;/etc/dse/spark/spark-env.sh&nbsp;as&nbsp;SPARK_LOCAL_DIRS&nbsp;and by default it is set to&nbsp;/var/lib/spark/rdd. There are subdirectories with randomly generated names which are created by executor and driver processes.</li>
</ul>

To ensure the aforementioned security requirements against the above locations the runner changes ownership and permissions of these locations in runtime. In particular, when a slot is released (the last process running on the slot has finished) the runner changes the ownership of the application directories and their content from the slot user to DSE service user so that no slot user cannot access them. On the other hand, when executors of the application are about to be run again on a worker node, the ownership of the application directories and their content is changed back to the slot user which is newly assigned to that application.

There is one more detail in this regard - what will happen if the worker is killed or the node dies suddenly and the runner is unable to perform cleanup? This problem is fixed in the way that when the worker starts, the first thing it does is to change the ownership of all remaining application directories to DSE service user. When executors of some application are run again on this worker node, they will follow the scenario described above and the application directories will be made accessible to those executors.

Note that if your application creates files somewhere else, you need to clean up those files on your own.

<h2>Configuration</h2>

In order to start working with&nbsp;run_as&nbsp;runner, the administrator needs to prepare slot users in the OS. run_as runner assumes that:

<ul>
	<li>each slot user has its own primary group, whose name is the same as the name of slot user (usually a default behaviour of the OS)</li>
	<li>DSE service user (the one as who DSE server is run) is a member of each slot's primary group</li>
	<li>sudo&nbsp;is configured so that DSE service user can execute any command as any slot user without providing a password</li>
</ul>

We also suggest to override umask to 007 for slot users so that files created by sub-processes will not be accessible by anyone else by default, as well as make sure DSE configuration files are not visible to slot users. One more step to secure DSE server environment can be modifying limits.conf file in order to impose exact disk space quota per slot user.

The only settings which the administrator needs to provide in DSE configuration is a selection of run_as runner and a list of slot users to be used on a node. Those settings are located in&nbsp;dse.yaml, in&nbsp;spark_process_runner&nbsp;section.

<h2>Example configuration - configure run_as runner with two slot users: slot1 and slot2</h2>

<ol>
	<li>Create 2 users called slot1, slot2 with no login; each such user should have primary group the same as its name:&nbsp;slot1:slot1, slot2:slot2</li>
</ol>

$ sudo useradd --user-group --shell /bin/false --no-create-home slot1 
$ sudo useradd --user-group --shell /bin/false --no-create-home slot2

<ol start="2">
	<li>Add DSE service user (the one as who DSE server is run) to the slot user groups - DSE service user has to be in all slot user groups</li>
</ol>

You can find the DSE service user name by looking into&nbsp;/etc/init.d/dse&nbsp;- there is the entry which define DSE service user, for example (let it be cassandra in our case):

CASSANDRA_USER="cassandra"

Then, add that user to each slot user primary group:

$ sudo usermod --append --groups slot1,slot2 cassandra

By invoking the following command you can verify group assignment:

$ id cassandra 
uid=107(cassandra) gid=112(cassandra) groups=112(cassandra),1003(slot1),1004(slot2)

<ol start="3">
	<li>Modify&nbsp;/etc/sudoers&nbsp;file by adding the following lines (remember to use&nbsp;visudo&nbsp;to edit this file):</li>
</ol>

<pre>
Runas_Alias &nbsp;&nbsp;&nbsp;&nbsp;SLOTS = slot1, slot2
Defaults&gt;SLOTS &nbsp;umask=007
Defaults&gt;SLOTS &nbsp;umask_override
cassandra &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ALL=(SLOTS) NOPASSWD: ALL
</pre>

<ol start="4">
	<li>Modify&nbsp;dse.yaml&nbsp;so that:</li>
</ol>

<pre>
spark_process_runner:
 &nbsp;&nbsp;&nbsp;runner_type: run_as

 &nbsp;&nbsp;&nbsp;run_as_runner_options:
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;user_slots:
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- slot1
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- slot2
</pre>

The above settings configure DSE to use&nbsp;run_as&nbsp;runner with two slot users:&nbsp;slot1&nbsp;and&nbsp;slot2.

<ol start="5">
	<li>Do those changes on all the nodes in data center where you want to use&nbsp;run_as&nbsp;runner. After applying the configuration restart all the nodes.</li>
</ol>

Next, given our workers have at least 2 cores available, we will run two applications but two different users so that a single worker will simultaneously run executors of both applications.

<ol>
	<li>Start two applications in separate consoles</li>
</ol>

$ DSE_USERNAME=john DSE_PASSWORD=password dse spark --total-executor-cores 3 --master dse://?connection.local_dc=DC1 
$ DSE_USERNAME=anna DSE_PASSWORD=password dse spark --total-executor-cores 3 --master dse://?connection.local_dc=DC1

Go to the Spark Master UI page and you will see that both application are registered and running. Then go to Spark Worker UI of one of the workers and verify that the worker is running executors of both applications. To see which slot users are used, execute the following statement in each shell:

scala&gt; sc.makeRDD(1 to 3, 3).map(x =&gt; s"${org.apache.spark.SparkEnv.get.executorId} - ${sys.props("user.name")}").collect().foreach(println)

The command runs a simple transformation of a 3-element collection. Each partition will be processed as a separate task - if there are 3 executors with 1 core assigned, each element of the collection will be processed by a different executor. We will get the value of system property “user.name” from each executor JVM. You will notice that one shell will report different slot user for the same executor ID than the other shell which means that both executors are run by different OS user.

You may also have a look at the directories created for each application and executor:

$ sudo ls -lR /var/lib/spark/worker

Example output of this command:

<pre>
./app-20170424121437-0000:
total 4
drwxrwx--- 2 cassandra slot1 4096 Apr 24 12:14 0

./app-20170424121437-0000/0:
total 12
-rw-rw---- 1 cassandra slot1 &nbsp;&nbsp;&nbsp;&nbsp;0 Apr 24 12:14 stderr
-rw-rw---- 1 cassandra slot1 10241 Apr 24 12:16 stdout

./app-20170424121446-0001:
total 4
drwxrwx--- 2 cassandra slot2 4096 Apr 24 12:14 0

./app-20170424121446-0001/0:
total 8
-rw-rw---- 1 cassandra slot2 &nbsp;&nbsp;&nbsp;0 Apr 24 12:14 stderr
-rw-rw---- 1 cassandra slot2 7037 Apr 24 12:22 stdout
</pre>

Similarly, when you list&nbsp;/var/lib/spark/rdd&nbsp;you will see that directories used by different applications have different owners.

Refer to the&nbsp;<a href="http://docs.datastax.com/en/dse/5.1/dse-dev/datastax_enterprise/analytics/analyticsTOC.html">DSE Analytics documentation</a>&nbsp;to get more detailed information about DSE Resource Manager. Stay tuned for more posts related to DSE Resource Manager where we are going to cover running Spark applications high availability troubleshooting.

DSE 5.1 Resource Manager Part 2 – Process Security

Jacek Lewandowski

Share

More Technology

Why DataStax Loves LangChain

Getting Started with DataStax Astra DB and Amazon Bedrock

Why You Can't Miss Cassandra Summit

Mitigate the OpenAI Debacle with Open Source and Cloud

NoSQL and Vector DB
for Generative AI,
Instantly, At Scale

Jacek Lewandowski

Share

More Technology

Why DataStax Loves LangChain

Getting Started with DataStax Astra DB and Amazon Bedrock

Why You Can't Miss Cassandra Summit

Mitigate the OpenAI Debacle with Open Source and Cloud

NoSQL and Vector DBfor Generative AI,Instantly, At Scale

NoSQL and Vector DB
for Generative AI,
Instantly, At Scale