Authorization, Mapping and Queue selection rules
Overview
ARC CE authorization and mapping rules rely on the concept of authgroups (configured by [authgroup] blocks).
Fig. 2 General overview of authorization and mapping concepts in ARC6
During the connection establishment and authentication process on any of the ARC CE interfaces (e.g. job submission on the figure), the Authgroup matching happened. Each authgroup represents a set of users, whose identities are matched to configured rules. The same user can match (belongs to) several authgroups.
If configured by allowaccess and denyaccess options, per-interface authorization rules will be enforced.
This rules defines the list of authgoups that granted or denied access to the particular ARC CE interface.
Without per-interface authorization rules, configuration access to the interface is granted to anyone who passed authentication process.
Warning
User will be successfully authenticated only in case of certificate and proxy-certificate has been passed validation.
In case of time syncronization problems, missing or invalid CA certificates and CRLs, missing VOMS LSC files, etc - the connection WILL NOT be established.
Mapping rules in ARC6 also relies on authgroup membership. Configured mapping rules are processed sequentially and define the OS account ID that will be assigned to authgroup members. Several mapping methods are available, depending on requirements.
Notice that in ARC6 authorization rules can also be enforced per-queue. It uses the same allowaccess and denyaccess options syntax
as for per-interface configuration but can additionally restrict access to the particular queue.
By default access to the queue granted to all users authorized on interface level.
Defining authgroups
Authgroups should be defined on the top of arc.conf using the [authgroup:groupname] block before it will be referenced in the other parts of configuration.
Each authgroup is a named object, that will be referenced by its name during authorization and mapping rules configuration.
There are no special restrictions to the authgroup names except the absence of spaces, so you can even define * authgroup to blow the mind of other arc.conf readers.
Each config line in the [authgroup:groupname] block represent a matching rule that are processed sequentially.
When the matchig criteria of the rule has been satisfied by user identity - the processing stops within this authgroup.
Whether user belogns to this authgroup or not is defined by the type of rule that was matched:
there are positively and negatively matching rules.
By default all rules are positive (user IS a member of authgroup when matched) unless prefixed with - sign.
Matching one of the authgroups does not mean that the same user is not processed for the next authgroup. All authgroups are evaluated, even if a user already has a match with one of the earlier processed authgroups.
Note
Notice that:
authgroup blocks should be defined before referencing!
authgroup rules within blocks are order-dependent!
all authgroup blocks are evaluated!
Complete list of authgroup rules can be found in the ARC Configuration Reference document. Some examples are:
[authgroup: norduguest]
-file = /etc/grid-security/banned.dns
voms = nordugrid Guests * *
[authgroup: admin]
subject = /O=Grid/O=Big VO/CN=Main Admin
[authgroup: lcas]
plugin = 10 /usr/libexec/arc/arc-lcas %D %P liblcas.so /usr/lib64 /etc/lcas/lcas.db
[authgroup: any]
authgroup = norduguest
authgroup = admin
authgroup = lcas
[authgroup: *]
all = yes
Configure mapping
Any grid user should be mapped to a local account to start processes and access files.
Mapping rules configured in [mapping] block define which grid-users (specified by authgroup) are mapped to which system accounts (several mapping methods available).
Rules in the [mapping] block are processed in a sequence in line order of the configuration file (from top to bottom).
There are two kind of rules avaiable:
mapping rules (started with
map_) that defines how the particular authgroup members are mapped,policy rules (started with
policy_) that modifies the mapping rules sequence processing.
Default policy for mapping rules processing is:
processing CONTINUES to the next rule if identity of user DO NOT match authgroup specified in the rule (can be redefined with policy_on_nogroup option)
processing STOPS if identity of user matched the authgroup specified in the mapping rule. Depend on whether this mapping rule returns valid UNIX identity the processing can be redefined with policy_on_map and policy_on_nomap options.
Policy can be redefined at the any point of configuration sequence and affects all mapping rules defined after the polcy rule.
Warning
If mapping process STOPS and there is still no local UNIX identity identified, the user running A-REX will be used (typically root unless redefined by user option for specific deployment case).
When grid-identity is mapped to root account - request processing fails implicitely!
Example: mapping to the same account
The map_to_user option allows to map all authgroup members to the same account specified as an argument.
For example in shipped zero configuration all users that are matched to authgroup zero are mapped to the same nobody account (and nobody group) that will work with local job forking:
[mapping]
map_to_user = zero nobody:nobody
Example: mapping to the accounts pool
The most secure and flexible way is to map authgroup members to account pools (so-called map_to_pool method). It is recommended to use pools mapping when the resource is under the use of different communities.
In this approach, every member of specified authgroup will be dynamically mapped to one of the available accounts in the configured pool.
Available pool account names are stored one per line in the pool file inside the dedicated directory.
Accounts from pool are assigned by means of leasing approach.
All leased accounts are stored in the other files placed in the same directory.
They can be reassigned to other users after 10 days of inactivity.
Example configuration for atlas:
Create necessary number of accounts to be used on ARC CE and Worked Nodes of the cluster.
Define ARC accounts pool:
[root ~]# mkdir -p /etc/grid-security/pool/atlas [root ~]# for u in atlas{001..100}; do echo $u >> /etc/grid-security/pool/atlas/pool; done
Configure mapping in
arc.conf[2]:[mapping] map_to_pool = atlas /etc/grid-security/pool/atlas
Example: Legacy grid-mapfile based mapping
Warning
Legacy grid-mapfile based mapping is NOT recommended for the typical production loads.
In the grid-mapfile approach users are mapped to local accounts based on certificate DNs only. Mapping rules are stored line-by-line in the so-called grid-mapfile that describes which user is mapped to which account, for example:
"/O=Grid/O=NorduGrid/OU=uio.no/CN=Aleksandr Konstantinov" user1
"/O=Grid/O=NorduGrid/OU=hep.lu.se/CN=Oxana Smirnova" user2
In the simplest legacy case ARC can use the grid-mapfile for both authorization and mapping decisions.
Example configuration for legacy grid-mapfile case:
[authgroup: legacy]
file = /etc/grid-security/grid-mapfile
[mapping]
map_with_file = legacy /etc/grid-security/grid-mapfile
Grid-mapfiles in arc.conf can be also referred as a [userlist] objects and be generated regularly, keeping them up-to-date (from e.g. VOMS database) with nordugridmap utility that can be used and configured with the [nordugridmap] block
Note
You can find more information about moving from grid-mapfiles in the The life without gridmapfiles presentation.
Example: mapping with external LCMAPS rules
ARC can run an external plugin to map users that can be configured with the map_with_plugin option.
To support several production loads, ARC ships with the built-in LCMAPS plugin included in A-REX package:
[authgroup:all]
all = yes
[mapping]
map_with_plugin = all 30 /usr/libexec/arc/arc-lcmaps %D %P liblcmaps.so /usr/lib64 /etc/lcmaps/lcmaps-arc-argus.db arc
LCMAPS itself is a third-party tool that should be installed and configured separately, which is beyound the scope of this guide.
Queue selection rules and queue configuration
Note
Behaviour new in ARC 6.11
Once a submitter is authorized to submit to one of the submission interfaces defined in arc.conf, the next step for ARC is to select a queue and check authorisation at queue-level.
The logic is as follows
if (queue defined in job description xrsl)
submit to that queue w/o modification if authorised in the queue block
elseif (no queue defined in job description xrsl but a default queue is defined in arc.conf)
substitute the default queue into xrsl if authorised in the queue block
elseif (no queue in defined in job description xrsl and no default queue is defined in arc.conf and the VO is authorised in one of the arc.conf queues*)
substitute into xrsl the first of the queues where the VO is authorised according to arc.conf
else
reject
* any VO is authorised in a queue that has no authorisation defined at all.
Note that this means that you must ensure that the authgroups you wish to allow submission from, are authorized in the queue you intend the authgroup to submit to. An example of an arc.conf setup that previously could result in the LRMS selecting the queue, but where submission today will be rejected could be the following:
[authgroup:exp1]
...
[authgroup:exp2]
...
[mapping]
..
[queue:queue1]
allowaccess= exp1
[queue:queue2]
allowacces= exp1
Let’s look at the exp2 authgroup. According to this arc.conf we assume the authorisation and mapping is ok.
Old behaviour: If there is no queue information in the xrls, the old behaviour would be to pass the job to the LRMS directly and let LRMS select the queue. This means that any queue in the system, even a queue not defined in arc.conf could be selected, e.g. a queue3 defined by the LRMS, but not in arc.conf.
New behaviour: From ARC version 6.11 only queue1 and queue2 will be possible queues for exp2 (and any authgroups), as they are the ones defined in arc.conf. Therefore in the example, none of the queues are allowed for exp2 and the job will be rejected.
A possible rewrite of this arc.conf example-snippet, to allow exp2 to submit to queue2 could be:
[queue:queue1]
allowaccess= exp1
[queue:queue2]
<empty>
This is an example of rule 3: No queue is defined in the job description xrsl and no default queue is defined in arc.conf and the VO is authorised in (at least) one of the arc.conf queues. In this example all VO’s are authorised for using queue2.