Introduction

• The JS7 components are easy to install out-of-the-box. However, a number of configuration items have to be considered when operating the 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 JS7 components in a compliance conformant way.

Connection Management

JS7 components use the following connections:

Network Connections

All network connections are unidirectional, as indicated by the direction of the arrows in the above diagram.

Default Configuration

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

• All network connections make use of HTTP:
  • Connections by users to the JS7 - Browser User Interface
  • Connections by from a user browser to the JOC CockpitConnections from the PowerShell CLI to the JS7 - REST Web Service API
  • Connections from by the JOC Cockpit REST Web Service to the JS7 Controller
  • Connections from by the 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 JS7 Controller uses the port 404444444
  • The JS7 Agent listens to port 4445
• Network Interface Usage
  • By default JS7 components will listen to the above mentioned ports on all any 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.

Secure Configuration

The following recommendations should be applied settings are recommend to ensure secure network connections.:

• Configure network connections to use HTTPS:
  • The use Use of HTTPS includes users providing to provide valid certificates for the hosts that JS7 components are operated for. The use Use of self-signed certificates is a no-go as they cannot be verified to a trusted source.
  • As HTTPS is restricted limited to secure the connectionconnections, in addition authentication is added to the configuration, e.g. required, for example when using HTTPS then a JS7 Controller is configured to authenticate with an Agent in order to guarantee that the Controller instance in fact is what it claims to be and is entitled to access an Agentthe Agent.
  • JS7 - Secure Connections by SSL Certificates explains use of the built-in certificate authority and use with external certificate authorities.
  • For detailed instructions on the configuration see:
    • JS7 - JOC Cockpit - HTTPS Authentication explains HTTPS Configuration Items explains HTTPS configuration for the JOC Cockpit and connection to the JS7 Controller.
    • JS7 - Controller Configuration Items
    • JS7 - Agent Configuration ItemsJobScheduler Universal Agent - HTTPS Agent and Master Authentication
• Restrict use of network interfaces
  • Consider restricting JS7 components to only listen to specific network interfaces.
  • The 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 JS7 Agent to use the SCHEDULER_HTTP_PORT and SCHEDULER_HTTPS_PORT environment variables in the JS7 Agent instance script.
    • For details see How to restrict the JobScheduler Agent to listen to specific network interfaces when using HTTP and HTTPS.

Database Connections

• •  command line options to specify network interfaces, see JS7 - Controller - Command Line Operation.
  • The JS7 Agent can be configured to use the --http-port and --https-port options to specify network interfaces, see JS7 - Agent Command Line Operation.
  • JOC Cockpit has to be configured with respective port settings:
    • JS7 - JOC Cockpit Configuration for Docker Containers
    • JS7 - JOC Cockpit Configuration Items

Database Connections

JOC Cockpit is the only JS7 component using a database.

Database All database connections are based on JDBC. If JDBC type 4 drivers are used then a DBMS client is not required for operation of JS7 components. JS7 components use Hibernate as their database access layerJOC Cockpit. The Hibernate access layer is used for database access.

Default Configuration

• JS7 ships with JDBC Drivers that are open source or that are free for bundling distribution with our softwareJS7.
• The JOC Cockpit installer allows
  
  • to specify alternative JDBC Drivers that can be downloaded from the relevant vendor's web site.
  • to specify individual Hibernate configuration files with security related settings.
• For details see Which Database Management Systems are supported by JobScheduler?JS7 - Database.

Secure Configuration

• Depending on the DBMS version in use it may be is 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 JS7. Instead a MariaDB® driver is provided to access MySQL® databases.
  • 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 appliedusers have to download a current JDBC Driver from the vendor's site.
  • 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. for example use of JDBC with Oracle Wallet.
• Consider additional security related settings that apply to your DBMS in the Hibernate configuration files: file, for access to the reporting database: ./resources/joc/reporting.hibernate.cfg.xmlthe location of this file see JS7 - Database.

Access Management

Access to JS7 components is centrally secured by the the JS7 - REST Web Service API. This interface is used by the JS7 - Browser User Interface and by external applications using the REST API.

Roles and Permissions

Default Configuration

• Consider the hints from the JOC Cockpit - Security article
• The JOC Cockpit The JS7 - REST Web Service API ships with a default configuration in ./joc/resources/joc/shiro.ini that includes
  
  • 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 informatioinformation)::
    • Active Accounts:
      • root=root, all
    • Deactivated Accounts (passwords are presented in plain text and are hashed in the shiro.ini configuration file:

      • # administrator

    • administrator

      • =secret, administrator
        

      application

      • # application_manager=secret, application_manager
        

      it

      • # it_operator=secret, it_operator
        

      incident

      • # incident_manager=secret, incident_manager
        

      business

      • # business_user=secret, business_user
        

      api

      • # api_user=secret, api_user

      root=root, all
• The JS7 Controller is assumed not to be accessed by users directly but exclusively via the JS7 REST Web Service. No default authentication is provided.
• JS7 Agents are assumed not to be accessed by users directly but exclusively by a JS7 Controller. No default authentication is provided.

Secure Configuration

• Do not use the default configuration with local authentication for the JS7 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 JS7 Controller and Agents except as stated above.

Credentials Management

Database Credentials

Default Configuration

• Database credentials are specified during installation and are added to the following Hibernate configuration files:
  • JOC Cockpit: for access to the reporting database: ./resources/joc/reporting.hibernate.cfg.xml
• No default values are provided by the installer.

Secure Configuration

• Do not use passwords.
  • Users frequently ask if 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

Job Credentials

Default Configuration

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

Secure Configuration

• It is a bad idea to run a 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 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 (Controller: 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.).

File Transfer Credentials

Such credentials apply to use of the YADE file transfer utility that is available from built-in job templates.

Default Configuration

• By default any accounts/passwords that are used for source connections, target connections and proxy connections are stored in clear text.
• Find the YADE - Reference Documentation - Parameter Reference

Secure Configuration

• Use the YADE Credential Store to manage credentials centrally in a store that is referenced by YADE configuration items, see the How to set-up the Credential Store and YADE Parameter Reference - CredentialStoreFragment articles.
• Should you use FTP connections then consider to switch to use of SFTP.
• SFTP connections can be used with private/public key files, there is no need to use passwords for such connections.

----------

Secure Operation

Access Management

• 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 JS7 Controller is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service- REST Web Service API. No default authentication is provided.
• JS7 Universal Agents are assumed not to be accessed by users directly but exclusively by a JS7 Controller. No default authentication is provided.

Roles and Permissions

Default Configuration

• The JOC Cockpit REST Web Service ships with a default configuration in ./joc/resources/joc/shiro.ini that includesusing local authentication with accounts and passwords stored as hash values,
• using local role assignment,
• the following default values for accounts, passwords and assigned roles (see JOC Cockpit - Authentication and Authorization for more information):

  • 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

Secure Configuration

• It is not recommended to use the default accounts that ship with JOC Cockpit. Default accounts are intended to enable initial login only.
• A fine-grained set of permissions is available that apply to any operation in JOC Cockpit and in the REST Web Service. Such permissions can freely be grouped to roles.
• If possible then LDAP Directory Services should be used to establish role assignment to users based on membership in LDAP security groups.

LDAP Directory Service

Default Configuration

• No LDAP Directory Service integration is in place.
• It is not recommended to use the default configuration with local authentication for the access to JOC Cockpit REST Web Service.

Secure Configuration

• LDAP Directory Services can be accessed for authentication and authorization:
  • users can connect by specifying their domain account.
  • optionally membership in security groups can be mapped to JobScheduler roles.
• Using LDAP allows to operate a JOC Cockpit configuration that contains no account data, no passwords and no role assignments to users. 
• This applies to any LDAP compliant product such as Microsoft Active Directory®, OpenLDAP etc.

...

• For details about LDAP configuration see LDAP Configuration.

Credentials Management

Database Credentials

Default Configuration

• Database credentials are specified during installation and are added to the following Hibernate configuration files:
  • JOC Cockpit: for access to the reporting database: ./resources/joc/reporting.hibernate.cfg.xml
  • For details see JS7 - Database.
• No default values are provided by the installer.

Secure Configuration

• 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 that is in reach of the component that makes use of it. Encrypted passwords correspond to the "key under the mat", they do not provide additional security, however, they perfectly contribute to obfuscation.
  • 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

Job Credentials

Default Configuration

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

Secure Configuration

• It is a bad idea to run a 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 for accessing files.
  • However, you should not grant more permissions to a process than required.
• Use specific user accounts to run 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 does not store such credentials in its installation response file (Controller: jobscheduler_install.xml, Agent: jobscheduler_agent_install.xml)but forwards them to the Windows Service interface, however, there is no guarantee that such credentials will be logged by some Windows mechanism.
  • 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 Agent 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 job 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 articleHow to install JS7-Agent on-premises 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.)JVM jobs.

File Transfer Credentials

Such credentials apply to use of the YADE file transfer utility that is available from built-in job templates.

Default Configuration

• By default any accounts/passwords that are used for source connections, target connections and proxy connections are stored in clear text.
• Find the YADE - Reference Documentation - Parameter Reference

Secure Configuration

• Use the YADE Credential Store to manage credentials centrally in a store that is referenced by YADE configuration items, see the How to set-up the Credential Store and YADE Parameter Reference - CredentialStoreFragment articles.
• Should you use FTP connections then consider to switch to use of SFTP.
• SFTP connections can be used with private/public key files, there is no need to use passwords for such connections.

...