[HTCondor-users] Lost in IDTOKENS

[Carsten Aulbert <carsten.aulbert@xxxxxxxxxx>]

Hi all,

finally, we are about to move past v8.8 and with going to the 10.7 
series on Debian bookworm. During this transition, I would like to get 
away from the current FS/HOST based security model, especially as the 
latter is very much frowned upon, but at the moment I'm struggling to 
get around IDTOKENS and how to pre-create those for users and how to 
distribute this centrally by a host-based configuration management tool.
My goal is to give every user access to our three local pools, enable 
flocking between them and have condor daemons talking easily between 
each other as necessary, just like they can at the moment. All relevant 
nodes have access to the same shared storage system which consists of 
dozens of different networked file systems, e.g. NFS and BeeGFS with 
Ceph to be added soon.
Currently, I don't see a problem to create a central auth token with the 
pool password and distribute this to every single central 
manager/schedd/execute node. I'm not yet sure, whether to have a 
different central auth token for every pool but even then, distributing 
one or three central secrets is not a big headache - Iâ think.
However, at the moment after reading the manual, I don't know how to 
enroll local users into this scheme.
My goal here is that users won't even notice any regression in migrating 
to a different security model, they continue to ssh into the schedd 
machines and can condor_submit/condor_q/condor_rm all they want 
(especially also condor_q -better-analyze which needs direct read access 
to a remote collector).
What I don't want is that users need to start to request tokens which we 
as admins have to manually approve of.
Sure, we could probably write a script which does all this for us, 
generate/approve a token and somehow copies this to the user's 
~/.condor/tokens.d but at the moment I don't really see how Iâ would be 
able to automate this easily[1].
Is there an easy mechanism within HTCondor itself to auto-approve 
locally generated requests (e.g. triggered by the user's ~/.profile or 
first use of a condor command?). From the man page of 
condor_token_request_auto_approve this does not seem to be the tool of 
choice.
Final side note (for now), how would one prohibit a user from generating 
a request for another user's identity? So far, I drew blanks from the 
manual on that.
As always, thanks a lot for some pointers, at the moment I'm completely 
lost between large bits of documentation and lack of documentation which 
could be applied to our set-up.
Cheers

Carsten

PS:â If relevant, I don't expect external submissions from outside our 
internal networking structure.
[1] Initial problems I see with trying our host based configuration 
management to tackle this includes
* central managers usually don't have knowledge of our Unix users
* schedd hosts know about the Unix users but write access to these 
users' home directories could prove finicky due to NFS and friends
* file servers with local access to the users' files have no local 
condor installation
*â trying to automagically create the proper tokens on the fly does add 
extra node inter-dependencies which Iâusually try to omit adding
* ...

--
Dr. Carsten Aulbert, Max Planck Institute for Gravitational Physics,
CallinstraÃe 38, 30167 Hannover, Germany, Phone +49 511 762 17185

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature