Introduction
Jobs might require variables for parameterization that hold secrets. We find a number of requirements for management of such variables:
- The secret should not be exposed to JS7 logging or to any instance of JS7 products that track variables.
- For example, if a variable created by some job should be forwarded to a next job executed with a different Agent then the Controller and JOC Cockpit keep track of the variable.
- The variable is available in the Agent's and the Controller's memory.
- The variable is available in the Controller's journal, in JOC Cockpit's JS7 - History and in the JS7 - Database.
- At no point in time the secret should be available to involved JS7 products, to the database or to the OS.
- For example, if a variable created by some job should be forwarded to a next job executed with a different Agent then the Controller and JOC Cockpit keep track of the variable.
- We find a number of inadequate approaches that do not make it for a secure solution:
- Symmetric keys are a No-Go as they are available in two places and leave it up to the implementation where to store the key.
- Obfuscation is a No-Go as it does not resist to attacks.
The preferred solution with JS7 is use of asymmetric keys:
- JS7 - Encryption and Decryption can be performed directly by scripts that are used outside of JS7 products or by related jobs.
- No JS7 product is directly involved in encryption/decryption as otherwise the JS7 product would know the keys involved that potentially could be compromised by logging, database persistence etc.
- Performing encryption/decryption by jobs limits the attack surface to the OS process executing the job. The job implementation is controlled by the user who can verify secure operation.
For creation of Encryption Keys see JS7 - How to create X.509 Encryption Keys.
Asymmetric Keys
Encryption and decryption use asymmetric keys, for details see JS7 - Encryption and Decryption:
Encryption
Use with Variables
The value of a variable can be encrypted using shell scripts, cmdlets, Java classes and JITL jobs:
- JS7 - How to encrypt and decrypt using Unix Shell
- JS7 - How to encrypt and decrypt using Windows Shell
- JS7 - How to encrypt and decrypt using PowerShell
- JS7 - How to encrypt and decrypt using Java
- JS7 - JITL EncryptJob
When executed from jobs, then the encrypted secret can be stored to a variable that is made available to later jobs in the workflow.
Use with Job Resources
The value of a variable is encrypted and is stored to JS7 - Job Resources using shell scripts, cmdlets or JITL jobs:
- JS7 - How to update a Job Resource using Unix Shell
- JS7 - How to update a Job Resource using PowerShell
- JS7 - JITL SetJobResourceJob
The Job Resource can be accessed by any jobs in the same or in other workflows.
Decryption
Encrypted secrets are made available from variables. This similarly works for variables that are created by predecessor jobs on the fly and by Job Resources. For shell jobs workflow variables are made available from OS environment variables.
The basic proceeding works like this:
- Consider the parties involved and related use cases:
- A job executed on Agent A should be parameterized by a variable holding a secret.
- A job executed on Agent B retrieves a secret that should be forwarded to the job on Agent A and possibly to other Agents too.
- Use of asymmetric keys allows
- to create and to store a Private Key on Agent A.
- to use Agent A's Certificate or Public Key on Agent B or on any other system involved.
- to manage encryption and decryption like this:
- create a symmetric one-time key and an encrypted copy of the key from Agent A's Certificate/Public Key.
- encrypt the value of a variable with the one-time key.
- drop the one-time key and forward the encrypted copy of the one-time key and the variable holding the encrypted value to Agent A.
- only Agent A will be able to decrypt the encrypted one-time key using its Private Key which provides the symmetric key required to decrypt the variable's value.
- Find details from JS7 - Encryption and Decryption.
Resources