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
* ...
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}