• Peer User Credential Management Overview
• Credential Mapping Files
• Constraining Access via Default and Mandatory Queues and QoS

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.

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 the special character '*' (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.

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.

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.

Constraining Access via Default and Mandatory Queues and QoS

While credential mapping allows a source side peer to translate one credential to another, a destination side peer may require control over this mapping as a prerequisite to participating in the peer relationship. For example, a given cluster may select to join a peer grid only if they can map all remote jobs into a specific class and apply limits constraining when and where this class is able to run.

In Moab, destination-side credential constraints are enabled using the RMCFG parameter's SET.JOB, MIN.JOB, MAX.JOB, and DEFAULT.JOB attributes.

Set Job Attribute

If the resource manager's SET.JOB attribute is set, each credential attribute specified within the remap job template will be used to overwrite values specified by the peer service. This is done regardless of whether the source job attributes are set. For example, in the following configuration, the job's account and class credentials will be remapped regardless of original values:

# define connection to remote peer cluster 'clusterB'
RMCFG[clusterB.INBOUND] TYPE=moab SET.JOB=set1
# force jobs coming in from clusterB interface to use account 'peer' and class 'remote'
JOBCFG[set1] ACCOUNT=peer CLASS=remote
...

Minimum and Maximum Job Constraints

The MIN.JOB and MAX.JOB attributes can be used to link a particular job template to a resource manager interface. If set, jobs that do not meet these criteria will be rejected.

Default Job Settings

If the resource manager's DEFAULT.JOB attribute is set, each credential attribute specified within the default job template will be used to set job attribute values that are not explicitly set by the peer service. For example, in the following configuration, the job's account and class credentials will be remapped if no original values are specified:

JOBCFG[default-hq.INBOUND] TYPE=TEMPLATE ACCOUNT=peer CLASS=remote
RMCFG[hq] DEFAULT.JOB=default-hq
...