Deprecation
For secure HTTPS communication use of a proxy is not required as HTTPS is directly available with Master and Agents, see JobScheduler Universal Agent - HTTPS Agent and Master Authentication
Architecture
Communication to and from the Universal Agent can be secured by HTTPS using a 3rd party reverse proxy (e.g. Apache HTTP Server, nginx).
Feature Availability
- JS-1467Getting issue details... STATUS
- JOE-164Getting issue details... STATUS
Explanations
This setup requires 2 user accounts on the 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 IP 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
All communication between the JobScheduler Master and the Agent goes through an HTTPS connection
- JobScheduler Master requests a job start on the Agent
- the request goes through HTTPS to the reverse proxy
- the reverse proxy forwards the request by 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
Motivation for using a 3rd party reverse proxy
- 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 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
- Whoever is able to run jobs JobScheduler Agent is able to
- The JobScheduler Universal Agent aims at a zero-configuration approach
- Setting up TLS encryption needs a lot of configuration (certificates, keys, protocol options)
- Experienced administrators 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
- Authorization: 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...)
Security
This setup secures the Agent against:
- 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 IP addresses
This setup does not secure the Agent against:
- attackers spoofing the IP address of the JobScheduler Master
Possible Enhancements
Validating the client identity using HTTPS client authentication
- JobScheduler Master is configured with a client 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.
References
Change Management References
See also
- For instructions on how to set up this architecture, see JobScheduler Universal Agent - connecting via HTTPS through a proxy
- Common pitfalls when setting up HTTPS communication to an Agent