[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Token based authentication and draining worker nodes
- Date: Wed, 17 Mar 2021 12:03:06 -0500 (CDT)
- From: Todd L Miller <tlmiller@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Token based authentication and draining worker nodes
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? 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.