Introduction
JS7 - Encryption and Decryption can be integrated with Secret Manager products in a number of ways. Basic requirements include:
- The Secret Manager is the sole source holding a secret. Secrets can be updated/rotated at any point in time.
- The Secret Manager stores encrypted secrets to JS7 - Job Resources.
- Jobs read encrypted secrets from Job Resources and decrypt on-the-fly.
For creation of Encryption Keys see JS7 - How to create X.509 Encryption Keys.
Integration
Use with Job Resources
Encrypting Secrets to Job Resources
Explanation:
- The Secret Manager encrypts a secret using the target Agent's certificate and stores the encrypted result to a Job Resource variable.
- The Job Resource variable is assigned an environment variable that will be made available to jobs using the Job Resource.
Examples:
For details see JS7 - How to update a Job Resource using Unix Shell.
For details see JS7 - How to update a Job Resource using PowerShell.
Example how to use Bitwarden® CLI to retrieve a password and to store the encrypted password to a Job Resource:
Explanation:- The script requires the jq utility to be available from the operating system.
jq ships with the MIT license, see https://opensource.org/licenses/MIT. - Login to JOC Cockpit can be performed using username/password or using a Client Authentication Certificate, see JS7 - Certificate Identity Service.
- Line 5-10: There are a number of ways how to login and to unlock the vault using Bitwarden CLI. Users should adjust this section.
- Line 17: The JSON returned by Bitwarden CLI depends on the type of secret (1=login, 2=secure note etc.) and will require adjustments to select the desired property.
- The script requires the jq utility to be available from the operating system.
Decrypting Secrets from Jobs
Explanation:
The Job Resource is assigned the workflow to make environment variables available to all jobs or is assigned individual jobs. JS7 takes care to transfer the Job Resource to all Agents that operate workflows or jobs which are assigned the Job Resource. The environment variables specified with the Job Resource are automatically available for shell jobs.
- The job decrypts a secret using the assigned Agent's Private Key.
Examples:
For details see JS7 - How to encrypt and decrypt using Unix Shell
For details see JS7 - How to encrypt and decrypt using Windows Shell
For details see JS7 - How to encrypt and decrypt using PowerShell
Use with Secret Managers
- Secret Manager products are used for lifecycle management of secrets, for example to create, to update, to rotate and to delete secrets.
- Secret Manager products typically offer one or more of the following interfaces:
- Command Line Interface: The Secret Manager CLI can be executed to retrieve a secret. The JS7 encryption scripts can be used to encrypt the secret for later use with JS7 products.
- Event interface: The Secret Manager triggers events when a secret is changed. Typically Secret Managers offer hooks to forward changed secrets to applications such as JS7. This includes an automation scenario when passwords are rotated at regular basis. Hooks can include to execute a shell script, to implement a REST API call etc.
- For CLI/Event integration the following JS7 interfaces can be used:
- For execution of shell scripts and cmdlets see
- For execution of REST API calls see
- JS7 - REST Web Service API
- No REST API calls for encryption are offered as this step is performed outside of JS7 products. Instead, the Secret Manager calls a locally available JS7 Java class to encrypt the secret. Finally the encrypted secret is stored to JS7 using the REST Web Service API.
- The recommended approach is to store changed secrets to JS7 - Job Resources.
- The recommended architecture includes that the Secret Manager forwards changed secrets to JS7.
- It is not a perfect option that JS7 will access the Secret Manager in order to check if a secret changed.
- One reason being that this approach will shift security risks as JS7 would have to authenticate with the Secret Manager at run-time. Availability and accessibility of the Secret Manager would be crucial which is a bad idea considering high availability of the job scheduling solution.
- Another reason being that the Secret Manager knows the point in time when a secret is changed. It's a waste of resources to repeatedly access the Secret Manager if the secret did not change.
Key Distribution
Keys can be distributed in a number of ways. Frequent scenarios include:
- Secret Manager products offering hooks to forward secrets to JS7 can encrypt secrets with the receiving Agent's Certificate or Public Key. If more than one Agent needs access to the same sensitive information,
- the same secret can be encrypted a number of times using individual Certificates/Public Keys per Agent,
- the secret can be encrypted once and the same Private Key can be shared by a number of Agents. This applies to use of secrets in an Agent Cluster if jobs on any Agent should access the same secret.
- Certificates and Public Keys include no sensitive information. There is no harm in making an Agent's Certificate available from a PEM file known to the Secret Manager product.
Further Resources
- JS7 - Encryption and Decryption
- JS7 - How to create X.509 Encryption Keys
- JS7 - How to encrypt and decrypt
- JS7 - How to update a Job Resource using Unix Shell
- JS7 - How to encrypt and decrypt Database Credentials