Page History
...
JS7 encryption/decryption can be integrated in a number of ways. Find below a few frequently used scenarios.
Use with Password Managers
- Password Manager products are used for lifecycle management of secrets, i.e. to create, to update, to rotate and to delete secrets.
- Password Manager products typically offer one or more of the following interfaces:
- Command Line Interface: The Password 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 Password Manager triggers events when a secret is changed. Typically Password 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 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 Password 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 scenario occurs outside of JS7 and includes to encrypt the changed secret and to store the encrypted secret to a JS7 Job Resource.
- The recommended architecture includes that the Password Manager forwards changed secrets to JS7.
- It is not an option that JS7 will access the Password Manager in order to check if a secret changed.
- One reason being that this approach will just shift security risks as JS7 would have to authenticate with the Password Manager at run-time. Availability and accessibility of the Password Manager would be crucial which is a bad idea considering high availability of the job scheduling solution.
- Another reason being that the Password Manager knows the point in time when a secret is changed.
Use with Jobs
- Jobs can be subject to a number of scenarios:
- Jobs might want to read passwords from specific sources such as arguments, configuration files etc.
- Jobs might want to create secrets on-the-fly that should be processed by successor jobs.
- Jobs should consider not to expose secrets to logging, database persistence etc.
- Jobs can use the scripts explained with the JS7 - How to encrypt and decrypt Variables article section to encrypt and to decrypt values.
- Jobs can use JS7 - Job Resources to store encrypted values, see JS7 - How to update a Job Resource using the REST Web Service API from the Shell
Key Distribution
Keys can be distributed in a number of ways. Find a few frequently used scenarios.
Use with a Password Manager Product
- Password Manager products offering hooks to forward secrets to JS7 should 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 (recommended),
- the secret can be encrypted once and the same Private Key can be shared by a number of Agents.
- 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 Password Manager product.
Use with Jobs
Users should create individual Private Keys and Certificates for encryption/decryption of secrets.
...
:
- JS7 - Encryption - Integration with Password Manager products
- JS7 - Encryption - Integration with Jobs
Further Resources
- JS7 - How to encrypt and decrypt Variables
- JS7 - How to update a Job Resource using the REST Web Service API from the Shell
- JS7 - How to encrypt and decrypt Database Credentials
...
Overview
Content Tools