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

Compare with Current View Page History

« Previous Version 3 Next »

Scope

  • The JobScheduler components are easy to install out-of-the-box. However, some more configuration items have to be considered to operate JobScheduler in a secure environment.
  • Secure operation is applied at the following levels
    • Connection Management
      • Network Connections
      • Database Connections
    • Access Management
      • Authentication
      • Authorization
    • Credentials Management
      • Database Credentials
      • Job Credentials

Connection Management

JobScheduler components make use of the following connections:

 

Network Connections

Default Configuration

The following default configuration is applied by the installer if users would not modify settings during installation:

  • All network connections make use of HTTP
    • Connections from a user browser to the JOC Cockpit
    • Connections from the PowerShell CLI to the JOC Cockpit REST Web Service
    • Connections from the JOC Cockpit REST Web Service to the JobScheduler Master
    • Connections from the JobScheduler Master to Agents
  • Port Usage
    • The JOC Cockpit can be accessed at port 4446
    • The JOC Cockpit REST Web Service can be accessed at port 4446
    • The JobScheduler Master makes use of the following ports
      • Access to the JobScheduler Master Web Service at port 40444
      • Access to the JobScheduler Master via TCP at port 4444
      • Access to the JobScheduler Master via UDP at port 4444
    • The JobScheduler Agent listens to port 4445
  • Network Interface Usage
    • By default JobScheduler components will listen to the above mentioned ports on all available network interfaces.

Secure Configuration

The following recommendations should be applied to secure network connections.

  • Configure network connections to use HTTPS
    • Use of HTTPS includes that users provide valid certificates for the hosts that JobScheduler components are operated for. Use of self-signed certificates is a no-go.
    • As HTTPS is restricted to secure the connection, in addition authentication is added to the configuration, e.g. when using HTTPS then a JobScheduler Master is configured to authenticate with an Agent in order to guarantee that the Master is what it claims to be and is entitled to access an Agent.
    • For detailed instructions on the configuration see
  • Close the JobScheduler Master UDP and TCP port
    • This port is not required for standard operation with releases starting from 1.11. 
    • This port is required for previous releases that include the "classic" JOC GUI running in the JobScheduler Master.
      • Access to this port can be restricted with the <allowed_host> setting in ./config/scheduler.xml
    • This port is required for any releases if a JobScheduler Supervisor is used.
  • Restrict use of network interfaces
    • Consider to restrict the JobScheduler components to listen to specific network interfaces only.
    • The JobScheduler Master can be configured by use of TBD
    • The JobScheduler Agent can be configured by use of TBD

Database Connections

ss

  • x

Access Management

Authentication

Authorization

Credentials Management

Database Credentials

Default Configuration

  • Such credentials are specified during installation and are added to the Hibernate configuration files
    • JobScheduler Master
    • JOC Cockpit
      • For access to the reporting database: ./resources/joc/reporting.hibernate.cfg.xml
      • For access to the JobScheduler database: ./resources/joc/jobscheduler.hibernate.cfg.xml
      • Optionally for access to additional JobScheduler databases: ./resources/joc/jobscheduler.<JobSchedulerID>.hibernate.cfg.xml
  • No default values are provided by the installer.

Secure Configuration

  • Do not use passwords.
    • Users frequently ask if JobScheduler can encrypt credentials. The answer is "no" as this makes no sense.
    • There is only one way how to handle passwords: not to use them.
  • Use Integrated Security

Job Credentials

Default Configuration

  • The Windows Service for the JobScheduler Master and Agent is running in the system account. 
    • The installer allows to specify a different account and to add credentials for that account.
  • By default jobs are executed in the context of the account that the JobScheduler Master or JobScheduler Agent are operated for.

Secure Configuration

  • It is a perfectly bad idea to run a JobScheduler Master or Agent for a Unix root account or Windows Administrator account.
    • Certainly this makes your life easy when it comes to switching to other user accounts or accessing files, 
    • However, you should not grant more permissions to a process than required.
  • Run JobScheduler Master and Agent for specific user accounts
    • Do not use the system account.
  • Do not specify credentials for Windows Service accounts
    • The installer would store credentials in its installation response file (Master: jobscheduler_install.xml, Agent: jobscheduler_agent_install.xml)
    • Instead manually specify credentials for the service account with the Windows Service Panel.
  • There are a number of options when it comes to running jobs for different user accounts
    • For Unix environments
      • Your job scripts can switch to a different user context by use of sudo or su commands. sudo is the preferred option as this the standard Unix tool that allows secure configuration of the users that are allowed to execute certain commands (sudoers file). In addition sudo provides reporting capabilities about (ab)use of commands.
    • For Windows environments
      • You can use the Windows Crendential Manager to safely store credentials of the user account that a job should be executed for. The JobScheduler will then read the credentials and create a new process to run a job in the target user context. This is a preferred solution as it does not store credential data with the JobScheduler configuraiton.
      • Find detailed information from the JobScheduler Universal Agent - Running jobs as a different user article.
    • For all environments

 

 

  • No labels