23.11 Grid Credential Management

• Peer User Credential Management Overview
• Credential Mapping Files

23.11.1 Peer Credential Management Overview

Moab provides a number of credential management features that allow sites to control which local users can utilize remote resources and which remote users can utilize local resources and under what conditions this access is granted.

23.11.2 Peer Credential Mapping

If two peers share a common user space (a given user has the same login on both clusters), then there is often no need to enable credential mapping. When users, groups, classes, QoS's, and accounts are not the same from one peer to another, Moab allows a site to specify an Object Map URL. This URL contains simple one to one or expression based mapping for credentials and other objects. Using the RMCFG parameter's OMAP attribute, a site can tell Moab where to find these mappings. The object map uses the following format:

<OBJECTTYPE>:<SOURCE_OBJECTID>,<DESTINATION_OBJECTID>

where <SOURCE_OBJECT> can be a particular username or an asterisk (*) which is a wildcard matching all credentials of the specified type which have not already been matched.

The object map file can be used to translate the following:

The following moab.cfg and omap.dat files demonstrate a sample credential mapping.

SCHEDCFG[master1] MODE=normal
RMCFG[slave1]     OMAP=file:///opt/moab/omap.dat
...

user:joe,jsmith
user:steve,sjohnson
group:test,staff
class:batch,serial
user:*,grid

In this example, a job that is being migrated from cluster master1 to the peer slave1 will have its credentials mapped according to the contents of the omap.dat file. In this case, a job submitted by user joe on master1 will be executed under the user account jsmith on peer slave1. Any credential that is not found in the mapping file will be passed to the peer as submitted. In the case of the user credential, all users other than joe and steve will be remapped to the user grid due to the wildcard matching.

Because the OMAP attribute is specified as a URL, multiple methods can be used to obtain the mapping information. In addition to the file protocol shown in the example above, exec may be used.

Note that there is no need to use the credential mapping facility to map all credentials. In some cases, a common user space exists but it is used to map all classes/queues on the source side to a single queue on the destination side. Likewise, for utilization tracking purposes, it may be desirable to map all source account credentials to a single cluster-wide account.

23.11.3 Source and Destination Side Credential Mapping

Credential mapping can be implemented on the source cluster, destination cluster, or both. A source cluster may want to map all user names for all outgoing jobs to the name generaluser for security purposes, and a destination cluster may want to remap all incoming jobs from this particular user to the username cluster2 and the QoS grid.

23.11.4 Preventing User Space Collisions

In some cases, a cluster may receive jobs from two independent clusters where grid wide username distinctiveness is not guaranteed. In this case, credential mapping can be used to ensure the uniqueness of each name. With credential mapping files, this can be accomplished using the <DESTINATION_CREDENTIAL> wildcard asterisk (*) character. If specified, this character will be replaced with the exact <SOURCE_CREDENTIAL> when generating the destination credential string. For example, consider the following configuration:

SCHEDCFG[master1] MODE=normal
RMCFG[slave1]     OMAP=file:///opt/moab/omap.dat  FLAGS=client
...

user:*,c1_*
group:*,*_grid
account:*,temp_*

This configuration will remap the usernames of all jobs coming in from the peer slave1. The username john will be remapped to c1_john, the group staff will be remapped to staff_grid and the account demo will be remapped to temp_demo.

© 2016 Adaptive Computing