[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] using LDAP groups for authorization and accounting/allocations



On 9/11/2019 10:18 AM, Rundall, Jacob D wrote:
> (A) We're interested in allowing/denying submission of jobs based on the 
> submitter/owner's membership in various LDAP groups.
> 
> (B) We are also interested in tracking usage and (when necessary) 
> limiting usage according to user- and group-based allocations. The 
> allocations would exist in some kind of external source, most likely a 
> database. And access to both user- and group-based allocations should 
> correspond with LDAP user identity and group membership, respectively. 
> Users may need access to multiple group-based allocations.
> 
> I have several questions:
> 
> What approaches are there for goal in (A)? My understanding is that 
> authorization in HTCondor (e.g., ALLOW_WRITE/DENY_WRITE) is based on 
> users and machines, not groups (other than netgroups). We will likely 
> have several thousand users, so manually maintaining user-based 
> configurations will not be practical. We could script the config, but is 
> making HTCondor keep track of thousands of users in the ALLOW_WRITE 
> macro a good idea? 

I don't think HTCondor would particularly care if ALLOW_WRITE had a few 
thousand entries, but I think using the AssignAccountingGroup feature 
discussed below is a better idea.  Especially because you ultimately 
want to map each user into a set of groups anyway.  More below...

> 
> The use of accounting groups seems like the most common approach to 
> goals similar to (B) and may assist in (A) as well. In particular, the 
> AssignAccountingGroup configuration template seems like a useful tool 
> (ref1 
> <https://www-auth.cs.wisc.edu/lists/htcondor-users/2019-July/msg00110.shtml>, 
> ref2 
> <https://research.cs.wisc.edu/htcondor/HTCondorWeek2017/presentations/TueKnoeller_Schedd.pdf>; 
> we could maintain a mapfile via scripting against LDAP). 

Yes, I think you are on the right track by using the 
AssignAccountingGroup feature to solve both (A) and (B).  This would 
allow HTCondor to use a standalone "map" file which is just an ascii 
file that has one user per line, where each line has the login name of 
the user plus their allowed groups.  condor_submit will fail with a 
descriptive error message if the user does not exist in the file, or if 
a user attempts to specify a group where they are not a member.  This 
map file is read into memory by the schedd as a hash table, so lookups 
are fast/efficient.  You could have a script that updates this file 
regularly against LDAP or any other source; the condor_schedd will 
re-read this file on-the-fly upon a condor_reconfig (or a SIGHUP 
signal), so everything keeps on running.

Another alternative for (A) is to configure your central manager 
(condor_collector) to allow job submission into your pool to only happen 
from specific hosts (by setting the ADVERTISE_SCHEDD knob), and then 
control login access to those hosts however you see fit.

> If the user has 
> access to multiple allocations (e.g., user-based allocation and multiple 
> group-based allocations), does this configuration allow them to choose 
> their AccountingGroup and then validate their response? 

Yes.  If your map file has a line that says

    * bob math,physics

Then user "bob" can pick with every job submission which group to use 
for accounting/quota purposes by putting "accounting_group=math" or 
"accounting_group=physics" in his job submit file.  If he tries to 
specify a group other than math or physics, the submit will fail.

> Or does it 
> simply assign a single AccountingGroup per user?
> 

If the user does not specify any accounting_group in the submit file, 
the AssignAccountingGroup metaknob uses the first group listed in your 
map file for that user as the default.  So in the example above, if user 
bob did not specify accounting_group, it would end up in the math group.

Hope the above helps
Todd