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

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.

- ToddM