Page History
...
- The Security Architecture includes
- Secure Communication
- Certificate Management: Create and deploy certificates for secure network communication between components.
- Life Cycle Management: Create, update and delete certificates and deploy changes to components.
- Secure Configuration
- Configurations include workflows, jobs and related objects.
- Such objects are digitally signed and deployed by a responsible person.
- Secure Operation
- Access Management: Authentication and Authorization via LDAP Directory Service.
- Credential Management: Use of a Credential Store for confidential data.
- Secure Communication
- Wording
- The term Deployment applies to a situation that a configuration is transferred from JOC Cockpit to a Master.
- The term Roll-out applies to a situation that a configuration is transferred between environments, e.g. from dev to test and to prod. Within the respective target environment a Deployment is performed to transfer configuration objects to Masters and Agents.
...
- Steps for a roll-out include
- that roll-out might include shared responsibilities, e.g being performed by an individual that is different from the person who managed the configuration, e.g.
- a developer would create workflows and jobs in a development environment and deploy them to Masters and Agents in that environment.
- an application manager would perform some quality assurance and pick up configurations from a development environment for roll-out to a test environment
- a release manager would authorize roll-out from a test environment to a production environment.
- to export a configuration the affected configuration objects are downloaded to a single archive file (.zip, .tar.gz)
- to sign the downloaded configuration objects should Security Level High be in place including the tasks
- to transfer the downloaded archive to a secure environment, e.g. a computer that is separated from the network.
- to extract the archive to disk and to use a program that applies to company standards to sign the files included with the archive. This step includes that the user's private key is used to sign files. As a result for each file extracted from the archive a signature file is created.
- to add the extracted files and the signature files to an archive file.
- to transfer the archive with signed files to the target environment. This includes to use any means for file transfer such as copying between servers, use of SCP, SFTP etc.
- to import the archive with signed files to JOC Cockpit in the target environment.
- that roll-out might include shared responsibilities, e.g being performed by an individual that is different from the person who managed the configuration, e.g.
- The final step includes to deploy the imported signed configuration objects to the target environment.
- This task can be performed by the same individual who signed and transferred the archive file or this can require a separate role in JOC Cockpit to be authorized to deploy in the target environment.
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 JobScheduler Master is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service. No default authentication is provided.
- JobScheduler Universal Agents are assumed not to be accessed by users directly but exclusively by a JobScheduler Master. 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 includes- using 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
- It is not recommended to use the default configuration with local authentication for the 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.
Credential Management
Database Credentials
Default Configuration
- 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 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 JobScheduler Master 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 Agent are operated for.
Secure Configuration
- It is a bad idea to run a JobScheduler Master 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 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 (Master:
jobscheduler_install.xml
, Agent:jobscheduler_agent_install.xml
) - Instead, use the Windows Service Panel to manually specify credentials for the service account.
- The installer will store such credentials in its installation response file (Master:
- 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
orsu
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 additionsudo
provides reporting capabilities about (ab)use of commands.
- Your job scripts can switch to a different user context by use of
- 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 Unix environments
- 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.
Credentials Management
Database Credentials
Job Credentials
...
Overview
Content Tools