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

[Todd L Miller <tlmiller@xxxxxxxxxxx>]

> 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