Re: [HTCondor-users] How to configure secure settings as part of connecting additional EXECUTE user nodes

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

>> On 9 Dec 2019, at 21:18, don_vanchos <hozblok@xxxxxxxxx 
>> <mailto:hozblok@xxxxxxxxx>> wrote:
>>
>> Hello!
>>
>> I have a central Unix machine with MASTER, COLLECTOR, SCHEDD demons 
>> and several main EXECUTE nodes in a private network behind a firewall. 
>> Let's call this machine - machine A.
>> There are also users who have some kind of licensed software installed 
>> on their Windows machines (Machine B). I want to connect EXECUTE 
>> HTCondor nodes from their machines (B) to an existing pool on machine A.
>> My goal is to make sure that they can run their jobs. Some of their 
>> jobs will use their licensed software, so these jobs must be running 
>> on machines B.
>> There is one-way visibility between the machines: from B to A. So I 
>> decided to use the CCB mechanism.
>>
>> From a security point of view, the question is: How can I best 
>> organize authentication the EXECUTE node (from machine B) to join it 
>> to main pool? I want to completely avoid the situation where users can 
>> break or change the main pool or configuration on Machine A. Also, if 
>> there will be several computers B, I do not want B1 to spoil or change 
>> something with B2.
>> What is the best way to configure the htcondor A, B machines? Which 
>> authentication method to choose?

Hi,

If I am understanding you above, the key to your question is how can you add machines to your HTCondor pool and ensure that these machines can only *execute* jobs.  In other words, you do not want any jobs to be able to be submitted into your pool from machine B (or B1, etc), even if an administrator changes the configuration on machine B to start up a SCHEDD daemon.  This way, even people with login or physical access to machine B cannot submit an arbitrary executable to run on any other machine in your pool.

The trick to accomplish this is a change in the configuration of your central manager (specifically, the condor_collector) to allow or deny entry into the pool at the level of the STARTD (execute node) or SCHEDD (submit node), instead of just allow a machine to have either role. See
  https://htcondor.readthedocs.io/en/stable/admin-manual/security.html#host-based-security-in-htcondor

So your central manager config with just your A machines, before you have added the B machines probably has a line like:

  ALLOW_WRITE = machineA1.xxx.com, machineA2.xxx.com

Now instead of just adding the B machines to the ALLOW_WRITE line, we add the following:

  ALLOW_ADVERTISE_STARTD = machineB1.yyy.com, machineB2.yyy.com

(you can use IP addresses in place of machine names for additional security).

The ALLOW_WRITE entry tells the collector to accept ads from masters, startds, or schedds running on any of those hosts, but the ALLOW_ADVERTISE_SCHEDD permission is more specific - only startd ads will be allowed (and not schedd ads), meaning these machines can only execute jobs, not submit.

Of course, the above means you are not worried about a B machine spoofing the IP address of an A machine (which may be impossible to do depending upon how your network/router is configured...  ie your router is likely doing ingress filtering which is blocking of packets from outside the network from claiming a source address inside the network).  If you are worried about IP address spoofing, then you can look into HTCondor pool password or SSL security mechanisms, which work across Linux and Windows nodes, but if all you want to do is prevent your B machines from doing anything but running jobs submitted from A machines, maybe the above is all you need.

Hope the above helps,
Todd