...

This setup needs 2 user accounts on the agent Agent host:

• User account A
  • has access to the TLS certificate and the TLS key
  • has access to the reverse proxy configuration files
  • executes the reverse proxy server, which is configured to
    
    • allow connections by HTTPS (using the TLS certificate and key)
    • allow connections only from certain IPsIP addresses
    • proxy these connections to JobScheduler Agent on localhost
• User account B
  • does not have access to the TLS key
  • does not have access to the reverse proxy configuration files
  • executes the JobScheduler Agent which is parameterized to
    • only allow connections on the local network interface

...

• JobScheduler Master requests a job start on the Agent
  • the request goes through https HTTPS to the reverse proxy
  • the reverse proxy forwards the request by http HTTP to JobScheduler Agent on the same machine
  • the JobScheduler Agent starts an agent task
• The agent tasks communicates with JobScheduler Master (logging, api calls...)
  • the agent task connects by TCP to the JobScheduler Agent
  • JobScheduler Agent tunnels all communication from the agent task to JobScheduler Master through the existing HTTP connection to the reverse proxy continuing in the HTTPS connection to JobScheduler Master

...

• Separation of confidential credentials from JobScheduler Agent
  • Whoever is able to run jobs JobScheduler Agent is able to
    • access all files that can be accessed by the user running JobScheduler Agent
    • execute all processes that can be executed by the user running JobScheduler Agent
    • do whatever the user running JobScheduler Agent could do on the shell
  • If the user running JobScheduler Agent was were the same user that runs the reverse proxy (or if the proxy was integrated into JobScheduler Agent), he could
    • steal the TLS key
    • reconfigure the reverse proxy to accept connections from other hosts
• The JobScheduler Universal Agent aims at a zero-configuration approach
  • Setting up TLS encryption needs a lot of configuration (certificates, keys, protocol options)
  • Experienced adminstrators know how to configure this in the reverse proxy of their choice (but would have to learn how to do this if it were configured in JobScheduler Agent)
• Use existing trusted functionality
  • TLS configuration and handling
  • Authentication: simple authentication can be achieved by restricting reverse proxy access to certain hosts
  • Authorisation: reverse proxy servers can be configured to allow
    
    • GET and POST requests for some hosts → execution of jobs possible
    • only GET request for other hosts → read-only access (status information...)

...

• attackers eavesdropping on the network
• attackers using JobScheduler Agent to steal the TLS key
• attackers using JobScheduler Agent to reconfigure the authentication in the reverse proxy
• attackers spoofing the identity of the Agent host
• attackers trying to control the Agent from other IPsIP addresses

This setup does not secure the Agent against:

• attackers spoofing the IP address of the JobScheduler Master

...

• JobScheduler Master is configured with a client HTTPs HTTPS certificate
• The reverse proxy is configured to only accept connections from certain hosts which can authenticate with a valid client certificate

...

Notes

• Communication between JobScheduler Master and Agent is initiated by the Master only and is restricted to the port that is specified for the HTTPS connection.
• Communication between JobScheduler Master instances for remote execution make use of a number of ports in both directions, see How to configure remote execution.