You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

work in progress

Article under construction

Communication to and from the Java Based Agent can be secured by HTTPs using a 3rd party proxy (e.g. apache http server, nginx).

This setup needs 2 users on the agent server:

  • User A
    • has access to the SSL certificate and the SSL key
    • has access to the proxy server configuration files
    • executes the proxy server, which is configured to
      • allow connections by HTTPs (using the SSL certificate and key)
      • allow connections only from certain IPs
      • proxy these connections to JobScheduler Agent on localhost
      • optional: allow only GET requests for certain IPs (read-only)
  • User B
    • does not have access to the SSL certificate and the SSL key
    • does not have access to the proxy server configuration files
    • executes the JobScheduler Agent which is parameterized to
      • only allow connections on the local network interface

All communication between the JobScheduler Master server and the Agent server goes through an HTTPs connection

  • JobScheduler Master requests a job start on the Agent
    • the request goes through https to the proxy
    • the proxy forwards the request by http to JobScheduler Agent the same machine
    • JobScheduler Agent starts an agent task
  • The agent tasks commuicates with JobScheduler Master (logging, api calls...)
    • the agent task connects on port 59999 or lower to the JobScheduler Agent
    • JobScheduler agent uses the existing HTTP connection to the proxy continuing in an HTTPs connection to JobScheduler master to relay communication from the agent task to JobScheduler master

 

This setup secures the agent against:

  • attackers eavesdropping on the network
  • attackers using JobScheduler agent to steal the SSL certificate and key
  • attackers using JobScheduler agent to reconfigure the authentication in the proxy
  • attackers spoofing the identity of the agent server
  • attackers trying to control the agent from other IPs

This setup does not secure the agent against:

  • attackers spoofing the IP of the Master JobScheduler

possible enhancements

Validating the client identitiy using HTTPs client authentication

  • JobScheduler Master is configured with a client HTTPs certificate
  • The proxy is configured to only accept connections with a valid client certificate

Validating the client identity with username/password

  • JobScheduler Master is configured with a username and password for each remote process class
  • JobScheduler Master sends username and password by simple HTTP authentication
  • The password is validated either
    • by JobScheduler Agent (could later be enhanced for a more granular authorization)
    • by the proxy

 

  • No labels