Page History

...

Scope

• The JobScheduler JS7 components are easy to install out-of-the-box. However, a number of configuration items have to be considered when operating the JobScheduler JS7 for a secure environment.
• Secure operation is applied at the following areas:
  • Connection Management
    
    • Network Connections
    • Database Connections
  • Access Management
    • Authentication
    • Authorization
  • Credentials Management
    • Database Credentials
    • Job Credentials
• Secure operation includes users configuring JobScheduler JS7 components in a compliance conformant way.

Connection Management

JobScheduler JS7 components use the following connections:

...

• 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 MasterJS7 Controller
  • Connections from the JobScheduler Master JS7 Controller 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 JS7 Controller uses the following ports:
    • Access to the JobScheduler Master JS7 Controller Web Service at port 40444
    • Access to the JobScheduler Master JS7 Controller via TCP at port 4444 

      Display feature availability
      EndingWithRelease 1.12

    • Access to the JobScheduler Master JS7 Controller via UDP at port 4444 

      Display feature availability
      EndingWithRelease 1.12

    • The TCP port 4444 and HTTP port 40444 enable access to the "classic" JOC GUI. 

      Jira
      server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-304

  • 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.
• Firewall Settings
  • Open ports in your firewall exclusively for the hosts, protocols and ports as specified above. Consider allowing connections only for the directions indicated in the diagram above.

...

• Configure network connections to use HTTPS
  • The use of HTTPS includes users providing valid certificates for the hosts that JobScheduler JS7 components are operated for. The 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 JS7 Controller is configured to authenticate with an Agent in order to guarantee that the Master Controller is what it claims to be and is entitled to access an Agent.
  • For detailed instructions on the configuration see:
    • JOC Cockpit - HTTPS Authentication explains HTTPS configuration for the JOC Cockpit and connection to the JobScheduler MasterJS7 Controller.
    • JobScheduler Universal Agent - HTTPS Agent and Master Authentication
• Drop the JobScheduler Master JS7 Controller TCP / UDP 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 MasterJS7 Controller.
    • Access to this port can be restricted with the <allowed_host> setting in ./config/scheduler.xml

  • This port is required for all releases if a JobScheduler Supervisor is used.
• Restrict use of network interfaces
  • Consider restricting JobScheduler JS7 components to only listen to specific network interfaces.
  • The JobScheduler Master JS7 Controller can be configured by use of the http_port and https_port attributes in the ./config/scheduler.xml configuration file.
    • For details see How to restrict the JobScheduler Master to listen to specific network interfaces when using HTTP or HTTPS.
  • Configure the JobScheduler JS7 Universal Agent to use the SCHEDULER_HTTP_PORT and SCHEDULER_HTTPS_PORT environment variables in the JobScheduler JS7 Agent instance script.
    • For details see How to restrict the JobScheduler Agent to listen to specific network interfaces when using HTTP and HTTPS.
• Drop the "classic" JOC GUI
  • The "classic" JOC GUI ships without authentication and authorization. It is included with release 1.11 for users who stick to this interface. It is available from the above TCP port and HTTP port. 

    Display feature availability
    EndingWithRelease 1.12

  • To drop the "classic" JOC GUI remove the SCHEDULER_HOME/operations_gui folder.

...

• Depending on the DBMS in use it may be preferable to download and to apply the DBMS vendor's current JDBC Driver version:
  • For use with MySQL the JDBC Driver is not included with JobScheduler. Instead a MariaDB driver is provided.
  • For use with Microsoft SQL Server the JDBC Driver is not included, instead the jTDS Driver is provided. In order to apply integrated security (see below chapter Credentials Management) it is recommended that a current Microsoft JDBC Driver is applied.
  • For use with Oracle newer JDBC Driver versions are available from the vendor's web site.
• Vendor-specific JDBC Drivers include support for specific authentication mechanisms, e.g. use of JDBC with Oracle Wallet.
• Consider additional security related settings that apply to your DBMS in the Hibernate configuration files:
  • ControllerJobScheduler Master
    • for access to the reporting database: ./config/reporting.hibernate.cfg.xml
    • for access to the JobScheduler database: ./config/hibernate.cfg.xml
  • 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 different locations of Hibernate configuration files can be set in ./resources/joc/job.properties for access to additional JobScheduler databases

...

• Consider the hints from the JOC Cockpit - Security article
• The JOC Cockpit REST Web Service ships with a default configuration in ./joc/resources/joc/shiro.ini that includes
  • using local authentication with accounts and passwords stored in clear text. 

    Display feature availability
    EndingWithRelease 1.11.4

  • using local authentication with accounts and passwords stored as hash values. 

    Display feature availability
    StartingFromRelease 1.11.5

  • using local role assignment
  • the following default values for accounts, passwords and assigned roles (see JOC Cockpit - Authentication and Authorization for more informatio):

    • administrator=secret, administrator
application_manager=secret, application_manager
it_operator=secret, it_operator
incident_manager=secret, incident_manager
business_user=secret, business_user
api_user=secret, api_user
root=root, all

• The JobScheduler Master JS7 Controller is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service. No default authentication is provided.
• JobScheduler JS7 Universal Agents are assumed not to be accessed by users directly but exclusively by a JobScheduler MasterJS7 Controller. No default authentication is provided.

...

• Do not use the default configuration with local authentication for the JOC Cockpit REST Web Service.
  • Instead use LDAP authentication as explained with the JOC Cockpit - Authentication and Authorization section.
• Do not allow any network connections to the JobScheduler Master JS7 Controller and Agents except as stated above.

...

• Database credentials are specified during installation and are added to the following Hibernate configuration files:
  • ControllerJobScheduler Master
    • for access to the reporting database: ./config/reporting.hibernate.cfg.xml
    • for access to the JobScheduler database: ./config/hibernate.cfg.xml
  • 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 different locations of Hibernate configuration files can be set in ./resources/joc/job.properties for access to additional JobScheduler databases
• No default values are provided by the installer.

...

• Do not use passwords.
  • Users frequently ask if JobScheduler JS7 can encrypt credentials. The answer is "no" as it makes no sense for an Open Source software component to handle a symmetric key.
  • There is one way only how to handle passwords: not to use them.
• Use Integrated Security
  • This authentication scheme starts from the fact that the account that a component is operated for is already authenticated and therefore can access a database without specifying user/password credentials.
  • This feature is available for a number of DBMS such as
    • Microsoft SQL Server, see the How to connect to an SQL Server with a domain account article.
    • Oracle that includes support for Oracle Wallet, see How to connect to an Oracle database without using passwords

...

• The Windows Service for the JobScheduler Master JS7 Controller and Agent runs 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 JS7 Controller or JobScheduler JS7 Agent are operated for.

Secure Configuration

• It is a bad idea to run a JobScheduler Master JS7 Controller or Agent using a Unix root account or Windows Administrator account.
  • Certainly this makes 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.
• Use specific user accounts to run JobScheduler Masters JS7 Controllers and Agents:
  • Do not use the system account (Windows) or root (Unix).
  • Create specific service accounts that are limited to privileges that are required to execute jobs.
• Do not specify credentials for Windows Service accounts during installation:
  • The installer will store such credentials in its installation response file (MasterController: jobscheduler_install.xml, Agent: jobscheduler_agent_install.xml)
  • Instead, use the Windows Service Panel to manually specify credentials for the service account.
• 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 Credential 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 the preferred solution as it does not store credentials with the JobScheduler configuration.
    • Find detailed information from the JobScheduler Universal Agent - Running jobs as a different user article.
  • For all environments
    • You can run a number of Agents in parallel for different user accounts.
    • For details see the JobScheduler Universal Agent - Running multiple instances article.
• For jobs that require credentials, e.g. to access a database, a credential store can be used, see the Using a Credential Store for Jobs article.
  • Credentials are not provided from parameters (that could be logged in clear text), instead an interface is provided that allows on demand access to the credential store. 
  • This feature is available for Shell jobs and for API jobs (JavaScript, PowerShell etc.).

...

• Access Management includes access to JOC Cockpit and to the REST Web Service. This applies to users who access the JOC Cockpit GUI and to scripts and applications that directly access the REST Web Service.
• The JobScheduler Master JS7 Controller is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service. No default authentication is provided.
• JobScheduler JS7 Universal Agents are assumed not to be accessed by users directly but exclusively by a JobScheduler MasterJS7 Controller. No default authentication is provided.

...

• The Windows Service for the JobScheduler Master JS7 Controller and Agent runs 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 JS7 Controller and JS7 Agent are operated for.

Secure Configuration

• It is a bad idea to run a JobScheduler Master JS7 Controller or Agent using a Unix root account or Windows Administrator account.
  • Certainly this makes 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.
• Use specific user accounts to run JobScheduler Masters JS7 Controllers and Agents:
  • Do not use the system account (Windows) or root (Unix).
  • Create specific service accounts that are limited to privileges that are required to execute jobs.
• Do not specify credentials for Windows Service accounts during installation:
  • The installer will store such credentials in its installation response file (MasterController: jobscheduler_install.xml, Agent: jobscheduler_agent_install.xml)
  • Instead, use the Windows Service Panel to manually specify credentials for the service account.
• 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 Credential Manager to safely store credentials of the user account that a job should be executed for. The JobScheduler Agent will then read the credentials and create a new process to run a job in the target user context. This is the preferred solution as it does not store credentials with the JobScheduler job configuration.
    • Find detailed information from the JobScheduler Universal Agent - Running jobs as a different user article.
  • For all environments
    • You can run a number of Agents in parallel for different user accounts.
    • For details see the JobScheduler Universal Agent - Running multiple instances article.
• For jobs that require credentials, e.g. to access a database, a credential store can be used, see the Using a Credential Store for Jobs article.
  • Credentials are not provided from parameters (that could be logged in clear text), instead an interface is provided that allows on demand access to the credential store. 
  • This feature is available for Shell jobs and for API jobs (JavaScript, PowerShell etc.).

...