[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 18:01:20 +0000
- From: "Bockelman, Brian" <BBockelman@xxxxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Token based authentication and draining worker nodes
> 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.