Sensys considers several security aspects in its design. However, user needs to be aware of the following items that are out of scope:

• As Sensys requires administrative permissions in most of the features, the protection of threats from privileged users is out of the scope. Therefore, it is recommended to enable mechanisms for logging and monitoring the operation of Sensys.
• The out-of-band communication protocols used by Sensys, like IPMI or SNMP, can be considered insecure and should be isolated from the user-accessible hosts. Consequently, system's administrators must ensure the network is properly configured to mitigate potential security issues.

Munge is a service library for creating and validating credentials, allowing a process to authenticate the UID and GID of a another local or remote process within a group of hosts. Sensys provides an authentication mechanism making use of the munge service, this method is recommended to be used while running Sensys daemons and tools among the different hosts in an HPC cluster enviroment. Munge library is covered by LGPL, more information about it can be found here: http://dun.github.io/munge/

The following configurations should be performed to use munge.

1. The recommended version of installation is version 0.5.1:
   https://github.com/dun/munge/releases/tag/munge-0.5.11
2. The munge.key should be created as per the steps mentioned in "Installation Guide":
   https://github.com/dun/munge/wiki/Installation-Guide
3. Munge key should be distributed on every node which requires authentication and runs the Sensys daemons and tools: orcmd, orcmsched and octl tool.
4. For the authenticantion, munge internally performs the embedded encode time check against the current time, make sure the time is synchronized on all nodes running munge.
5. The system admin will create a group manually in /etc/group and add all the users recommend to run the Sensys daemons (on the compute node) to this group.
6. For security purposes make sure to refresh the munge keys periodically to ensure the credential has not been altered.
7. The orcmd should be started with the following mca-parameter to enable authentication:
   --omca sec munge
8. The orcmd and orcmsched should be started with another mca-parameter for authorization:
   --omca sec sec_munge_authorize_group=<name_of_authorized_group>

In this example, the goal is to run orcmd as user "admin" and authorize remote users with a group called "sensysusers".

1. Create the munge key file

% dd if=/dev/urandom bs=1 count=1024 >/etc/munge/munge.key

2. Distribute the munge.key, ie. you could make use of warefulf to sync the file:

% wwsh file sync munge.key

3. Start/restart the munged service

% service munged start

4. Make sure that munged is running on the local machine.

% ps aux | grep munged

5. Make sure that time is synchronized on all the nodes that are using munge.

% pdsh <host names> ntpdate <server>

6. Create a group called "sensysusers".

% groupadd sensysusers

7. Add users to the group by using one of the below commands.
   
   The following command add existing user "admin" to existing group "sensysusers":

% usermod -a -G sensysusers admin

Or the next command creates new user "admin" and add to group "sensysusers":

% useradd -G sensysusers admin

8. Start orcmsched with command:

% orcmdsched --omca sec_munge_authorize_group=sensysusers

9. Start orcmd with command:

% orcmd --omca sec munge --omca sec_munge_authorize_group=sensysusers

Once this daemon starts running with this configuration, it will accept connections only from remote connections which have munge enabled in the similar way, and use the exact same munge.key, and running as a user who belongs to the user group "sesnsysusers" to establish a successful connection. Thus the authentication and authorization are achieved. Similar to orcmd, orcmsched daemon can be started with munge enabled, and octl can be started with same parameters to use munge authentication to connection to orcmsched.