Re: [HTCondor-users] Token based authentication and draining worker nodes

[Caspart, Renà (SCC) <rene.caspart@xxxxxxx>]

Hi Brian, Todd,

thanks a lot for your replies and clarifications. Indeed I must admit
the security concern is probably a bit exaggerated, but it boils down to
us wanting to limit the distribution of a cluster-wide valid (and
unique) password as much as possible.

Based on you replies we will try to go for having a dedicated signing
key for each case/off site location and corresponding tokens on our
central manager to allow interaction with the startds there.
Of course we are looking forward to any new feature which improves
handling of such cases in the future.

Thanks,
Rene

Am 17.03.21 um 19:01 schrieb Bockelman, Brian:
>
>> On Mar 17, 2021, at 12:03 PM, Todd L Miller <tlmiller@xxxxxxxxxxx> wrote:
>>
>>> Now I am a bit lost, since our original assumption was that we do not
>>> need to distribute a (common) password to the worker nodes (which could
>>> then be used to create a token for authenticating with the worker nodes).
>> 	I'm a bit confused about the threat model here.  For your own (on-site) machines, you could ensure that the password file would be owned by root and unreadable by anyone else.  If your off-site worker nodes aren't glide-ins, that would indicate that you don't trust the off-site admins.  (If your off-site worker nodes _are_ glide-ins, I have to admit that there's currently nothing you can do, but I wouldn't expect you to want to drain a glide-in in the first place.)  That's fine, but then it seems like the bigger threat would be creating a token that could authenticate against your own nodes -- the off-site admin already has control of their own machines.
>>
>>> Are we missing something obvious here?
> No, the subtlety is not obvious at all!  For the record:
>
> - Any command you send to the startd requires the startd to act as a "server" in a client-server relationship.
> - A token can _only_ be used by clients, not by servers.
> - Therefore, if the startd only has a token, it cannot be a remote server and commands like (remote) condor_drain or condor_on/off don't function.
>
> This is a known deficiency and something we'd like to work on in the next series.  We had a prototype for condor_fetch_log working but need to make it more broadly applicable (for your use case, for example!).
>
>>> Is there any recommended way how
>>> to achieve what we intend?
>> 	In general, as you've noticed, IDTOKENS aren't quite ready to be the only authentication method in a pool.  (They work really well if all you want to do is run jobs on other people's machines though, whether that's through flocking or glide-ins.)
>>
>> 	However, one of the nice things about IDTOKENS is that you can have more than one password (signing key).  In particular, you could create a different signing key (and token) for as many different groups as you'd like: one for your own execute nodes and one for different each off-site administrator, for example.  As long as you don't add those signing keys to your own collector, it will reject tokens created using them, so they're safe to hand out from that point of view.
>>
> To elaborate - because the collector doesn't accept the "offsite" signing key, tokens generated by the offsite signing key cannot be used to advertise schedds or startds, reducing the overall privilege sent to the offsite hosts.
>
> HTH,
>
> Brian
> _______________________________________________
> 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/

-- 
Karlsruher Institut fÃr Technologie (KIT)
Steinbuch Centre for Computing (SCC)

Dr. Renà Caspart

Hermann-von-Helmholtz-Platz 1 
76344 Eggenstein-Leopoldshafen, Germany
Telefon: +49 721 608-25631
E-mail: Rene.Caspart@xxxxxxx


Sitz der KÃrperschaft:
KaiserstraÃe 12, 76131 Karlsruhe



KIT â Die ForschungsuniversitÃt in der Helmholtz-Gemeinschaft

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