18.4 Identity Managers
The Moab identity manager interface can be used to coordinate
global and local information regarding users, groups, accounts, and
classes associated with compute resources. The identity manager
interface may also be used to allow Moab to automatically and
dynamically create and modify user accounts and credential
attributes according to current workload needs.
Only one identity manager can be configured at a time.
18.4.1 Identity Manager
Overview
Moab allows sites extensive flexibility when it comes to
defining credential access, attributes, and relationships. In most
cases, use of the USERCFG,
GROUPCFG, ACCOUNTCFG, CLASSCFG, and QOSCFG parameters is adequate to
specify the needed configuration. However, in certain cases such as
the following, this approach may not be ideal or even adequate:
- Environments with very large user sets
- Environments with very dynamic credential configurations in
terms of fairshare targets, priorities, service access constraints,
and credential relationships
- Grid environments with external credential mapping information
services
- Enterprise environments with fairness policies based on
multi-cluster usage
Moab addresses these and similar issues through the use of an
identity manager. An identity manager is configured with the
IDCFG parameter and allows
Moab to exchange information with an external identity management
service. As with Moab resource manager interfaces, this service can
be a full commercial package designed for this purpose, or
something far simpler such as a web service, text file, or database.
18.4.2 Basic
Configuration
Configuring an identity manager in basic read-only mode can be
accomplished by simply setting the SERVER attribute. If Moab
is to interact with the identity manager in read/write mode, some
additional configuration may be required.
BLOCKCREDLIST |
Format |
One or more comma-delimited object types
from the following list: acct, group, or
user |
Details |
If specified, Moab will block
all jobs associated with credentials not explicitly reported in the
most recent identity manager update. If the credential appears on
subsequent updates, resource access will be immediately restored.
Jobs will only be blocked if fairshare is enabled. This can be
accomplished by setting the FSPOLICY parameter to any value
such as in the following example:
|
Example |
IDCFG[test01] BLOCKCREDLIST=acct,user,groups
Moab will block any jobs associated with accounts, users, or groups not in the most recent identity manager update.
|
CREATECRED |
Format |
<BOOLEAN> (default is FALSE) |
Details |
Specifies whether Moab should create credentials reported by the identity manager that have not yet been locally discovered or loaded via the resource manager. By default, Moab will only load information for credentials which have been discovered outside of the identity manager. |
Example |
IDCFG[test01] CREATECRED=TRUE
Moab will create credentials from test01 that have not been previously loaded.
|
REFRESHPERIOD |
Format |
[[[DD:]HH:]MM:]SS or INFINITY (default is
infinity)
Note: The former values of MINUTE, HOUR, DAY or NONE are deprecated and may be removed in a future release.
|
Details |
Moab will refresh the identity manager information on the specified period relative to the scheduler start time. If INFINITY is specified, the information is updated only at Moab start up. |
Example |
IDCFG[test01] REFRESHPERIOD=4:00:00
Moab queries the identity manager every four hours.
|
REQUIREDUSERLIST |
Format |
One or more comma-delimited object types
from the user list. |
Details |
Lets you dynamically set the user list with a class for jobs.
Removing a user from the REQUIREDUSERLIST will not affect the user's running jobs. However, the user's idle jobs will become blocked because the user no longer has access to the class requested.
|
Example |
IDCFG[test01] CLASS:<name> REQUIREDUSERLIST=<user>
|
RESETCREDLIST |
Format |
One or more comma-delimited object types
from the following list: acct, group, or
user. |
Details |
If specified, Moab will reset
the account access list and fairshare cap and target for all
credentials of the specified type(s) regardless of whether they are
included in the current info manager report. Moab will then load
information for the specified credentials. |
Example |
IDCFG[test01] RESETCREDLIST=group
Moab will reset the account access list and fairshare target for all groups.
|
SERVER |
Format |
<URL> |
Details |
Specifies the
protocol/interface to use to contact the identity manager. |
Example |
IDCFG[test01] SERVER=exec://$HOME/example.pl
Moab will use example.pl to communicate with the identity manager.
|
UPDATEREFRESHONFAILURE
|
Format |
<BOOLEAN> (default is
FALSE) |
Details |
When an IDCFG script fails, it
retries almost immediately and continuously until it succeeds. When
UPDATEREFRESHONFAILURE is set to TRUE, a failed script does not
attempt to rerun immediately, but instead follows the specified
REFRESHPERIOD schedule. When set to TRUE, UPDATEREFRESHONFAILURE
updates the script execution timestamp, even if the script does not
end successfully. |
Example |
IDCFG[info] SERVER=exec:///home/tshaw/test/1447/bad_script.pl REFRESHPERIOD=hour UPDATEREFRESHONFAILURE=TRUE
|
18.4.3 Importing Credential Fairness Policies
One common use for an identity manager is to import fairness
data from a global external information service. As an example,
assume a site needed to coordinate Moab group level fairshare
targets with an allocation database that constrains total
allocations available to any given group. To enable this, a
configuration like the following might be used:
IDCFG[alloc] SERVER=exec://$TOOLSDIR/idquery.pl
...
The tools/idquery.pl script could be set up to query a
local database and report its results to Moab. Each iteration, Moab
will then import this information, adjust its internal
configuration, and immediately respect the new fairness
policies.
18.4.4 Identity
Manager Data Format
When an identity manager outputs credential information either
through an exec or file based interface, the data
should be organized in the following format:
<CREDTYPE>:<CREDID> <ATTR>=<VALUE>
where
- <CREDTYPE> is one of user, group,
account, class, or qos.
- <CREDID> is the name of the credential.
- <ATTR> is one of adminlevel, alist,
chargerate, comment, emailaddress,
fstarget, globalfstarget, globalfsusage, maxjob, maxmem, maxnode, maxpe, maxproc, maxps, maxwc, MAX.WCLIMIT, plist, priority, qlist, or role. Multi-dimensional policies work here as well.
- <VALUE> is the value for the specified attribute.
To clear a comment, set its value to ""; for
example: comment="".
Example 18-3:
The following output may be generated by an exec based
identity manager:
group:financial fstarget=16.3 alist=project2
group:marketing fstarget=2.5
group:engineering fstarget=36.7
group:dm fstarget=42.5
user:jason adminlevel=3
account:sales maxnode=128 maxjob=8,16
The following example limits user bob to 8 matlab generic resources.
user:bob MAXGRES[matlab]=8
To specify unlimited use of generic resources, set the value to -1.
18.4.5 Identity Manager
Conflicts
When local credential configuration (as specified via
moab.cfg) conflicts with identity manager configuration,
the identity manager value takes precedence and the local values
are overwritten.
18.4.6 Refreshing Identity
Manager Data
By default, Moab only loads identity manager information once
when it is first started up. If the identity manager data is
dynamic, then you may want Moab to periodically update its
information. To do this, set the REFRESHPERIOD attribute of
the IDCFG parameter. Legal values are documented in the
following table:
Value |
Description |
minute |
Update identity information once per
minute |
hour |
Update identity information once per
hour |
day |
Update identity information once per
day |
infinity |
Update identity information only at
start-up (default) |
Example 18-4:
IDCFG[hq] SERVER=exec://$TOOLSDIR/updatepolicy.sh REFRESHPERIOD=hour
Job credential feasibility is evaluated at
job submission and start time.
Related Topics
Credential Overview
Usage
Limits/Throttling Policies