Integrations
CI/CD Integrations provided with Keeper Secrets Manager
Keeper Secrets Manager integrates into popular CI/CD platforms and development environments. Use Keeper Secrets Manager to inject secrets into your build processes, and remove hard-coded credentials from your environments.
Ansible
A collection of Ansible plugins that interact with Keeper Secrets Manager
AWS CLI Credential Process
Protect your AWS Access Keys with Keeper Secrets Manager
Go to AWS CLI Credential Process Documentation
AWS Secrets Manager
Sync secrets from the Keeper Vault with AWS Secrets Manager
Go to AWS Secrets Manager Documentation
AWS KMS
Protect your Keeper Secrets Manager connection with AWS.
Azure DevOps
Securely retrieve secrets from the Keeper Vault and use them in Azure DevOps pipelines. Remove hardcoded values, fetch secure files, and keep all your build credentials in the Keeper Vault.
Go to Azure DevOps Integration
Azure Key Vault
Sync secrets from the Keeper Vault with Azure Key Vault.
Go to Azure Key Vault Documentation
BitBucket
Retrieve secrets from the Keeper Vault within BitBucket Pipelines.
Go to BitBucket Plugin Documentation
Docker Image
The Secrets Manager CLI can be used to pull secrets from a Docker image at runtime, or it can be used by building it into the docker image.
Go to Docker Image Documentation
Docker Runtime
Keeper Secrets Manager integrates with the Docker Runtime so that you can dynamically retrieve a secret from the vault when the container executes.
Go to Docker Runtime Documentation
Docker Writer Image
A general purpose docker image to retrieve secrets.
Entrust HSM
Protect your Keeper Secrets Manager connections with the Entrust HSM
Go to Entrust HSM Documentation
GCP Secret Manager
Sync secrets from the Keeper Vault with GCP Secret Manager.
Go to GCP Secret Manager Documentation
Git
This integration will let you sign git commits with an SSH key in your Keeper Vault (via Keeper Secrets Manager) rather than using a key stored on disk.
GitHub Actions
This action securely retrieves secrets from Keeper and places them to the desired destination of the GitHub Actions runner such as an environment variable, output parameters of the step or to a file.
Go to Github Actions Integration
GitLab
Bring secret credentials into your GitLab Pipeline builds using Keeper's Secrets Manager GitLab plugin.
Hashicorp Vault
Use Keeper Secrets Manager with HashiCorp Vault as a Data Source
Go to Hashicorp Vault Documentation
Heroku
Use Keeper Secrets Manager SDKs to bring secret credentials and files securely into Heroku builds.
Jenkins
The Jenkins plugin for Keeper Secrets Manager allows you retrieve secrets from the Keeper Vault and place the values into environmental variables or files within the builder and workflow pipelines.
Go to Jenkins Plugin Documentation
Keeper Connection Manager
Store connection credentials in the Keeper Vault and easily use them in Connection Manager.
Go to Keeper Connection Manager Documentation
Kubernetes
Keeper Secrets Manager can be integrated into your K8s cluster for accessing Keeper secrets in real-time across all pods.
Go to the Kubernetes External Secrets Operator Documentation
Go to the legacy Kubernetes Documentation
Octopus Deploy
Use credentials from your Keeper Vault in Octopus Deploy workflows. Integrate with Keeper Secrets Manager to securely access all the platforms and services you connect to with Octopus Deploy.
PowerShell
Utilize PowerShell's Secret Management module to access secrets from Keeper.
Go to PowerShell Documentation
ServiceNow
Retrieve credentials from the vault from the ServiceNow Management, Instrumentation, and Discovery (MID) Server integration.
Go to ServiceNow Documentation
TeamCity
Use secrets from the Keeper vault in TeamCity builds.
Teller
Retrieve secrets from the Keeper Vault within Teller environments.
Terraform
The Keeper Terraform Plugin utilizes Keeper Secrets Manager to provide access to secret credentials saved in the Keeper Vault. The Keeper Terraform plugin allows for injecting secrets directly into Terraform builds securely using Keeper's zero-knowledge infrastructure.
TeamCity
The TeamCity integration allows TeamCity servers to integrate with Keeper Secrets Manager to make managing secrets in TeamCity easier and more secure.
XSOAR
Use credentials from your Keeper Vault in XSOAR workflows. Integrate with Keeper Secrets Manager to securely access all the platforms and services you connect to with XSOAR.
CLI Tools
Use Keeper Secrets Manager in a CLI environment. Build scripts that securely utilize your secrets, or easily access Secrets Manager functionality from your terminal.
PowerShell
The Keeper Secrets Manager PowerShell plugin utilizes Microsoft PowerShell's Secret Management module to inject secrets from the Keeper Vault into your PowerShell scripts.
Go to PowerShell Documentation
Secrets Manager CLI
The Keeper Secrets Manager CLI ("KSM CLI") provides core Secrets Manager Vault interaction from a terminal, shell script or any software that can be launched from a shell.
Ansible
Use Keeper Secrets Manager with Ansible
Features
Retrieve secrets from the Keeper vault to use in Ansible Playbooks
Update the value of secrets in the Keeper Vault from Ansible
Copy files from the Keeper Vault
Use Keeper Secrets Manager within Ansible Tower to fetch secret credentials and files in your Ansible Playbooks.
For a complete list of Keeper Secrets Manager features see the Overview
Ansible Integrations
Check out the nested pages for using Secrets Manager with Ansible
How to use Keeper Secrets Manager to fetch secret credentials and files in your Ansible Playbooks
Store Keeper Secrets Manager configuration credentials in Ansible Tower and create reusable playbook templates that utilize Keeper Secrets Manager features.
Ansible Plugin
A collection of Ansible plugins that interact with your Keeper account and can be used in your automations.
Features
Retrieve secrets from the Keeper vault to use in Ansible Playbooks
Update the value of secrets in the Keeper Vault from Ansible
Create records from Ansible
Copy files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Ansible integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The Ansible integration accepts both Base64 and JSON format configurations
Installation
Due to the flexibility of Ansible, where you install the plugins depends on your Ansible installation and playbook locations.
Install Keeper Ansible Module
Installation via Ansible Galaxy
The collection can be found on the Ansible Galaxy website. You can install the collection with the follow command line.
Ansible Galaxy collection uses long plugin names. The name is the collection name combined with the plugin name. For example, the keeper_copy plugin name when using Ansible Galaxy is keeper_security.keeper_secrets_manager.keeper_copy. If you want to use the short plugin name, add keepersecurity.keeper_secrets_manager to the collections block of your playbook.
Installing via Ansible Galaxy assumes you already have Ansible installed. Ansible Galaxy cannot install dependencies. The following dependencies will need to be installed manually, via pip, into your the python library or virtualenv used by Ansible.
importlib_metadata
keeper-secrets-manager-core>=16.4.1
keeper-secrets-manager-helper>=1.0.4
Installation via Pypi
The Ansible module for Keeper is installed with the command below. Make note of the location where the module is installed, as this will be needed in the Ansible playbook configuration.
Find the Keeper Secrets Manager Ansible Plugin source code in the GitHub repository.
The Keeper ansible plugins are installed in the site-packages directory of your version of Python or your current virtual environment. You can find the plugin locations using the following command:
Those paths can be used in your ansible.cfg.
Generate a Config File
Prior to proceeding with this guide, make sure you meet all the prerequisites and have the following:
KSM Application and it's One-Time Access Token
Keeper Ansible module installed
In order to use the Ansible plugin for Keeper Secrets Manager, a Keeper config file is required. Once you have a config file, the configuration values can be placed into the Ansible variable files. These variable files can be encrypted with Ansible vault.
Using the Keeper Ansible module and the generated One-Time Access Token, generate a Configuration file:
This will generate the Keeper JSON configuration file in the current directory.
If you do not have your Python module bin path added your PATH environment variable, you can create a config with the following command.
The default name for the JSON configuration file is client-config.json. The content of the file will look like the following:
This config file allows your Ansible playbook to authenticate and retrieve designated secrets from the vault.
Ansible Variables
The Keeper Secrets Manager plugins can use multiple configuration methods. For example, the Base64 encode configuration can be used.
Ansible can use the client-config.json config file directly. It can be specified in the Ansible variables using the keeper_config_file variable key.
Another solution is to place the values in your client-config.json file into an Ansible variable file. For example, the values can be placed into the group_vars, host_vars, or in the task files:
For security, the group_vars or host_vars files can be encrypted with ansible-vault.
A list of valid Ansible Variables for the Keeper plugin are below:
Ansible Variable
JSON Key
Description
keeper_config
--
A Base64 encoded configuration string.
keeper_config_file
--
An alternative path and name for the JSON configuration file, if not current directory or named differently than client-config.json.
keeper_token
clientKey
The one time access token, also known as the client key. Only used to initialize the configuration.
keeper_client_id
clientId
The client id provided from Secrets Manager after the one time access token is used. Required.
keeper_app_key
appKey
The app key provided from the secret management service after the one time access token is used. Required.
keeper_private_key
privateKey
The private key provided from the secret management service after the one time access token is used. Required.
keeper_app_owner_public_key
appOwnerPublicKey
The public key used for creating records. Required if using the keeper_create plugin.
keeper_server_public_key_id
serverPublicKeyId
Selects which public key to use when connecting to the server. If the server wants a different public key the SDK will handle switching. Not required, but will reduce number of web service calls.
keeper_hostname
hostname
The Secrets Manager backend hostname. Defaults to US. Supports "US", "EU", "AU" and "US_GOV" values depending on your Keeper data center location. Required.
keeper_log_level
--
Set the log level of the SDK. Acceptable levels are DEBUG, INFO, WARNING, ERROR, and CRITICAL. Defaults to ERROR.
keeper_record_cache_secret
--
Required for the keeper_cache_records action. Used to encrypt records in cache. The value of this variable can be created in the playbook. See action example.
keeper_use_cache
--
Use a cache of the vault. Defaults to False. Cache file are only used as backup for network problems.
keeper_cache_dir
--
The directory to write and read the cache file.
keeper_record_types
--
An list of Keeper Commander record type definitions.
There are two caching methods in the plugin. They are not the same.
keeper_record_cache_secret is used to cache records for a playbook run. After the playbook run, the cache is removed. The cache is stored in memory encrypted. This cache can be used to reduce the number of API called to the Keeper Secret Manager service. Since this cache is stored in memory, the more records retrieved the more memory is used.
keeper_use_cache and keeper_cache_dir are used for Disaster Recovery caching of the Keeper Vault. This cached is used when connection to the Keeper Secret Manager service cannot be reached. This cache is stored encrypted on disk.
Command Line Variables
As an optional method, values can be passed in through the ansible-playbook command. Example:
Ansible Plugin Usage
There are three Keeper action plugins and one lookup plugin.
For all the plugins, the following arguments are used. Either the uid or title is required.
uid- The Record UID of the desired record.title- The Record Title of the desired record.field- Retrieve the value with specified label from the record.custom_field- Retrieve the value with the specific custom field name.file- Retrieve the file with the specified name from the record.
The uid value is required, and you need either field or file populated.
To find out what fields and custom fields are available for a specific vault secret, use the Keeper Secrets Manager CLI "ksm secret get -u XXXX" command. More info here.
The plugin example are shown with the short plugin names. If you installed the collection via Ansible Galaxy, you will need to use the longer plugin name or add the collection name to the list of collections used in your playbook.
Actions can either use Keeper Notation or the record UID or Title, combined with the task attributes array_index and value_key to get a specific value.
For example, a complex value like Phone number is an array of objects.
The example, below is show how to use Keeper Notation and array_index and value_key to get the same result.
Plugin: keeper_cache_records
The plugin keeper_cache_records is used to retrieve a select amount of records to be stored in a cache. The cache can then be used by other actions. This is used to reduce the number of API calls by getting all required record up front.
The records can be retrieved by the record UID or by the record title. The result of the action is an encrypted serialization of the records. The result should be stored in Ansible by using the register variable so it can be used by other actions. The encrypted serialization of the records can be quite long. For security and reducing log noise, it is recommended to set no_log to True.
keeper_cache_records caches records only. It does not cache attached files. If an action attempts to retrieve an attached file from a record that came from the cache, an API call will be made to download the file.
Use templating to set the attributes in other actions. For example cache: "{{ my_records.cache }}"
keeper_cache_records requires the keeper_record_cache_secret to be set. This can be done in the host, group, task variables, or generated in a task and then set as a fact (variable). In the example above, the keeper_password action is used to generate a password which is then stored as keeper_record_cache_secret. The no_log attribute is set to True to prevent the secret from being logged.
The cache will not update. The cache will not contain records created or updated after it has been generated. To get new records or changes in the cache, keeper_cache_records will need to be called again.
Required Attributes
uids- A list of Keeper Vault record UID.titles- A list of titles of Keeper Vault records.
The attributes uids and titles can be used at the same time. At least one of them needs to be set.
Plugin: keeper_copy
keeper_copyThe plugin keeper_copy is an extension of the built-in copy plugin. Example:
In the examples, a password will be copied from the Keeper vault record and stored in the file /tmp/my_password on the remote system. It will use the Ansbile built-in copy plugin's mode attributes to changed the permissions of the file.
The last task example from above, the file "my_cert_file.crt" will be coped from the Keeper vault record and stored at the location "/tmp/special.crt". Several of the built-in copy plugin functions will be applied to the file.
Required Attributes
uid- A Keeper Vault record UID.title- Title of a Keeper Vault records.notation- Use Keeper Notation to get the field from a record.
The attributes uids and titles can be used at the same time. At least one of them needs to be set.
Optional Attributes
cache- The record cache from thekeeper_cache_recordsaction.field- Get the content from the standard Keeper Vault record.custom_field- Get the content from the custom Keeper Vault record.file- Get the content from the files attach to the Keeper Vault record by file title.array_index- Defaults to 0. If the field value contains multiple values, this attribute will allow you to select which item to return. The first item will have thearray_indexof 0, and the next will be 1, etc.value_key- If the field value is a complex object, this will allow you to select the key of the key/value pair to return.
Additional optional attributes are the same as the built-in copy plugin attributes. The attributes src, remote_src, and content are not allowed and will be ignored.
Plugin: keeper_get
keeper_getThe plugin keeper_get will retrieve a field or file from a Keeper vault record. Example:
The keeper_get plugin returns a dictionary. The key "value" in the dictionary will contain the desired field or file content. This plugin is normally paired with the Ansible register instruction and the returned value is stored in memory so it can be accessed by other tasks.
In the example above, a record containing user's login name is retrieved. The login name is then stored under the name my_login. The second task will print the login name to your console for debug purposes. The third task will add a sudoer file for the login name with ability to execute all applications.
Required Attributes
uid- A Keeper Vault record UID.title- Title of a Keeper Vault records.notation- Use Keeper Notation to get the field from a record.
The attributes uids and titles can be used at the same time. At least one of them needs to be set.
Optional Attributes
cache- The record cache from thekeeper_cache_recordsaction.field- Get the value from the standard Keeper Vault record.custom_field- Get the value from the custom Keeper Vault record.file- Get the value from the files attach to the Keeper Vault record by file title.allow_array- By default is False. If set to True, an array of values will be returned. This is needed if the field contains multiple values such as Phone numbers. If True,array_indexandvalue_keywill be ignored.array_index- Defaults to 0. If the field value contains multiple values, this attribute will allow you to select which item to return. The first item will have thearray_indexof 0, and the next will be 1, etc.value_key- If the field value is a complex object, this will allow you to select the key of the key/value pair to return.
Plugin: keeper_get_record
keeper_get_recordThe plugin keeper_get_record will retrieve all the fields in the record and return them in a dictionary. Example:
The keeper_get_record plugin returns a dictionary. The keys of the dictionary are the normalized field labels, or types. The keys will be alphanumeric and the underscore characters. If there are duplicate key, a number will be appended to the end of the key.
In the example above, a record is retrieved using the UID. The fields will be stored in a dictionary, in memory, using the register instruction. Since the allow attribute is used, the dictionary will only contain login and password .The field values can be accessed using the normal the templating in Ansible. The values will be stored as arrays. This is due to some fields returning arrays of the values, such as phone.
Required Attributes
uid- A Keeper Vault record UID.title- Title of a Keeper Vault records.
Either uids and titles is required.
Optional Attributes
cache- The record cache from thekeeper_cache_recordsaction.allow- A list of keys to allow. If set, if the key is not in the list, it will not be inclued in the dictionary.
Plugin: keeper_set
keeper_setThe keeper_set plugin has the ability to write a value into an existing Keeper vault record. Example:
In this example, a new user's login name is retreived. The new user is created on the remote system with the login name from the record. The home directory on the remote machine is then updated in the record.
The keeper_set action does not have the ability of set individual values of an array or complex values. It simplely replaces the existing value with a new value. For example, for a Hostname and Port field type there is no way to just update the port. The entire value including the hostName needs to be included in the object value.
keeper_set will set the update the record in the vault. It will not update the cache, if used. To update the cache, a step will need to run the keeper_cache_records action again with the UID or Title of the record that was updated.
Required Attributes
uid- A Keeper Vault record UID.title- Title of a Keeper Vault records.notation- Use Keeper Notation to get the field from a record.
The attributes uids and titles can be used at the same time. At least one of them needs to be set.
Optional Attributes
cache- The record cache. Used for getting the record, will not update the cache.field- Update the existing standard Keeper Vault record field.custom_field- Update the existing custom Keeper Vault record field.
Plugin: keeper_create
keeper_createThe keeper_create plugin creates a record in the Keeper vault. See the Field/Record Types document for available record types, and the field types used to build the records. The action plugin will return the record_uid upon successful creation.
The Ansible variable keeper_app_owner_public_key is required to create a record. In the client-config.json, the JSON key is appOwnerPublicKey. If your configuration does not contain this key, create a new One-Time Access Token and initialize it.
Example:
The following fields are required.
shared_folder_uid- The Shared Folder UID from the vault. The record will be created within this folder.record_type- The type of record. This will included all the default record types. If thekeeper_record_typesis set, those record types can be used.title- The title of record
The following fields are optional.
generate_password- If set to true, any password field where the password has not been set, will be populated with a random generated password.password_complexity- Sets the complexity of the password. All parameters of password_complexity are optional.length- Length of password. Defaults to 64.allow_lowercase- Defaults to True. If set to False, no lowercase letters will be used.allow_uppercase- Defaults to True. If set to False, no uppercase letters will be used.allow_digits- Defaults to True. If set to False, no digits will be used.allow_symbols- Defaults to True. If set to False, no symbols will be used.filter_characters- A list of characters to exclude from the password. This allows to remove characters a services will reject. For example, '%' in SQL. If not set, the password will not be filtered.
notes- Attach a note to the record.
Password generation will use the following symbols: "!@#$%()+;<>=?[]{}^.,
Based on the Record Types, certain fields maybe required. Custom fields are optional. Both fields and custom_fields are an array of values.
fields/custom_fieldstype- Field typelabel- Label to display with the value.value- Field value. Can be a string or dictionary based on field type.
Creating Custom Record Types
To create a record with a particular Custom Record Type, first export the custom record types using Keeper Commander and the record-type-info command. KSM does not sync down the custom type definitions, so this must be added directly to the playbook as a variable.
Keeper Commander will output a JSON Array ("content"). Only the JSON object is required.
Example:
In your Ansible YAML file, add the value of the "content" object to the variable key called keeper_record_types. The variable is an array, and the JSON is to be treated as a string value. The pipe, after the array item, will treat the following JSON as a string. The variable will accept multiple record types.
Example:
To check if this worked, the keeper_info plugin can be used to show which record types are available.
When creating a record of a particular custom type, the Ansible task will reference the record type name in the record_type parameter as seen below:
Plugin: keeper_remove
keeper_removev1.2.1 Released on: 10/27/2023
The keeper_remove plugin will remove a record from the Keeper vault.
Required Attributes
uid- A Keeper Vault record UID.title- Title of a Keeper Vault records.
The attributes uid and title cannot be used at the same time. At least one of them needs to be set.
Optional Attributes
cache- The record cache from thekeeper_cache_recordsaction. The record will not be removed from the cache. The cache will be used for looking up the record title.
Plugin: keeper_password
keeper_passwordThe keeper_password plugin will generate a random password. The action plugin will return the password.
Example:
All parameters are optional. If no parameters are set, the defaults will be used.
length- Length of password. Defaults to 64.allow_lowercase- Defaults to True. If set to False, no lowercase letters will be used.allow_uppercase- Defaults to True. If set to False, no uppercase letters will be used.allow_digits- Defaults to True. If set to False, no digits will be used.allow_symbols- Defaults to True. If set to False, no symbols will be used.filter_characters- A list of characters to exclude from the password. This allows to remove characters a services will reject. For example, '%' in SQL. If not set, the password will not be filtered.
Password generation will use the following symbols: "!@#$%()+;<>=?[]{}^.,
Based of record types, certain fields maybe required. Custom fields are optional. Both fields and custom_field are an array of values.
Plugin: keeper_lookup
keeper_lookupThe keeper_lookup plugin retrieves a field from the Keeper vault record and inserts the value into a text string. Example:
In the example above, the first task the content of a file is created by templating the login name of a user from a Keeper record.
The second task displays as debug the second phone of number from a field with a complex value using the array_index and value_key task attributes. An array_index starts at 0, the next item in the araray will be 1, the next is 2, a so on. The value_key is the name of key in a key/pair dictionary.
Required Attributes
uid- A Keeper Vault record UID.title- Title of a Keeper Vault records.notation- Use Keeper Notation to get the field from a record.
The attributes uids and titles can be used at the same time. At least one of them needs to be set.
Optional Attributes
cache- The record cache. Used for getting multiple records, will not update the cache.field- Update the existing standard Keeper Vault record field.custom_field- Update the existing custom Keeper Vault record field.file- Get the value from the files attach to the Keeper Vault record by file title.allow_array- By default is False. If set to True, an array of values will be returned. This is needed if the field contains multiple values such as Phone numbers. If True,array_indexandvalue_keywill be ignored.array_index- Defaults to 0. If the field value contains multiple values, this attribute will allow you to select which item to return. The first item will have thearray_indexof 0, and the next will be 1, etc.value_key- If the field value is a complex object, this will allow you to select the key of the key/value pair to return.
Important Notes
To avoid leaking secret values when using the lookup plugin, add
'no_log: True'to the task. The stdout information will not be logged if the value is True.If the plugin was installed by Ansible Galaxy the longer name is required for the lookup plugin (i.e. keepersecurity.keeper_secrets_manager.keeper). Listing collections appears not to work with lookup plugins.
To find out what fields and custom fields are available for a specific vault secret, use the Keeper Secrets Manager CLI "
ksm secret get -u XXXX" command. More info here.
Plugin: keeper_init
keeper_initThe keeper_init plugin initialize a configuration from a one time access token. This is similar to the keeper_ansible --keeper_token command. The plugin accepts the following options.
token- The one time access token. It's best to template this value and pass in the value.filename- The configuration file name to generate with config values. If not included, the configuration will not be created.show_config- A flag to indicate if the configuration values should be returned in the task log. By default this isFalse. Only set to True if you are unable to generate the configuration via other methods or do not have access to a generated configuration file. If True, the configuration will be logged. This might not be a problem if running the playbook via the command line, however if running via Ansible Tower to will be log file which is retained.
It's best not to hard code the token into the playbook since it's only good once. The token and the configuration file name can be passed into the playbook using the extra vars.
The above will generate a file similar to the one below. The content of the file can be copied into a configuration file used by ansible, and optionally encrypted by ansible-vault.
Ansible Galaxy Role
If the Keeper Secret Manager plugins were installed via Ansible Galaxy, a role called keeper_init_token was installed to initialize the one-time access token. This role can be used in a playbook.
The role will use the following options set via extra variables.
keeper_token- Required one-time access token.keeper_config_file- Generate a file containing the configuration. If not set, no file will be created.keeper_show_config= Default False. If set to True, it will show the config in the log if verbosity is enabled.
Either keeper_config_file or keeper_show_config should be used, else the token will initialize and you will not be able to view the resulting configuration.
Plugin: keeper_info
The keeper_info action will display information about the Keeper ansible plugin. The results include a list of record types, field types, and versions of Python modules. In order to see the results, the verbosity level needed to be set at 1 or higher.
This can be used to verify custom record types are being picked up by the plugins.
Plugin: keeper_cleanup
keeper_cleanupThe keeper_cleanup plugin is used to clean up any files created by the keeper plugins. This is mainly used to delete a cache file, if you are using it. Disaster Recovey cache files are used when there are network problems as a fall back to get records. If you are running Ansible secret environment, there is no need to remove the Disaster Recovey cache. However this plugin gives you the ability to do so.
Plugin: keeper_redact
keeper_redactThe keeper_redact stdout callback plugin is used to redact secrets from the standard out logs. This will work for the keeper_redact stdout callback plugin is used to redact secrets from the standard out logs. This will work for the keeper_copy and keeper_get plugins. It will not redact secret values for keeper_lookup. For keeper_lookup, use the no_log: True directive.
See How do I keep secrets data in my playbook? Using no_log can hide all logging from a task. This plugin is for when you just want secrets returned by the Keeper Secrets Manager plugins to be hidden/redacted.
The keeper_redact plugin will not work with Ansible Tower since it had its own stdout callback plugin to stream the log as the job runs. Highly recommend using the no_log option when you do not wish show information in the log.
To use the keeper_redact plugin, enable it in your ansible.cfg.
For example, the following task would return all the phone numbers in the custom field MyPhoneNumbers and place them into the variable phone_numbers.
If the playbook was run with any verbosity, the values being placed into the variable would be displayed. This would leak the secrets to the log. If the keeper_redact stdout callback plugin is enabled, the values in the log would be redacted.
Ansible Vault Password Retrieval
You can use the Keeper Secret Manager CLI ("ksm") to provide the decryption password for your Ansible vaults. This is done using the ANSIBLE_VAULT_PASSWORD_FILE environment variable or the vault_password_file in the ansible.cfg field to specify an executable file that will return a password.
A executable shell script can be created that returns the password using the "ksm" secret notation (learn more about ksm secret notation). For example, the below script will output a specific secret password for the given Record UID:
Replace XXXX with the Vault Record UID. Running this script simply outputs the secret password.
To override the environmental variable "ANSIBLE_VAULT_PASSWORD_FILE", execute the following, replacing /path/to/script with the location of the above script.
Now, when Ansible needs to decrypt any vaults used by playbook_with_vault.yml, it will execute that shell script. The shell script will retrieve the password from the Keeper Vault.
Logging
By default, the Ansible plugins will only display errors. If you use the Ansible verbosity level, different SDK logging will be displayed. An Ansible verbosity level of -v will display any SDK messages INFO and higher, while a verbosity level of -vvv will display any SDK messages DEBUG and higher.
Troubleshooting
__NSPlaceholderDate in progress in another thread when fork() called error.
This appears to be specific to Ansible running on MacOS. While running a playbook you may get the following error:
This is known problem with Ansible. This can be fixed with the following environmental variable.
Missing Configuration file
Ansible Tower
A collection of Ansible plugins that interact with your Keeper account and can be used in your Ansible Tower automations.
Features
Store Secrets Manager configurations securely in Ansible Tower
Use Ansible Tower to manager and launch Ansible projects utilizing the Secrets Manager Ansible plugin which features:
Retrieving secrets from the Keeper vault to use in Ansible Playbooks
Updating the value of secrets in the Keeper Vault from Ansible
Copying files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
KSM Configuration
The first step in using Ansible Tower with Keeper Secrets Manager is to get and initialize a Base64 configuration. The Secret Manager Configuration document will explain how to get a configuration using the Keeper Secret Manager CLI or Commander CLI.
Using Commander CLI, add a new device can generate a Base64 configuration without using a one time access token.
The Keeper Secrets Manager CLI requires a one-time access token. This can be obtained from the Web Vault by adding a new device to an application.
Another way using the keeper_init_token role included in the Keeper Secrets Manager collection, which can used after Ansible Tower is setup. An example will appear at the end of this document.
The Base64 configuration can be added to the inventories, hosts, or templates variables sections. It can also be added to the playbook repository as an Ansible secret. The variable name is keeper_config.
Vault Credential
With the Base64 KSM configuration we need to create a vault credential. Under the Resources menu, select Credentials and click Add.
Give your Vault Credential a name, select Vault from the Credential Type drop-down, type in the password that was used to encrypt the secrets.yml file into the Vault Password field, then click Save.
The credential will be used when the Template is setup.
Execution Environment
To use the Keeper Secrets Manager plugins in Ansible Tower an Execution Environment containing the Keeper Secrets Manager SDK is required. This SDK is included in the Docker image keeper/keeper-secrets-manager-tower-ee. In your instance of Ansible Tower, select Execution Environment in the Administration menu, then click Add.
The Image value is docker.io/keeper/keeper-secrets-manager-tower-ee:latest or docker.io/keeper/keeper-secrets-manager-tower-ee:<tag> if there is a specific tag version.
The value for Pull should be set to Always pull container before running is you are using the latest tag. If you pin the tag to a specific tag version of keeper/keeper-secrets-manager-tower-ee then set the value to Only pull the image if not present before running.
Projects
Playbook Repository
Using the Keeper Security Manager collection from Ansible Galaxy
To use the Keeper Secrets Manager plugins in your projects, create a collections directory in your source repository, if one does not already exists. Then create, or add to, the file requirements.yml the following value.
Storing the KSM Configuration
The Base64 KSM configuration can be stored in numerous places inside of Ansible Tower like in the inventories, hosts, and templates. The configuration is encrypted when stored in these locations.
For this project, the KSM configuration will be stored as an encrypted secret in the source repository. Add a YAML file called secrets.yml in a directory called defaults located in the root directory of the repository.
In this file add a key called keeper_config with the Base64 configuration as it's value.
Then encrypt the secrets.yml file using ansible-vault.
Remember the password, it will be needed in Tower for a Vault Credential.
At this point, if you look at your secrets.yml file, it should be encrypted.
Playbook
The directory structure should look like the following.
For our playbooks, the Keeper Secrets Manager collection is added to the playbook collections. The first task is to include the secrets.yml using the built-in action include_vars. That task also includes no_log: True to prevent the KSM configuration from being logged. This task needs to be performed before any of the plugins from the Keeper Secrets Manager collection.
Ansible Tower uses it's own stdout callback plugin. So using keeper_redact will not work. It's important to add no_log: True to tasks that may display secrets in the log.
Project
Once you have added the collection to your source repository, a new Project can be created.
Make sure to select the Execution Environment that you create that uses the keeper/keeper-secrets-manager-tower-ee image.
In the example above, the source repository was Git with the appropriate details. Your company may use a different source control.
After it is saved, sync the playbooks to your Ansible Tower instance.
Template
In your instance of Ansible Tower, select Templates in the Resources menu, then click Add.
For Projects select the project that was just created that contain the playbooks. For Execution Environment select the execution environment what contains the Keeper Secrets Manager Tower EE docker image. For Playbook select a playbook from your source repository.
For Credentials select the Vault credential that will be used to decrypt the secrets.yml file in the Project's source repository. You can also select the credential to use for connection to your inventory servers.
Finish by clicking the Save button at the bottom of the page.
Launching a Template
The last step is to launch a template to create a job.
The include_vars task will import the KSM Base64 Configuration and decrypt it. The no_log: True will hide the configuration from the log. If it is not included, the configuration will be logged and viewable by anyone who has access to Ansible Tower.
With the configuration now in the available variables, the keeper_copy action can retrieve the public and private SSH key from the Keeper Vault and copy them into location on the remote machine.
See the Ansible Plugin documentation for all the Secrets Manager capabilities available to Ansible
AWS CLI Credential Process
Protect your AWS Access Keys with Keeper Secrets Manager
About
By default, the AWS CLI uses credentials stored in plaintext in ~/.aws/credentials. With this credential process, you can now use the Keeper Vault to store your AWS credentials, removing the need to have them on disk.
Instead, AWS will use this executable to securely fetch your AWS credential from your Vault using the Keeper Secrets Manager (KSM).
Features
Use a vaulted AWS Access Key to authenticate to the AWS CLI.
Prerequisites
In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with an Access Key shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
This integration only accepts JSON format configurations
The AWS CLI v2 installed
Setup
Vault
The first step in the setup of the integration is to add you AWS Access Key ID and your Secret Access Key to a record in your Vault. There is no built-in record type for this kind of secret; however, you can create a custom record for this purpose alone.
In order to create new custom Record Types, the user must be in an Administrative role with the "Manage Record Types in Vault" permission activated.
Note: Field names are case-sensitive.
Once you have created your custom field, you can now use it to create a record for your AWS Access Key. This record should be stored in a shared folder that your KSM application has permission to access.
Once safely stored, you can delete the Access Key credentials from your AWS credential file.
KSM
The integration expects a KSM Application Configuration file at either .config/keeper/aws-credential-process.json or aws-credential-process.json relative to the user's home directory. It must have access to a Shared Folder containing the required AWS Access key.
For help in obtaining a KSM configuration in JSON format, follow these instructions.
After creating a new device get corresponding config.json and copy it into user's home folder as aws-credential-process.json
AWS Config
Download the latest version of the keeper-aws-credential-process executable from the GitHub releases page and store that in a convenient location.
Now in your AWS configuration file, which is usually located at ~/.aws/config, add the following line to any profile you are using via the CLI.
Make sure there's no residual aws cli configuration left on the machine which may be picked up automatically or on credential process misconfiguration.
Usage
Once configured as above, the AWS CLI will automatically fetch your authentication credential from the Keeper Vault. You can test that it works by using any CLI command in which you have an appropriate IAM role for, such as:
If the command completes without error, congratulations, you are now fully set up.
Feature Request / Report an Issue
This Credential Process is open source and can be found on GitHub. If you need to report a bug or would like to request a feature to support more authentication use cases, please create a GitHub issue.
AWS Secrets Manager
Sync secrets from the Keeper Vault with AWS Secrets Manager
About
The Keeper Secrets Manager CLI tool sync command allows you to push secrets from the Keeper Vault to a target AWS Secrets Manager account, overwriting the existing values in the target location. This allows the Keeper Vault to be the single source of truth for any services or scripts in AWS that utilize AWS Secrets Manager.
Features
Use secrets from the Keeper Vault as the source of truth for AWS Secrets Manager
Seamlessly start using secrets from the Keeper Vault with your existing AWS scripts and services
Prerequisites
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper subscription
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An AWS account with AWS Secrets Manager, and the ability to create IAM security credentials
Setup
1. Configure Keeper Secrets Manager CLI
You can skip this step if the KSM CLI is already configured on your machine.
To configure the KSM CLI tool, a profile needs to be created with the Keeper Secrets Manager One Time Access Token.
The simplest way to do this is to initialize the default profile with the following command:
ksm profile init <TOKEN>
For information on creating multiple profiles and other options, see the profile documentation
2. Set AWS Permissions
To use the KSM sync to AWS, AWS Secrets Manager requires standard IAM security credentials with SecretsManagerReadWrite enabled for the entire vault or on individual keys to sync.
arn:aws:iam::aws:policy/SecretsManagerReadWrite
See the Amazon instructions for creating Access Keys:
3. Create AWS Credentials Record
The KSM CLI needs the credentials for the AWS account to set secrets. These credentials are stored in a Keeper record which the CLI tool can access using Keeper Secrets Manager.
Record fields with the following labels are required on the credentials record:
"AWS Access Key ID"
"AWS Secret Access Key"
"AWS Region Name"
(Method 1) Create an AWS Credentials Custom Record Type
A custom record type can be created with the required fields, which makes it easy and clean to create a record.
To create a custom record type, go to the "Custom Record Types" tab in the Keeper Vault and hit "Create Type". Create a new record type with hidden fields that have the correct field label, then click "Publish" to create the new record type.
Then simply create a new record of the AWS Credentials type and enter the details into the corresponding fields.
Make sure this new record is moved to a Shared Folder that is associated with your Secrets Manager application.
(Method 2) Add Custom Fields
To create a credentials record without creating a new record type, the required fields can be added as custom fields to a standard record.
Create a new record of any type, then add Custom Fields of the 'Hidden Field' type for each required AWS field. Click "Edit Label" to change the labels to the corresponding field name.
Any record type will work, but the "File Attachment" standard record type has no fields and will be cleaner looking when custom fields are added
Then fill in each custom field and hit "Save" to save the record.
4. Create Value Mappings
The KSM CLI sync command identifies which values to set using mappings that are defined on the command call. For each mapping passed to the command, a value with the given name will be populated with the given value from the Keeper Vault.
These mappings follow this format:
--map "VALUE KEY" "KEEPER NOTATION"
VALUE KEY is the key name that the value will be assigned in AWS Secrets Manager
KEEPER NOTATION is a Keeper notation query of a value from a keeper record to set to the key
Keeper notation is a query notation used by Keeper Secrets Manager to identify specific record values. The notation follows the general format of: UID/[field|custom_field]/fieldname
for example: ae3d[...]d22e/field/password
See the Keeper Notation documentation for more information
Note that full record UIDs are not given in these examples
Full Mapping Example:
--map "MySQL_PWD" "jd3[...]i-fd/field/password"
Multiple mappings can be added to a single sync command
--map "MySQL_PWD" "jd3[...]i-fd/field/password" --map "MySQL_Login" "jd3[...]i-fd/field/login"
Ensure that the records referenced by the Keeper Notation queries are in a shared folder that is shared with your Secrets Manager application
KSM sync is now ready to run
Run Sync
To run the sync, use the KSM CLI sync command with the credentials record and value mapping.
1. Construct the Command
Put together the KSM sync command with the AWS type. The format looks like the following:
ksm sync --type aws --credentials [UID] --map [...] --map [...]
2. Run a Dry-Run
The sync command supports running a dry-run which will identify all changes that will be made to your AWS Secrets Manager values without actually pushing the values or making changes. Use this to make sure your mapping queries are constructed properly.
ksm sync --type aws --credentials [UID] --map [...] --map [...] --dry-run
3. Run the Sync
When ready, run the sync command without the dry-run option. This will push values from your Keeper Vault to AWS Secrets Manager
TIP: you can use -m as short hand for --map
ksm sync --type aws --credentials [UID] -m [...] -m [...]
AWS KMS
Protect Secrets Manager connection details with AWS KMS
Keeper Secrets Manager integrates with AWS KMS in order to provide protection for Keeper Secrets Manager configuration files. With this integration, you can protect connection details on your machine while taking advantage of Keeper's zero-knowledge encryption of all your secret credentials.
Features
Encrypt and Decrypt your Keeper Secrets Manager configuration files with AWS KMS
Protect against unauthorized access to your Secrets Manager connections
Requires only minor changes to code for immediate protection. Works with all Keeper Secrets Manager Python SDK functionality
Prerequisites
Supports the Python Secrets Manager SDK
Requires boto3 package
Setup
1. Install KSM Storage Module
The Secrets Manager HSM modules are located in the Keeper Secrets Manager storage module which can be installed using pip
2. Install boto3
boto3 is a prerequisite for the AWS KSM integration. Install it to your machine using pip.
3. Configure AWS Connection
By default the boto3 library will utilize the default connection session setup with the AWS CLI with the aws configure command. If you would like to specify the connection details, the two configuration files located at ~/.aws/config and ~/.aws/credentials can be manually edited.
See the AWS documentation for more information on setting up an AWS session: https://docs.aws.amazon.com/cli/latest/reference/configure/
Alternatively, configuration variables can be provided explicitly as an access key using the AwsSessionConfig data class and providing aws_access_key_id , aws_secret_access_key and aws_session_token variables.
You will need an AWS Access Key to use the AWS KMS integration.
For more information on AWS Access Keys see the AWS documentation: https://aws.amazon.com/premiumsupport/knowledge-center/create-access-key/
4. Add AWS KMS Storage to Your Code
Now that the AWS connection has been configured, you need to tell the Secrets Manager SDK to utilize the KMS as storage.
To do this, use AwsKmsKeyvalueStorage as your Secrets Manager storage in the SecretsManager constructor.
The storage will require an AWS Key ID, as well as the name of the Secrets Manager configuration file which will be encrypted by AWS KMS.
You're ready to use the KSM integration 👍
Using the AWS KMS Integration
Once setup, the Secrets Manager AWS KMS integration supports all Secrets Manager Python SDK functionality. Your code will need to be able to access the AWS KMS APIs in order to manage the decryption of the configuration file when run.
Check out the KSM SDKs documentation for more examples and functionality
Azure DevOps Extension
Keeper Secrets Manager integration into Azure DevOps for dynamic secrets retrieval
Features
Retrieve secrets from the Keeper Vault from an Azure DevOps pipeline
Set secret credentials as build arguments or environment variables
Copy secure files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Azure DevOps integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The Azure DevOps integration accepts JSON and Base64 format configurations
Installation
Install the Keeper Secrets Manager Extension
Download from the Visual Studio Marketplace here or search for "Keeper Secrets Manager"
Enable the extension for your Azure organization by selecting an organization and clicking "Download".
Access Secrets From Azure Pipelines
In order to access secrets from the Keeper Vault, add a task to your Azure Pipelines YAML configuration file. Then query your records for the desired fields.
Secret queries use Keeper Notation and have the following syntax KeeperNotation > destination where the destination location is defined by its prefix var:, out: or file: see the examples below.
Since v1.0.4 extension allows use of a search by title syntax, where UID portion could be replaced with the record title and must be escaped according to Keeper Notation rules then it must follow YAML format specifications for escaping special characters.
Create a Keeper Secrets Manager Task
Keeper Secrets Manager tasks look like this:
In this example, 6ya_fdc6XTsZ7i4x9Jcodg is the Record UID. In order to add a task, you can create a task using a Task Form, or add it manually.
Add Task Using a Task Form
Search the Tasks menu for "Keeper Secrets Manager" to open the task form.
To fill in the task form and create a Keeper Secrets Manager Task, you will need:
A Keeper Secrets Manager Configuration
The Azure DevOps Extension accepts JSON and base64 configurations.
One or more Secret queries (See query syntax below)
While it is possible to simply copy a Keeper Secrets Manager configuration into the pipeline, we recommend keeping the Secrets Manager configuration in an Azure Key Vault that is accessible to your Azure Pipeline. See Microsoft's documentation to learn more about Azure Key Vault.
Submit the form to add a task to your configuration automatically.
Manually add Task
To add a task manually to the pipeline configuration, follow this syntax:
Keeper Secret Queries
Queries for secrets in the Keeper Vault use the following syntax:
Get a Standard Field Value
Syntax
Example
Get a Custom Field Value
Syntax
Example
Get a Two-Factor Code
Syntax
[UID]/field/oneTimeCode > [VARIABLE NAME]
Example
Get a File
Syntax
Example
Variable Types
When saving a secret from the Keeper vault as a variable on your Pipeline, there are a few options for how to set those variables, depending on your needs.
OUT
out (default) sets the secret to a variable which is accessible in any jobs in the pipeline. If you do not define a variable type, out will be used by default.
VAR
var sets the secret to a local variable, usable within the same pipeline job.
FILE
file sets the contents to a file. Usually used to access certificates and other files from the Keeper Vault.
ENVIRONMENT VARIABLE
env set the secret as an environment variable which the build machine can access.
To do this, you first need to set the secret to a pipeline variable, then set it as an environment variable in the bash task.
Example Usage
Get Secrets From Keeper
This example pipeline sets secrets from the Keeper Vault to variables and echoes them. Note that echoed passwords are masked.
Use Secrets in Multiple Jobs
This example gets passwords and files from Keeper, and utilizes those passwords and files in another job.
Azure Key Vault
Sync secrets from the Keeper Vault with Azure Key Vault
About
The Keeper Secrets Manager CLI tool sync command allows you to push secrets from the Keeper Vault to a target Azure Key Vault account, overwriting the existing values in the target location. This allows the Keeper Vault to be the single source of truth for any services or scripts in Azure which utilize the Key Vault.
Features
Use secrets from the Keeper Vault as the source of truth for Azure Key Vault
Seamlessly start using secrets from the Keeper Vault with your existing Azure scripts and services
Prerequisites
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An Azure account with Key Vault, and the ability to create security principals
Setup
1. Configure Keeper Secrets Manager CLI
You can skip this step if the KSM CLI is already configured on your machine.
To configure the KSM CLI tool, a profile needs to be created with the Keeper Secrets Manager One Time Access Token.
The simplest way to do this is to initialize the default profile with the following command:
ksm profile init <TOKEN>
For information on creating multiple profiles and other options, see the profile documentation
2. Set Azure Permissions
To use KSM sync with Azure, the Azure account needs to be configured to accept the connection. The Azure account with Key vault needs to enable a service principal with authorization to perform key operations in the Key Vault.
Follow the Microsoft guide for setting up a service principal:
3. Create Azure Credentials Record
The KSM CLI needs the credentials for the Azure account to set secrets. These credentials are stored in a Keeper record which the CLI tool can access using Keeper Secrets Manager.
Record fields with the following labels are required on the credentials record:
"Azure Tenant ID"
"Azure Client ID"
"Azure Client Secret"
"Azure Key Vault Name"
When retrieving the Client secret from Azure app registration, make sure to copy the Value (not Secret ID) into "Azure Client Secret" field.
(Method 1) Create an Azure Credentials Custom Record Type
A custom record type can be created with the required fields, which makes it easy and clean to create a record.
To create a custom record type, go to the "Custom Record Types" tab in the Keeper Vault and hit "Create Type". Create a new record type with hidden fields that have the correct field label, then click "Publish" to create the new record type.
Then simply create a new record of the Azure Credentials type and enter the details into the corresponding fields.
Make sure this new record is in a shared folder that is shared to your Secrets Manager application.
(Method 2) Add Custom Fields
To create a credentials record without creating a new record type, the required fields can be added as custom fields to a standard record.
Create a new record of any type, then add Custom Fields of the 'Hidden Field' type for each required Azure field. Click "Edit Label" to change the labels to the corresponding field name.
Any record type will work, but the "File Attachment" standard record type has no fields and will be cleaner looking when custom fields are added
Then fill in each custom field and hit "Save" to save the record.
4. Create Value Mappings
The KSM CLI sync command identifies which values to set using mappings that are defined on the command call. For each mapping passed to the command, a value with the given name will be populated with the given value from the Keeper Vault.
These mappings follow this format:
--map "VALUE KEY" "KEEPER NOTATION"
VALUE KEY is the key name that the value will be assigned in Azure Key Vault
KEEPER NOTATION is a Keeper notation query of a value from a keeper record to set to the key
Keeper notation is a query notation used by Keeper Secrets Manager to identify specific record values. The notation follows the general format of: UID/[field|custom_field]/fieldname
for example: ae3d[...]d22e/field/password
See the Keeper Notation documentation for more information
Note that full record UIDs are not given in these examples
Full Mapping Example:
--map "MySQL_PWD" "jd3[...]i-fd/field/password"
Multiple mappings can be added to a single sync command
--map "MySQL_PWD" "jd3[...]i-fd/field/password" --map "MySQL_Login" "jd3[...]i-fd/field/login"
Ensure that the records referenced by the Keeper Notation queries are in a shared folder that is shared with your Secrets Manager application
KSM sync is now ready to run
Run Sync
To run the sync, use the KSM CLI sync command with the credentials record and value mapping
1. Construct the Command
Put together the KSM sync command with the Azure type. The format looks like the following:
ksm sync --type azure --credentials [UID] --map [...] --map [...]
2. Run a Dry-Run
The sync command supports running a dry-run which will identify all changes that will be made to your Azure Key Vault values without actually pushing the values or making changes. Use this to make sure your mapping queries are constructed properly.
ksm sync --type azure --credentials [UID] --map [...] --map [...] --dry-run
3. Run the Sync
When ready, run the sync command without the dry-run option. This will push values from your Keeper Vault to Azure Key Vault
TIP: you can use -m as short hand for --map
ksm sync --type azure --credentials [UID] -m [...] -m [...]
Bitbucket Plugin
Keeper Secrets Manager integration into Bitbucket for dynamic secrets retrieval
Features
Retrieve secrets from the Keeper Vault within BitBucket Pipelines
Set secret credentials as build arguments or environment variables in BitBucket Pipeline scripts
Copy secure files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager BitBucket integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The BitBucket integration accepts JSON and Base64 format configurations
Setup
Getting a configuration
Using Keeper Commander, add a new client to an application and initialize the configuration to a Base64 string. This will be the long text hash that appears after the "Initialized Config:" label.
That value can be added to your BitBucket Repository variables, under Repository settings menu, as a secure secret with the name KSM_CONFIG. This will allo the configuration to be available to the Keeper Secrets Manager pipe as a variable.
Adding to bitbucket-pipeline.yml
Pipe Integration
The name of the pipe integration is the following.
The pipe requires you to choose a git tag for the version. The README.md will always have the latest tag in the YAML Definition.
Variables
Required
KSM_CONFIG - The Keeer Secrets Mananger pipe requires configuration information. This can be stored in the Repository variables and pulled into a variable using "${KSM_CONFIG}"
SECRETS - The secrets are a new line separted list of Keeper Notation and destinations. The notation and desitnation are separated by the '>' character.
Optional
SCRIPT_FILE - The script file is an application, or shell script, that you wish to run inside of the pipe. The script will be able to access the secrets.
SCRIPT_TEXT - The script text allows you to hardcode a script inside of the bitbucket-pipeline.yml. It will be used if a SCRIPT_FILE does not exist. If used, you will need to escape any shell related special characters.
SECRETS_FILE - If set, secrets that were to be place into environmental varaibles will also be placed into a file. The format of the file depends on the SECRET_FILE_TYPE.
SECRETS_FILE_TYPE - If a SECRET_FILE is used, this variable will determine it's format. Valid formats are 'json', 'export', 'setenv', and 'set'. The default is 'json'
SHOW_OUTPUT - A boolean flag to show the output from the SCRIPT_FILE or SCRIPT_TEXT. The REDACT variable will determine if you will be able to see your secrets in the ouput. By default, this flag is True.
SAVE_OUTPUT_FILE - If set, the output from the SCRIPT_FILE or SCRIPT_TEXT will be saved to a file.
REDACT - If True, any secret displayed from the SCRIPT_FILE or SCRIPT_TEXT will be replaced with '****'. By default, this flag is True. This does not redact output saved to a file.
REMOVE_FILES - If True, when the pipe exits it will delete any files it created. Those files will not be available outside of the pipe unless the value is set to False. By default, this is True.
CLEANUP_FILE - The name of a shell script that will remove any files created inside of the pipe. While the build workspace is removed when the build finishes, this shell file can be run to make sure the files are deleted. If not set, no clean up file will be created.
DEBUG - Enable debug message inside of the pipe. By default, this is False.
Retrieving Secrets
The SECRETS variable in the YAML contains a list of Keeper Notation and where the value should be stored. Secrets can be stored as an environmental variable or in a file.
The default destination for a variable is a environmental variable. The prefix env: can be added to the front of the environmental variable name, but is not required.
The environmental variable name must be a valid Unix environmental variable name
Saving secrets to an environment variable
The example below will take the login secret and place them into environmental variables. Both lines do the same, one without the env: prefix and one with.
In the example, 1adh_WZxtbbHWqf6IALMVg is a record UID.
Saving secrets to a file
If the secret is binary data it is highly recommended not to store the secret in an environmental variable due to encoding issues. Use the file: destination instead.
If the variable REMOVE_FILES is True, the file will be removed when the pipe exits. Set this variable to False if you wish to use the files outside of the pipe.
Examples
Example 1 - Docker Build
This example will create a Tomcat server Docker image that contains a custom server.xml config and keystore containing the SSL certs. The server.xml and keystore are stored in the Keeper Vault.
The first step is to create a repo in BitBucket, then add a Dockerfile. This Dockerfile will add two files created by the Keeper Secrets Manager pipe to an official Tomcat Docker image.
Next a configuration is needed for the Keeper Secrets Manager pipe. This can be created using Keeper Commander and initializing the config as Base64.
For more options creating a configuration, see the configuration documentation
The Initialized Config: Base64 string needs to be cut-n-pasted into your Repository variables. In this example the name of the variable is KSM_CONFIG. A private Docker Hub username and password are also added to the Repository variables.
Next a bitbucket-pipelines.yml file needs to be added to the repository.
The above is used to build a Docker image and push it to your Docker Hub account. The first step will use the Keeper Secrets Manager pipe to retrieve the two files and place them into the work directory.
The REMOVE_FILES variable is set to False since we don't want to delete them after the pipe has finished.
The CLEANUP_FILE variable is set to ksm_cleanup.sh which will create a script that will remove the two files when we are done.
When we build the Dockerfile, it will add the two files into the correct locations inside the image. When done it will push the image to the Docker Hub account.
The last part is running the ksm_cleanup.sh script that was set by the CLEANUP_FILE variable. This will make sure the two files we created are deleted. BitBucket Pipeline does delete the work space when it is done, however this guarantees the files are deleted.
Example 2 - Using Keeper Secrets Manager pipe with other pipes.
This example will retrieve secrets that are used as variables for another pipe. The other pipe is the AWS S3 Deploy pipe which will copy a local directory into a S3 bucket.
In the Keeper Vault, a record was created that contains our AWS credentials and information about the S3 bucket.
The first step is to create a repo in BitBucket, and then store the Keeper Secrets Manager pipe configuration in the Repository variables. This can be created using Keeper Commander and initializing the config as Base64.
For more options creating a configuration, see the configuration documentation
The Initialized Config: Base64 string needs to be cut-n-pasted into your Repository variables. In this example the name of the variable is KSM_CONFIG.
Next a bitbucket-pipelines.yml file needs to be added to the repository.
The bitbucket-pipelines.yml contains the Keeper Secrets Manager pipe which will retrieve our AWS credential from a record and place them into environment variables. It will also get a PNG image and write it into a directory called to_s3. The pipe will create a secrets file called secrets.env.
The SECRETS_FILE_TYPE is export which will allow the contents to be sourced and the secret values placed into environment.
Next the secrets file is sourced. This allows other pipes, and applications, access to the secrets as environmental variables.
The last step is using the aws-s3-deploy pipe to copy the image to the S3 bucket. The variables for the aws-s3-deploy pipe are set using the environmental variables provided by the Keeper Secrets Manager pipe's secret file.
Docker Image
Using environmental variable substitution with containerized environments
Docker Secrets Management
Features
Pass secret credentials from the Keeper Vault to Docker images
Build Docker Images with secret credentials from the Keeper Vault using build arguments
Copy files from the Keeper vault into Docker containers
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Docker Image b Actions integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
The Keeper Secrets Manager (KSM) CLI Tool
See instructions on setting up the KSM CLI here
About
The Secrets Manager CLI can be used to pull secrets from a Docker image at runtime, or it can be used by building it into the docker image. Several use cases are described in this document.
Example 1: Build an Image with Secrets using BuildKit
Secrets from the Keeper Vault can be built into a Docker container using Docker BuildKit. As of Docker 18.09 or later, image building supports the ability to pass secrets in via a mounted file system. As a simple example demonstrating this capability, we will be creating a user account in the destination image with a username and password from Keeper Secrets Manager.
Step 1: Set Environmental Variables with Keeper notation for the secrets that are needed. For more notation examples click here.
Step 2: Using the ksm exec command, the Docker build is created with the 2 secrets (login and password). The --secret parameters will pull values from the environmental variables that have been substituted with Keeper secrets.
Step 3: In the dockerfile, we will create a linux user account using useradd and then set the password with chpasswd. The Docker file is below:
In this example, each secret is mounted as a file. The 'dst' value specifies where you want to temporarily store the secret. Once the RUN command is finished, the temporary file will be removed and unmounted. You can either pass the file name as an argument or in this case we are using cat $(/path/to/secret) to read the file contents into a variable.
Example 2: Build an Image with Secrets using Build Arguments
Similar to example 1, you can pass in secrets via the --build-arg. This example will also demonstrate the ability of using secrets in a Docker build process.
Step 1: Set Environmental Variables with Keeper notation for the secrets that are needed. For more notation examples click here.
Step 2: Using the ksm exec command, the Docker build is created with the 2 secrets (login and password). The flag --inline processes the replacement of secrets. For example:
Step 3: In the dockerfile, we will create a linux user account using useradd and then set the password with chpasswd. The Docker file is below:
To prevent secrets being sent to stdout from the printenv command, use the --null option to remove the line feed.
Example 3: Using docker-compose to Build an Image with Secrets
In this example, we will use docker-compose to build an image. Docker-compose cannot populate build args from environment variables. To replace notation with secret values, the build args need to be set via the command line. Since the notation will be on the command line, the --inline replacement flag needs to be set.
Step 1: Create a simple docker-compose.yaml file:
Step 2: Using the ksm exec command, the Docker build is created with the 2 secrets (login and password). The flag --inline processes the replacement of secrets. For example:
Step 3: In the dockerfile, we will create a linux user account using useradd and then set the password with chpasswd. The Docker file is below:
To prevent secrets being sent to stdout from the printenv command, use the --null option to remove the line feed.
Example 4: Copy files from vault to Docker Image
In this real world example, we copy an SSL certificate and passphrase from the Keeper Vault to a Tomcat container.
By default, the official Tomcat docker contains a default server configuration that does not have SSL enabled. We are going build a custom image that installs our server.xml, copies over the keystore file, and enables SSL. The server.xml file also contains the secret passphrase for the keystore file.
Step 1: Create a Keeper Secret Record
In the Keeper Vault, create a secret record that contains 2 file attachments: server.xml and localhost-rsa.jks as seen below:
Make note of the Record UID in the information dialog which will be used in the dockerfile. Click the Record UID to copy to your clipboard.
Step 2: Create the dockerfile
The below dockerfile example copies the server.xml and keystore files from the vault into the Tomcat folder.
Note that in this use case, ksm is no longer needed after the build, so it is deleted.
Step 3: Create a shell script to execute the docker build
To execute the docker build the below script will pass in the Secrets Manager device configuration and Record UID that contains the secret files.
When the docker image is built, it will be fully configured with SSL, keystore file and passphrase that are managed by the Keeper Vault. 😃😃😃
Integration with Docker Compose
Keeper Secrets Manager supports direct integration with Docker Compose using the KSM Writer Docker image.
Learn more about the KSM Writer Docker image here.
Contribute to the Docker Image Examples
If you have some great examples to contribute to this page, please ping us on Slack or email sm@keepersecurity.com.
Docker Runtime
Retrieve secrets from Keeper Secrets Manager at Docker runtime
Features
Dynamically retrieve secrets from the Keeper Vault when Docker containers execute
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Docker Runtime integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
The Keeper Secrets Manager (KSM) CLI Tool
See instructions on setting up the KSM CLI here
About
Keeper Secrets Manager integrates with the Docker Runtime so that you can dynamically retrieve a secret from the vault when the container executes.
The ksm command is used to set environment variables when the container is started instead of hard-coding them into a deployment script. A real world example of this implementation is demonstrated below.
Example: Provision MySQL network user account
The official MySQL docker allows a user to set the MySQL root password and create a network accessible user via environment variables. The MySQL instance is then provisioned when a container is run.
The official MySQL dockerfile is below:
In the standard implementation, the ENTRYPOINT does the provisioning of the container and will use environmental variables that are passed in to set up MYSQL. The environmental variables referenced are the following:
MYSQL_ROOT_PASSWORD
MYSQL_USER
MYSQL_PASSWORD
MYSQL_DATABASE
The below steps will show how to initialize the MySQL database with secrets that are stored in the Keeper Vault.
Step 1: Create 2 Vault Records with Secrets
Create two records in the Vault that are managed by the Secrets Manager application. One record contains the root password. The other record contains the regular user, password and database values.
Make sure to copy the Record UID that appears in the vault records. These are used in Step 3 below when referencing the vault secrets.
Step 2: Create dockerfile that builds on the default MySQL dockerfile
We'll create a dockerfile that installs Keeper Secrets Manager CLI (ksm) and then wraps the ENTRYPOINT with ksm exec
In the below dockerfile, the 4 environment variables are replaced using Keeper Notation. We are also passing in the Secrets Manager profile that points to the vault where the secrets are stored.
Step 3: Create a shell script to execute the docker build
To execute the docker build, the below script will pass in the Secrets Manager device configuration, root user Record UID and network user Record UID from the vault that contains the secrets.
Example: Using KSM CLI Docker Image
The KSM CLI Docker includes a volume mount to both GLIBC (most Linux distributions) and MUSL (Alpine Linux) CLI binaries. The volume is /cli. This directory can be mounted into another container using the volumes_from in docker-compose or -v from command line docker. The ksm executables exists in directory based on the version of C library your Linux distribution is using.
/cli/glibc/ksm- For standard GLIBC distributions like Ubuntu, Debian, Fedora, and CentOS./cli/musl/ksm- For Alpine Linux.
For example, the following is simple framework showing how to access the CLI binary.
The init service will load the CLI docker. The container will start, display a CLI splash screen, and then will exit. Even though the container has stopped, the /cli volume is still accessible from other containers.
The main service will mount the CLI docker's volume under the directory /cli using volumes_from. The command is overridden to run the GLIBC version of the KSM CLI. The command is using the exec function of the CLI. That will replace environment variables environment variable, that use the Keeper Notation, with a secret value. The exec command, of the CLI, is running the printenv application. That will print the environment variable, MY_LOGIN, that has been set to Keeper Notation, and has had its value replaced with a secret by the exec command.
Example: Using KSM CLI Docker With Other Vendor Docker Images
Similar to the examples above, the KSM CLI docker can be used to override the entrypoint and command for another vendor's Docker image without creating a custom Docker image.
This example, combines the first two examples.
For this example, it will be assumed the Docker image is being severed by the Docker Hub repository and the images' Dockerfile is stored on GitHub.
Operating System Distribution
The first step is to determine what operating system distribution the vendor's Docker image is built upon. Often this can be determined by the tag name. For example, if the name has "alpine" in the image tag name, you'll know it's the Alpine Linux distribution.
If the image tag name does not indicate the distribution, then on the Docker Hub web page for the image, click on the tag name in the "Supported tags" section. This will display the content of the Dockerfile. The FROM statement will indicate the distribution the vendor has built their image upon. If it is not apparent from the FROM statement, you man check the Dockerfile of the FROM image due to inheritance.
MySQL 8.0.31 doesn't indicate the operating system distribution in the tag name. On the MySQL Docker Hub page, the 8.0.31 tag links to their GitHub repo. From the Dockerfile we can see the distribution is Oracle Linux.
The purpose of checking the distribution is to determine what version of the libc library is being used. Most distributions use GLIBC but some, mainly Alpine Linux, uses MUSL. This is needed to select the correct binary from the KSM CLI Docker image. If you select the wrong one, you will get an error like exec /cli/musl/ksm: no such file or directory or exec /cli/glibc/ksm: no such file or directory. For our example, Oracle Linux is a GLIBC distribution.
Entrypoint and Command
The next step is to determine the vendor's Docker image ENTRYPOINT and CMD. The Dockerfile will list the ENTRYPOINT and/or CMD.
From the MySQL Dockerfile, the ENTRYPOINT is ["docker-entrypoint.sh"] and the CMD is ["mysqld"]. This means the ENTRYPOINT will be prepended to the CMD, so when the container is started docker-entrypoint.sh mysqld will be executed.
docker-compose.yml
docker-compose.ymlThe docker-compose uses two services.
The init service loads the keeper/keeper-secrets-manager-cli Docker image volumes. This image image will start and exit, however the volumes will still be accessible after it exits.
The main service will run after the init service. This is done by using the docker-composes depends_on directive. This service contains environment variables, with notation, that will be replaced by the KSM CLI exec command and also includes the Base64 encoded configuration needed by the KSM CLI. The MYSQL_ environmental variables are used by the MySQL Docker image to provision the database.
The main services also will mount the volumes from the init service using the volumes_from. The KSM CLI Docker image defined that volumes are exported, and where they are mounted in the main service container. The binaries are mounted in /cli, followed by the libc version, and the ksm binary name.
Since the MySQL image uses the Oracle distribution, a GLIBC distribution, the main service will use the /cli/glibc/ksm binary.
The main service will override the ENTRYPOINT and CMD of the MySQL image. This is done using entrypoint and command. The entrypoint will use the KSM CLI exec command to run the original ENTRYPOINT docker-entrypoint.sh. The command is the same, however it needs to be set in the docker-compose.yml else the service will just exit.
Based on the Docker image you are using, you may need override either ENTRYPOINT or CMD, or both.
Results
When the services are brought up. The init service will run first and then exit with a code 0, which means it exited successfully execute. Then the main services will start up, execute the KSM CLI exec command and run docker-entrypoint.sh with mysqld. At this point the environmental variable have been replaced with secrets, MySQL has been provisioned, and mysqld is running.
Contribute to the Docker Runtime Examples
If you have some great examples to contribute to this page, please ping us on Slack or email sm@keepersecurity.com.
Docker Writer Image
A general purpose docker image to retrieve secrets.
Overview
The Docker Writer Image for KSM is an image that can download secret files and also generate a file containing secrets.
The image can be pulled with the following command:
When run, its parameters are passed in via environmental variables.
The writer is used to copy files from the vault and to create files containing secrets. Due to writing information to disk, there is always risk of exposure. An alternative is the keeper/keeper-secrets-manager-cli image and the exec command.
Parameters
The parameters are handled by passing environment variables into the container.
KSM_CONFIG
A base64 encode configuration file.
SECRETS
A line-feed separated list of Keeper notation and destinations.
SECRETS_FILE
A filename to write the non-file destination secrets.
SECRETS_FILE_TYPE
The format of the secrets file. Valid format are export, setenv, set, and JSON. JSON is the default.
CLEANUP_FILE
If set, all files created will be added to the shell file to be removed when executed. This file can be executed to remove the files created.
Secrets List
The SECRETS are a list of Keeper Notation and destinations. The values are separated by line feeds. For example:
Each line is "Keeper Notation > destination". The destination can be either an environmental variable/JSON key or a file path and name. If a file, the path is prefixed with the text file:. It is recommended not to place binary data into an environmental variable due to unknown string encoding.
Secret File Type
The secrets file contains the values of the environmental variable SECRETS. The format of the file is based on the value of SECRETS_FILE_TYPE. The type can be the following values:
json - Values stored in a JSON format.
export - Values stored as export commands commonly used with a BASH shell.
setenv - Values stored as setenv commands commonly used with C shell.
set - Values stored as set commands commonly used with C shell.
The types related to a shell can be sourced to place the secrets into the environment.
Examples
The Docker Writer Image for KSM can be used for many applications. Here are some examples.
Kubernetes
The writer image is best used in an Init Container.
In this container, the writer image is used to save a file and create a secrets file that the main container can access. This can be done by mounting a volume, writing the files, and then having the main container mount the same value. The pod's emptyDir is a good choice.
Docker Compose
By using the depends_on options in the main service, the Docker Writer Image for KSM can be used in the initialization service. In the example below, the Docker Writer pulls secrets from the vault and shares them on a volume mount to the main image.
Normally services start in parallel, however by using the depends_on option the service startup can be controlled. In the above, the main service depends on the init service.
The init service will start, retrieve and save the files into the keys-volume, then exit. By using the condition service_completed_successfully, when the init service successfully exits, it will start the main service. The main service will also mount the keys-volume and use the stored keys.
Docker Command Line
The writer image can be executed in the command line by using docker run.
If SECRETS has multiple secrets, the line-feed character (\n) is hard to represent. The solution is to surround the --env,-e value with $". For example
Between file:my.png and the next record UID, there is a '\n'. If you don't wrap the entire value with $'' the my.png file name will include the escape line feed and the next record UID.
Entrust HSM
Protect Secrets Manager connection details locally with Entrust HSM
Keeper Secrets Manager integrates with Entrust HSM in order to provide protection for Keeper Secrets Manager configuration files. With this integration, you can protect connection details on your machine while taking advantage of Keeper's zero-knowledge encryption of all you secret credentials.
Features
Encrypt and Decrypt your KSM configuration files with Entrust HSM
Protect against unauthorized access to your Secrets Manager connections
Requires only minor change to code for immediate protection. Works with all KSM Python SDK functionality
Prerequisites
Supports the Python Secrets Manager SDK
The Python module needs to be built as a nShield native application
Using Python (v3.8.5) and nfpython modules from SDK ISO image from Entrust nShield software (Security World 12.80 or later)
Virtualenv is recommended
Setup
1. Create and Configure Virtualenv
This step is optional, but recommended for development
Create a virtualenv environment to work in
/opt/nfast/python3/bin/python3 -m venv --copies venv
Activate the virtualenv environment before starting development
. venv/bin/activate
Create a virtualenv environment to work in
c:\Program Files\nCipher\nfast\python3\python --copies -m venv venv
Activate the virtualenv environment before starting development
venv\Scripts\activate.ps1
2. Install KSM Storage and nfpython Modules
The Secrets Manager HSM modules are located in the Keeper Secrets Manager storage module which can be installed using pip
The nfpython package also needs to be installed in order to utilize the Entrust HSM. This package is installed as part of the nShield package with your Entrust installation.
In Linux:
In Windows:
3. Add Entrust HSM Storage to Your Code
Use the HsmNfastKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor.
The HsmNfastKeyValueStorage requires the method and identity ("simple" and "ksmkey" respectively in this example).
You're all set and ready to use Secrets Manager with Entrust NShield HSM
Using Secrets Manager with Entrust HSM
Once setup, the Secrets Manager Entrust integration supports all Secrets Manager SDK functionality. Your code will need to be able to access the nShield HSM in order to manage the decryption of the configuration file when run.
Check out the KSM SDKs documentation for more examples and functionality
Create an Encryption Key for Testing
In order to test encryption with the Entrust nShield HSM, use the following command:
Replace "ksmkey" in these examples with the identity in your HSM.
in Linux:
in Windows:
GCP Secret Manager
Sync secrets from the Keeper Vault with GCP Secret Manager
About
The Keeper Secrets Manager CLI tool sync command allows you to push secrets from the Keeper Vault to a target GCP Secret Manager project, overwriting the existing values in the target location. This allows the Keeper Vault to be the single source of truth for any services or scripts in GCP that utilize GCP Secret Manager.
Features
Use secrets from the Keeper Vault as the source of truth for GCP Secret Manager
Seamlessly start using secrets from the Keeper Vault with your existing GCP scripts and services
Prerequisites
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper subscription
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
A GCP account with GCP Secret Manager, and optionally the ability to create IAM service account credentials
Setup
1. Configure Keeper Secrets Manager CLI
You can skip this step if the KSM CLI is already configured on your machine.
To configure the KSM CLI tool, a profile needs to be created with the Keeper Secrets Manager One Time Access Token.
The simplest way to do this is to initialize the default profile with the following command:
ksm profile init <TOKEN>
For information on creating multiple profiles and other options, see the profile documentation
2. Set GCP Permissions
To use the KSM sync to GCP, GCP Secrets Manager requires standard IAM security credentials with Secret Manager Admin role enabled for the project or on the service account principal to sync.
Secret Manager Access control with IAM:
GCP instructions for creating Service Account Credentials (optional):
3. Create GCP Credentials Record
The KSM CLI needs the credentials for the GCP service account to set secrets. These credentials are stored in a Keeper record which the CLI tool can access using Keeper Secrets Manager.
Record fields with the following labels are required on the credentials record:
"Google Cloud Project ID"
"Google Application Credentials" - optional
"Google Application Credentials" field is optional and needed only when Service Account Credentials are used. By default, GCP clients use Application Default Credentials which can be created using gcloud CLI
When no longer need these credentials can be revoked:
(Method 1) Create a GCP Credentials Custom Record Type
A custom record type can be created with the required fields, which makes it easy and clean to create a record.
To create a custom record type, go to the "Custom Record Types" tab in the Keeper Vault and hit "Create Type". Create a new record type with hidden fields that have the correct field label, then click "Publish" to create the new record type.
Then simply create a new record of the GCP Credentials type and enter the details into the corresponding fields.
Make sure this new record is moved to a Shared Folder that is associated with your Secrets Manager application.
(Method 2) Add Custom Fields
To create a credentials record without creating a new record type, the required fields can be added as custom fields to a standard record.
Create a new record of any type, then add Custom Fields of the 'Hidden Field' type for each required GCP field. Click "Edit Label" to change the labels for the corresponding field name.
Any record type will work, but the "File Attachment" standard record type has no fields and will be cleaner looking when custom fields are added
Then fill in each custom field and hit "Save" to save the record.
4. Create Value Mappings
The KSM CLI sync command identifies which values to set using mappings that are defined on the command call. For each mapping passed to the command, a value with the given name will be populated with the given value from the Keeper Vault.
These mappings follow this format:
--map "VALUE KEY" "KEEPER NOTATION"
VALUE KEY is the key name that the value will be assigned in GCP Secret Manager
KEEPER NOTATION is a Keeper notation query of a value from a keeper record to set to the key
Keeper notation is a query notation used by Keeper Secrets Manager to identify specific record values. The notation follows the general format of: UID/[field|custom_field]/fieldname
for example: ae3d[...]d22e/field/password
See the Keeper Notation documentation for more information
Note that full record UIDs are not given in these examples
Full Mapping Example:
--map "MySQL_PWD" "jd3[...]i-fd/field/password"
Multiple mappings can be added to a single sync command
--map "MySQL_PWD" "jd3[...]i-fd/field/password" --map "MySQL_Login" "jd3[...]i-fd/field/login"
Ensure that the records referenced by the Keeper Notation queries are in a shared folder that is shared with your Secrets Manager application
KSM sync is now ready to run
Run Sync
To run the sync, use the KSM CLI sync command with the credentials record and value mapping.
1. Construct the Command
Put together the KSM sync command with the GCP type. The format looks like the following:
ksm sync --type gcp --credentials [UID] --map [...] --map [...]
2. Run a Dry-Run
The sync command supports running a dry-run which will identify all changes that will be made to your GCP Secret Manager values without actually pushing the values or making changes. Use this to make sure your mapping queries are constructed properly.
ksm sync --type gcp --credentials [UID] --map [...] --map [...] --dry-run
3. Run the Sync
When ready, run the sync command without the dry-run option. This will push values from your Keeper Vault to GCP Secret Manager
TIP: you can use -m as short hand for --map
ksm sync --type gcp --credentials [UID] -m [...] -m [...]
Git - Sign Commits with SSH
Sign your git commits using an SSH key stored in your Keeper Vault
About
Signing your git commits is important. It verifies authorship, ensures the integrity of committed content, prevents identity spoofing, and establishes non-repudiation. Using a cryptographic signature with your private key demonstrates a commitment to the authenticity and security of your contributions, building trust among collaborators and protecting the repository from potential tampering and malicious code.
This integration allows developers to sign git commits with an SSH key protected in your Keeper Vault (via Keeper Secrets Manager).
Features
Signs git commits using an SSH key stored in Keeper Vault.
Removes the need for SSH keys on disk for secure DevOps workflows.
Works on Windows, MacOS, and Linux.
Source code at https://github.com/Keeper-Security/git-ssh-sign
Prerequisites
In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with SSH key(s) shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
This integration only accepts JSON format configurations
Git installed with a minimum version of 2.34.0
Setup
1. Secrets Manager Configuration
Login to the Keeper Web Vault or Desktop App
Create a shared folder (e.g. "Git SSH Keys")
Add a SSH Key record to the shared folder
Generate
In order to fetch the SSH key from your vault, this integration uses the zero-knowledge Keeper Secrets Manager.
It expects to find the Secrets Manager configuration file at .config/keeper/ssh-sign.json in the user's home directory for all systems. If this configuration is not found, it will check ssh-sign.json as a backup. The Secrets Manager application must have access to the shared folder in which your SSH key is stored.
For help in setting up your application and obtaining your configuration file, you can find detailed instructions here.
2. Git Config
After successfully configuring Secrets Manager, you can now configure git to sign your commits automatically. This can be done locally or globally, depending on your needs.
Four pieces of information are required in your config:
Tell git you want to sign all commits.
Tell git you want to use SSH signing over the default GPG signing.
Tell git the location of this integration's executable file. (download here)
Tell git the UID of the SSH key to be used to sign.
We can do this for the local Git repository with the following commands (add the --global flag to set these globally):
Your git config will now include these attributes:
3. Add Keys to GitHub / GitLab
3.1 Setup GitHub
For GitHub to verify the signature used to sign the commit, you will need to upload your SSH key's public key to your GitHub account. GitHub will then use this public key to verify the signature and display the verified tag in the UI.
For full details on adding your public key to your account, see GitHub's official documentation.
Important: Be sure to set the type of key to "signing key".
3.2 Setup GitLab
For GitLab to verify the signature used to sign the commit, you will need to upload your SSH key's public key to your GitLab account. GitLab will then use this public key to verify the signature and display the verified tag in the UI.
For full details on adding your public key to your account, see Gitlab's official documentation.
Important: Be sure to set the type of key to "signing key" or "Authentication and signing".
Verify Signatures
Git is now configured to automatically sign all commits, regardless of whether you use the terminal or an IDE interface to interact with git. It also removes the need to use the -S flag for commit signing.
You can confirm your commit has been signed with git show --pretty=raw in the terminal.
GitHub and GitLab
Once you have signed a commit and pushed it to GitHub or GitLab, you should see the verified tag next to your commit in the Git history automatically. No further work is needed.
Local verification
If your repos are stored in your own datacenter, you can verify commits locally on the command line. In order to so this, you will need to create an allowed_signers file which is a record of authorized signing keys.
Typically, this file is saved either globally at .ssh/allowed_signers or in the local repo at .git/allowed_signers. The path to this file needs then to be added to your .gitconfig or .git/config file.
Each line of your allowed_signers file should be a principal of an authorized signing key. The line should start with the email address associated with the public key, separated by a space. For example:
The format of the allowed signers file is documented in full here.
While it is correct syntax to have more than one email address associate with a single public key, it is not recommended or currently supported.
To verify your git history use:
Source
The source code for this integration is open source and available on GitHub. Issues can be submitted here.
Similar Integrations
Keeper also provides the ability to authenticate and sign Git commits using the Keeper SSH Agent.
Learn more about the Keeper SSH Agent and specifically Integration with Git
GitHub Actions
Keeper Secrets Manager integration into GitHub Actions for dynamic secrets retrieval
Features
Retrieve secrets from the Keeper Vault within the Github Actions runner
Set secret credentials as build arguments or environment variables in Github Actions scripts
Copy secure files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Video Demo
The below overview video covers basic setup and ends with a basic Github Actions integration.
Prerequisites
This page documents the Secrets Manager GitHub Actions integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The GitHub Actions integration accepts JSON and Base64 format configurations
About
This action securely retrieves secrets from Keeper and places them to the desired destination of the GitHub Actions runner such as an environment variable, output parameters of the step or to the file.
Quick Start
Below example shows all available functionality of this plugin
You will need to provide two inputs to utilize the Github Actions plugin:
A Keeper Secrets Manager configuration
Github Actions supports JSON type configuration
Keeper Notation queries for secrets
Inputs
keeper-secret-config
keeper-secret-configSecrets configuration. See documentation for more information about creating a configuration.
JSON type configuration is supported.
Example:
We recommend storing the configuration in a Github Actions secret and accessing it as a variable, as shown in the example above.
secrets
secrets Queries using Keeper Notation to access fields in Keeper records.
The secrets input is the list of secrets that you need to get from Keeper and put into either an environment variable, GitHub Action output or a file.
Example:
The first part is the id of the secret using the Keeper Notation format.
The second part defines the destination of the secret in the GitHub runner.
field or custom_field
Notation query result is placed into step's output
Notation query result is placed into environment variable
Not allowed
file
file is downloaded and placed into destination
file is downloaded and placed into destination
file is downloaded and placed into destination
Masking - Hiding Secrets from Logs
This action uses GitHub Action's built-in masking, so all variables will automatically be masked if printed to the console or to logs. This only obscures secrets from output logs. If someone has the ability to edit your workflows, then they are able to read and therefore write secrets to somewhere else just like normal GitHub Secrets.
Source Code
Find the Keeper Secrets Manager Github Actions plugin source code in the GitHub repository
GitLab
Keeper Secrets Manager integration into GitLab for dynamic secrets retrieval
Features
Retrieve secrets from the Keeper Vault within the GitLab Pipeline
Set secret credentials as build arguments or environment variables
Copy secure files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager GitLab integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The GitLab integration accepts JSON and Base64 format configurations
A GitLab account with Pipeline creation access
Python3 installed to the GitLab Pipeline job
About
This action securely retrieves secrets from Keeper and places them to the desired destination of the GitLab Pipeline such as an environment variable or file.
Setup
Save Configuration as a Secret Variable
A keeper Secrets Manager configuration is required to utilize the GitLab integration.
1) Create a Keeper Secrets Manager Configuration. See the documentation for details. The GitLab integration supports Base64 and JSON configurations.
2) To save the configuration in GitLab, navigate to GitLab Settings -> CI/CD -> Variables
3) Create a new variable. Key can be set to any name for the variable (use KSM_CONFIG to have the SDKs automatically recognize the configuration). Set Value as the Secrets Manager configuration in Base64 or JSON format.
Use KSM_CONFIG as the variable name to have Secrets Manager SDKs automatically recognize the configuration variable
After creating the variable, you should see it in your GitLab variables as shown below.
Keeper Secrets Manager GitLab Integration setup is complete
Usage
Prepare the Pipeline for Secrets Manager
In order to use Keeper Secrets Manager with GitLab, first we need to install it from the PyPi registry. This can be achieved by adding following line to the before_script area:
If you did not set the Secrets Manager Configuration variable to the name KSM_CONFIG you need to set it here in the before_script area
Get Secrets
Inside the GitLab job, retrieve a secrets from the Keeper Vault using the following format:
This utilizes the KSM CLI tool to get secrets using Keeper Notation.
After getting a secret, you can set it as an environment variable or file.
Set Secret as Environment Variable
Use - export <VARIABLE NAME>=$(ksm secret notation <KEEPER NOTATION>) to set a secret to an environment variable
Example:
The following job sets a password secret as an environment variable named MY_PWD and a custom 'isbncode' record field to the environment variable named MY _ISBNCODE
Replace XXX with a record UID in the above example.
Keeper Secrets Manager can be used in any job stage. This example uses the build stage.
Create a File from a Secret
Use - ksm secret download -u <UID> --name <SECRET FILENAME> --file-output "<OUTPUT FILENAME>" to get a file from the Keeper Vault and save it as a file to your GitLab Pipeline job.
Example:
The following job gets a file named "mykey.pub" that is attached to a Keeper record and saves its contents into file name "mykey.pub" in the local "tmp" folder
Replace XXX with a record UID in the above example.
Keeper Secrets Manager can be used in any job stage. This example uses the build stage.
Complete Example
The example below shows all available functionality of this integration
Replace XXX in the example above with a record UID.
Hashicorp Vault
Use Keeper Secrets Manager with HashiCorp Vault as a Data Source
About
The Keeper Secrets Manager HashiCorp Vault integration allows you to use secrets from the Keeper Vault as a data store for HashiCorp Vault.
Features
Use Secrets from the Keeper Vault with HashiCorp Vault scripts and commands
Read secret information using HashiCorp Vault
Update secret information from HashiCorp Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager HashiCorp Vault integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper subscription
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The HashiCorp Vault integration accepts our Base64 format configurations
HashiCorp Vault command line, and a Vault server running
See the HashiCorp Vault documentation for how to install
Installation
1. Download the Secrets Manager Plugin
Download the latest integration release from the KSM GitHub page:
Look for a vault-plugin release in the list of releases that matched your platform.
Unzip the plugin and place it into your HashiCorp Vault plugins directory. In this example the folder is located at C:\vault\plugins (Windows) or /etc/vault/vault_plugins (MacOS/ Linux)
2. Register the Plugin with HashiCorp Vault
Development Mode
For testing the plugin or to allow quick development, development mode can be used to quickly get the HashiCorp Vault CLI up and running.
HashiCorp Vault CLI development mode utilizes volatile in-memory storage. Any actions taken on secrets in the Keeper Vault are immediate, but the plugin will need to be re-enabled each time the HashiCorp Vault is started in dev mode.
Production Mode
When ready to move to production, the plugin will need to be registered using a SHA256 hash of the plugin.
Register and Enable the Secrets Manager Plugin
Generating SHA256 Hash
You will need a hash of the plugin file to enable it with production HashiCorp Vault servers. This hash can be generated for the Secrets Manager plugin.
Windows 7 and later comes with a built-in tool called CertUtil that can be used to generate the SHA256 hash. This example will show how to generate a SHA hash using CertUtil, but any tool that can generate a file hash in SHA256 will work.
Register and Enable the Secrets Manager Plugin
Generating SHA256 Hash
You will need a hash of the plugin file to enable it with production HashiCorp Vault servers. This hash can be generated for the Secrets Manager plugin.
Using the built-in shasum function this can be generated like this:
Depending on your OS, you may use the sha256sum command instead
3. Configure a Secrets Manager Connection
Now that the HashiCorp Vault plugin is installed, a secure connection to the Keeper Vault needs to be established so that secret credentials can be accessed. To create this connection, a Secrets Manager configuration needs to be created and assigned to the plugin.
Create a Secrets Manager Configuration
A Secrets Manager configuration can be created using Keeper Commander or the Secrets Manager CLI. See the Configuration Documentation for more information on creating a configuration.
Once a configuration has been generated, set it to a variable to be used by the Vault Plugin.
Using the Plugin
List Secrets
The records will be shown in the following format:
Example:
Get a Single Secret
Example:
Read TOTP Code
Example:
Update a Secret
To update an existing secret, use the following command, passing in JSON data that represents the updated secret's information. The corresponding record in the Keeper Vault will be updated to match the JSON data passed.
In this example, the updated data is passed in from a file, this is recommended for cleaner and more simple CLI commands. The JSON data can be passed in on the command line, but quotes will need to be escaped.
Example data file:
TIP
You can see the current values of a secret in JSON format with this command:
vault read -field=data -format=json ksm/record uid=<UID>
Create a Secret
Similar to updating a secret, create a new secret by passing JSON data to the following command:
In this example, the updated data is passed in from a file, this is recommended for cleaner and more simple CLI commands. The JSON data can be passed in on the command line, but quotes will need to be escaped.
Example data file:
Delete a Secret
Heroku
Using Keepers Secrets Manager to store your Heroku application sensitive secrets.
Features
Securely store secret credentials in the Keeper Vault and use them in Heroku without exposure
Copy files from the Keeper vault into your Heroku Apps
Utilize other Secrets Manager SDK features (such as record creation and TOTP codes) from Heroku
For a complete list of Keeper Secrets Manager features see the Overview
About
Heroku offers the ability to store configuration variables for your application. The problem is it stores the values in a viewable format. Keeper Secrets Manager allows you to store your sensitive secrets offsite in a zero knowledge environment.
The Keeper Secrets Manager SDK can be used with Heroku
See the example project below to get an idea of the capabilities of Keeper Secrets Manager with Heroku
Example - Slack notification using Python SDK
This example uses the Keeper Secrets Manager SDK to retrieve a webhook token to send messages to a channel in Slack from a Heroku web application.
Slack Setup
The first step is getting a webhook token from your instance of Slack. Login into the Slack website and go to Your Apps.
Create a new app by clicking the Create New App button and selecting From scratch from the dialog box. At this point enter an App Name and select the workspace you want to develop your app in.
Next click the Incoming Webhooks button.
Turn On the Incoming Webhooks. This will show the Webhook URLs for Your Workspace section. Click the Add New Webhook to Workspace button.
Then select a channel in your workspace.
Now at the bottom of the Incoming Webhooks page, there will be a Webhook URL. For this example, Copy the url. This will be placed in Keeper Vault record.
Keeper Vault setup
In the Keeper Vault create a Login record to hold the Slack Webhook URL in the Shared Folder. The Shared Folder can be added used by an Application. Reference the Quick Start Guide for more details.
Copy the Webhook URL into the Website Address field of the Login record and save. Once saved click on the information icon, 
, of the record to see the Record UID. You can copy a Record UID URL into the clipboard which will contain the actual Record UID. You only need that part of the URL.
Heroku
For this example, a Heroku account and Python 3 are requiered. The next step is to install the Heroku CLI following their instructions.
With the Heroku CLI installed an application can be created.
The generated name of your application will be different than in this example.
That will create a blank Git repository that will be used for the application. The Git repository can then be cloned. There will be a warning about it being empty. After that change into the repository directory.
With the repository cloned, the config variables can be set. There are two config variables that need to be set. The first is RECORD_UID which the Record UID of the record that contains the Webhook URL. The second is KSM_CONFIG which contains the Base64 encoded Secrets Manager configuration.
See the Configuration documentation for details on creating a Base64 configuration
With the configuration variables in place, the application can be added. The first step is to defined the requirements for the Python 3 application. The requirements.txt file contains Flask used for the website, slack_sdk used to communicate with Slack, and keeper-secrets-manager-core to communicate with Secrets Manager.
In your preferred editor save the contents of the following to app.py.
This is a simple Flask web application that will display a form input box and a submit button. Any text entered into the input box will be sent to your Slack channel.
The last part is to give Heroku information on how to start your application using the Procfile file.
Now the application is ready to be run. Add the file it your the Git repository and push the main branch. This will build and launch the application.
At this point you can visit the web site by either going to the URL, i.e. https://random-name-30564.herokuapp.com/, or by using the following command line.
This will display a simple web site. Enter a message and click submit.
The message should appear in the channel for the created Webhook.
Jenkins Plugin
Keeper Secrets Manager integration into Jenkins for dynamic secrets retrieval
Features
Retrieve secrets from the Keeper Vault with Jenkins
Use Keeper Secrets Manager with Jenkins Freestyle or Jenkins Pipeline projects
Get files from the Keeper vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Jenkins integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
The plugin uses SecureRandom which can be slow on certain systems due too low entropy.
On Linux, executing cat /proc/sys/kernel/random/entropy_avail will show the available entropy. If below 200, you'll need to software like rng-tools to generate entropy.
About
The Jenkins plugin for Keeper Secrets Manager allows you retrieve secrets from the Keeper Vault and place the values into environmental variables or files within the builder and workflow pipelines.
Installation
The Keeper Secrets Plugin can be installed from Jenkins' the list of available plugins. Within Jenkins navigate to Manage Jenkins->Manage Plugins->Available. Search for "Keeper Secrets Manager" using the search bar to find the plugin. Check the Install checkbox and an Install button. You can choose to restart Jenkins immediately, or later to complete installation. When Jenkins restarts, you will be able to use the plugin.
If you had installed a beta version of the Keeper Secrets Manager plugin you will need to remove it first. On the tab Manage Jenkins->Manage Plugins->Installedclick the Uninstall button. It will not show up on the Available tab if already installed.
Source Code
Find the Keeper Secrets Manager Jenkins Plugin source code in the GitHub repository
Create a Secrets Manager Client
If you haven't done so already, follow the Quick Start Guide and create a Secrets Manager application and Client Device specifically for Jenkins usage.
Using Keeper Commander, generate a Client Device for Jenkins. Make note of the One Time Access Token.
By default, the Client Device is locked to the first IP address that uses the One Time Access Token. If your Jenkins server has potentially multiple external IP addresses, you may want to add the--unlock-ipparameter when generating the One Time Access Token.
For more information on creating Secrets Manager Applications and Clients, see the Secrets Manager Commands documentation.
Add Credential to Jenkins
The first step in using the plugin is creating a Jenkins credential from a One Time Access Token.
Within Jenkins, navigate to Manage Jenkins > Manage Credentials > (scope) > Add Credentials, then select Keeper Secrets Manager in the Kind dropdown. You will be presented with a form that looks like the following:
Set a Description for the credential to make it easier to find in other areas of Jenkins.
Paste the One Time Access Token into the form field and save.
Initial Connection
When you save the credential, the Jenkins server will connect to the Keeper Secrets Manager service and initialize the One Time Access Token. It will then populate the required encryption keys and client identifiers inside Jenkins for subsequent requests. At this point the One Time Access Token field will be cleared out.
If there was a problem initializing the One Time Access Token, the error message will be placed in the field. The Jenkins credential cannot be used until there is no errors. You are able to create a new One Time Access Token and replace the information that already existing for a credential. Just use Commander to create another token, cut-n-paste it into the Token field, and save.
You will not be able to see the Client Id, Private and App Keys. You can replace them from an existing config by clicking the Replace Keys... button.
Clicking the Replace button will allow you to cut-n-paste values from an existing configuration into Jenkins. You can then validate the id and keys by clicking the the Validate Credential button.
Example Usage: Freestyle Project
For a Freestyle project the environmental variable injection is performed via a Build step.
In the Add build step dropdown, select Keeper Secrets Manager.
In the Credential dropdown select the Keeper Secrets Manager credential that was created in the prior steps.
Using Keeper Notation syntax, the environmental variable is magically replaced with the matching value from the record in the Keeper vault. You can reference any field within the Keeper vault secret such as login, password, custom field or filename.
Then select the destination for the secret. A secret can be placed into an environmental variable or a file within the build's workspace.
You can add multiple environmental variable to the Build step by clicking on "Add Secret" and populating the environmental variable and notation fields.
Keeper Notation Syntax
Use the Keeper notation format to select which record field to use as your secret. Keeper notation has the following format:
keeper://<Record UID>/field/<field name>
Where "Record UID" is the UID of the record which contains the secret credential as a field and "field name" is the field that credential is stored as, such as "password"
Here's an example: keeper://3FXqmP5nFKwju0H8pl0DmQ/field/password
The Record UID can be found in Keeper Commander or inside the Web Vault user interface.
Using Your Secrets
The populated environment variables will available to the following build steps. You can even add another Keeper Secrets Manager step and select secret from a different account or application.
You can use and view the environment variables in a Execute Shell step. For example:
In the above the environmental variable MY_LOGIN will be passed a parameter to the application my_app, however the echo statement will result in the text "****" the console. Text based secrets are actively redacted in the console.
Example Usage: Pipeline Integration (Workflows)
The Keeper Secret Manager plugin can be used inside a Jenkinsfile using a step that has the label withKsm. Below is an example.
The Keeper Secrets Manager snippet can be created using the Pipeline Syntax snipper editor inside of Jenkins. Select withKsm from the Sample Step dropdown, then add a Keeper Secrets Manager Application, which will allow you to select the credentials and add secrets.
When you are finished setting up your application, credentials, and secrets, you can click the Generate Pipeline Script to generate the withKsm block. This snippet can then be added to your Jenkinsfile.
The environmental variables containing the secrets are only accessible within the withKsm block where they are defined. Once you exit the block, the secrets are not accessible.
Keeper Connection Manager
Keeper Secrets Manager integration into Keeper Connection Manager for dynamic secrets retrieval
Features
Retrieve secrets from Keeper when launching Remote RDP, SSH, MySQL and other connections
Protect secret configuration settings in the Keeper Vault
Provide privileged sessions without exposing credentials to the end-user
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager <> Keeper Connection Manager integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The Connection Manager integration accepts the Base64 format configuration
Installation
This integration securely retrieves secrets from Keeper for use in establishing remote connections via RDP, SSH, VNC, MySQL, K8s and other protocols.
Step by Step documentation for activating Keeper Secrets Manager with Keeper Connection Manager can be found at the link below:
Kubernetes External Secrets Operator
Synchronize Secrets from Keeper Secrets Manager with the K8s External Secrets Operator
Overview
Kubernetes External Secrets Operator injects secrets into Kubernetes by synchronizing them from various external APIs. This guide primarily focuses on the setup process for External Secrets, facilitating the synchronization of secrets from your Keeper Vault into Kubernetes.
The External Operator documentation can be found at this link.
Features
Seamless synchronization of secrets from Keeper Vault into Kubernetes via External Secrets.
Real-time access to secrets from Keeper Vault across all pods.
Prerequisites
Before proceeding with the setup, ensure you have the following:
Keeper Secrets Manager (KSM) access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
Make sure you add the proper permissions to your device in order to be able to read and write secrets
An initialized Keeper Secrets Manager Configuration
Setup
Install External Secrets With Helm
To install External Secrets with Helm, run the following commands:
Create Kubernetes Secret to store Base64 KSM Config
After creating a Secrets Manager Configuration for your device, you will have a Base64 JSON string that contains connection tokens, encryption keys, identifiers and domain information used to authenticate and decrypt data from the Keeper Secrets Manager APIs.
The Base64 JSON config string will be set by External Secrets to authenticate against Keeper Security and defined in a regular Kubernetes Secret.
Invoking the following command will create a Kubernetes Secret which is used to authenticate to Keeper Secrets Manager:
Note: Lines 2-8 in the above code snippet can be stored in a YAML file and applied with the command kubectl apply. For example, you can store lines 2-8 in secrets.yaml and execute the following:
Create SecretStore
After creating a Kubernetes Secret with ksm_config defined to your Base64 JSON string, you can now create your SecretStore.
Invoking the following command will create your SecretStore:
In the above code snippet, define folderID with the UID of the shared folder where the records are stored in your Vault
In case of a ClusterSecretStore, Be sure to provide namespace for SecretAccessKeyRef with the namespace of the secret that we just created.
Note: Lines 2-13 in the above code snippet can be stored in a YAML file and applied with the command kubectl apply. For example, you can store lines 2-13 in secretstore.yaml and execute the following:
Create ExternalSecret
Next, you need to create your ExternalSecret.
The following code snippet will create your External Secret and store the values of the login & password field for the specified record into the Kubernetes Secret. These fields are defined in the target.template.data section and refreshed every 30 seconds. For a full list of supported fields, visit this page.
In the above code snippet, replace "[RECORD UID]" with the UID of your desired record
For complex types, like name, phone, bankAccount, which does not match with a single string value, external secrets will return the complete JSON string. Use the JSON template functions to decode.
Note: Lines 2-27 in the above code snippet can be stored in a YAML file and applied with the command kubectl apply. For example, you can store lines 2-27 in externalsecret.yaml and execute the following:
Behavior
How a Record is equated to an ExternalSecret:
remoteRef.keyis equated to a Record's IDremoteRef.propertyis equated to one of the following options:Fields: Record's field's Type
CustomFields: Record's field's Label
Files: Record's file's Name
If empty, defaults to the complete Record in JSON format
remoteRef.versionis currently not supported.
dataFrom:find.pathis currently not supported.find.name.regexpis equated to one of the following options:Fields: Record's field's Type
CustomFields: Record's field's Label
Files: Record's file's Name
find.tagsare not supported at this time.
Limitations
There are some limitations using this provider.
Keeper Secret Manager does not work with legacy non-typed records
Using tags
find.tagsis not supported by KSMUsing path
find.pathis not supported at the moment
Push Secrets
Push Secret will only work with a custom KeeperSecurity Record type ExternalSecrets
Behavior
selector:secret.name: name of the kubernetes secret to be pusheddata.match:secretKey: key on the selected secret to be pushedremoteRef.remoteKey: Secret and key to be created on the remote providerFormat: SecretName/SecretKey
Create PushSecret
To create a Keeper Security record from Kubernetes a Kind=PushSecret is needed.
Note: Lines 2-19 in the above code snippet can be stored in a YAML file and applied with the command kubectl apply. For example, you can store lines 2-19 in pushsecret.yaml and execute the following:
Make sure there's only one record with the title remote-secret-name in the KSM Application in use.
Limitations
Only possible to push one key per secret at the moment
If the record with the selected name exists but the key does not exists the record can not be updated.
Verifying Setup
After setting up your Kubernetes Secret, SecretStore, and ExternalSecret, you can extract secrets with the command kubectl get secrets
In the above code snippets, the name of the secret is my-external-secrets-values and we store the following record values:
To get the login and password values, invoke the following command:
The above response is encoded, to decode, invoke the following:
Conclusion
In conclusion, this guide has detailed a step-by-step process for integrating the Keeper Secrets Manager with Kubernetes via the Kubernetes External Secrets Operator. By following these steps, you'll be able to seamlessly synchronize your secrets stored in Keeper Vault into your Kubernetes environment. This not only provides a secure method to manage your secrets but also facilitates real-time access across all your pods.
The processes outlined, including setting up the External Secrets operator, creating a Kubernetes Secret, SecretStore, and ExternalSecret, are key to this integration. Upon successful setup, the provided commands allow you to verify the integration and retrieve stored secrets effortlessly.
The integration of Keeper Secrets Manager with Kubernetes enhances the security infrastructure of your applications running in the Kubernetes environment. It provides a solid foundation for managing your secrets, thereby improving overall operational efficiency and security posture.
Remember to replace all placeholders in the command snippets with your specific information, and don't hesitate to refer back to this guide anytime you need to set up or manage your External Secrets in Kubernetes.
Kubernetes (alternative)
Keeper Secrets Manager integration into Kubernetes for dynamic secrets retrieval
We recommend using the Kubernetes External Secrets Operator integration for most use cases. This document describes an alternate method of integration which does not utilize the External Secrets Operator.
Features
Retrieve secrets from the Keeper Vault within the Kubernetes
Access secrets from the Keeper Vault in real-time across all pods
Copy secure file attachments from the Keeper Vault to the local filesystem
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Kubernetes integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
About
Keeper Secrets Manager can be integrated into your K8s cluster for accessing Keeper secrets in real-time across all pods.
Setup
Create a Secrets Manager Configuration
Using Commander, create a Secrets Manager device configuration for Kubernetes. Note that this configuration is not IP locked and it is pre-initialized.
Create the configuration in Commander using this command:
secrets-manager client add --app <APP NAME> --unlock-ip --config-init k8s
Example:
In the example above, copy lines 8 through 14 and place them into a file called secret.yaml. Then, If you are using a machine with kubectl installed and you have access to your cluster, add the KSM SDK config to your Kubernetes secrets.
For more information on creating Secrets Manger configurations, see the Configuration Documentation
Alternate Method: One Time Access Token and KSM CLI
Alternatively, you can create a configuration by generating a One Time Access Token with Commander (or the Vault UI) and then using the Keeper Secret Manager CLI to create a configuration as demonstrated below (replace XX:XXX) with the One Time Access Token.
If you are using a machine with kubectl installed and you have access to your cluster, the parameter --apply can be set to automatically add the KSM SDK config to your Kubernetes secrets.
The output of redeeming the token can be piped to a file and then applied via kubectl. For example:
Using the KSM Config
The KSM config can be pulled into your K8s containers using secrets.
At runtime, the Keeper Developer SDKs running in the K8s cluster will use the environment variable KSM_CONFIG to retrieve the device configuration and communicate with the Keeper Vault.
Examples
Example 1 - Custom App using SDK
Below is a simple example that will generate a deployment and service that displays database secrets via a web application. This example uses the Keeper Python Developer SDK for the web application. The SDK will get its configuration from a Kubernetes secret and then retrieve PostgreSQL database record information from the Keeper vault.
From the Keeper Vault, a "Database" record type is created using the following information.
Now let's create our web application. The web page can be created using any of the Developer SDKs. For this example, it will being using the Python SDK. A simple Flask application with one endpoint will display the HTML that contains the Vault record secrets. The secrets are retrieved using the Keeper Notation syntax.
The next part is creating a Dockerfile. The Dockerfile below is based off of the Python Debian images from Docker Hub.
The Python SDK uses the cryptography module. This module requires the language Rust to be installed. Other Docker Hub images may provide Rust pre-installed.
Next we will build a Docker image named ksm_demo.
Assuming there is access to the Kubernetes cluster, the config can be generated from the One Time Access Token and automatically applied.
You can see the secret entry when you enter kubectl get secret.
You can then make a deployment and service for the ksm_demo Docker image. This example is going to name the file ksm_demo.yaml.
Defining which secrets you need, and the config for the SDK, happen in the env section in the list of containers. In this section the KSM_CONFIG environmental variable is defined to get it's value from the ksm-config Kubernetes secret, specifically the config key of the secret.
The other environmental variables are just list of name/values. The value is Keeper Notation which the web application will send to the notation retrieval method of the SDK.
The second record in the ksm_demo.yaml file is the Service definition. This can be changed to whatever works with your Kubernetes cluster. In our example, it uses an external IP address. It's safe to use one of your Kubernetes nodes IP address, 10.0.1.18 for the example.
At this point the deployment and service are ready to be applied.
Wait until your deployment is ready. Either monitor it via the command line or Kubernetes Dashboard.
Finally, use a web browser and go to the external IP address, port 5000, and you will see the Keeper vault record database secrets.
Example 2 - NGINX SSL certificates
In this example a pod will be created that contains the stock NGINX docker image and SSL certificates retrieved from the Keeper Vault.
A Login record is created in the vault to hold the SSL certificate, private key, and certificate password.
A one time token is generated and added to the Kubernetes ConfigMap.
The example website is simply an index HTML page. The HTML can be stored in the ConfigMap and mounted in to the document root directory.
The default.conf will be overwritten by our example. The certificate, key, and password will be placed in to the /etc/keys directory. For non-interactive startup, NGINX requires the certificate password be placed in a file and ssl_password_file to be included in the server configuration.
The deployment for this example looks like the following:
The docker image keeper/keeper-secrets-manager-writer is used for an initialization container. The container will retrieve the secrets and write them to disk so they can be used by NGINX. The secrets are written to the pod's emptyDir volume, mounted to /etc/keys. This directory will be removed when the pod is deleted.
Documentation for the Keeper Secrets Manager Writer can be found here.
The main container will also mount the pod's emptyDir volume to /etc/keys. And will also mount the default.conf into /etc/nginx/conf.d and the index.html file into the document root for the server.
The last part is to create a service to access NGINX as shown below.
The service can be tested by going to the external IP via https (ie https://XXX.XXX.XXX.XXX). Notice the lock in the address bar indicates the certificate is valid.
External Secrets
External Secrets is a Kubernetes operator that synchronizes secrets from External APIs and injects them into Kubernetes. For more information on how to setup External Secrets to synchronize secrets from your Keeper Vault into Kubernetes, visit the following:
Kubernetes External Secrets OperatorNext Steps
At this point, you can now integrate Keeper Secrets Manager into your K8s deployments using any of the Secrets Manager SDKs.
Linux Keyring
Store and Retrieve Secrets from the Linux Keyring
Overview
Keyring is a Linux security feature that stores sensitive information, such as passwords and secrets, and allows applications to securely access it.
Keeper provides a utility, the Linux Keyring Utility, that interacts with the native Linux APIs to store and retrieve secrets from the Keyring using the Secret Service API. This utility can be used by any integration, plugin, or code base to store and retrieve credentials, secrets, and passwords in any Linux Keyring simply and natively.
The code base for the Linux Keyring Utility can be found here:
The binary needed to use the above utility can be found here:
To use the Linux Keyring Utility, you can either
deploy the pre-built binary from the releases page
or import it into your code base.
Both use cases are covered below.
Linux Keyring Utility
The Linux Keyring Utility gets and sets secrets in a Linux Keyring using the D-Bus Secret Service.
It has been tested with GNOME Keyring and KDE Wallet Manager. It should work with any implementation of the D-Bus Secrets Service.
Interface
There are two packages, dbus_secrets and secret_collection. The secret_collection object uses the functions in dbus_secrets. It unifies the D-Bus Connection, Session and Collection Service objects to offer a simple get/set/delete interface that the CLI uses.
Usage - Importing it into your codebase
The Go Language API has offers Get(), Set() and Delete() methods. The first two accept and return string data.
Example (get)
The .DefaultCollection() returns whatever collection the default alias refers to. It will generate an error if the default alias is not set. It usually points to the login keyring. Most Linux Keyring interfaces allow the user to set it.
The .NamedCollection(string) method provides access to collections by name.
Example (set)
Set takes the data as a parameter and only returns an error or nil on success. It does not restrict the content or length of the secret data.
Usage - Binary Interface (CLI)
The Linux binary supports three subcommands:
getsetdel
Get and del require one parameter; name, which is the secret Label in D-Bus API terms.
Del accepts one or more secret labels and deletes all of them. If it generates an error it will stop.
Set also requires the data as a single string in the second parameter. For example, set foo bar baz will generate an error but set foo 'bar baz' will work. If the string is - then the string is read from standard input.
Base64 encoding
Get and set take a -b or --base64 flag that handles base64 automatically. If used, Set will encode the input before storing it and/or get will decode it before printing.
Note that calling get -b on a secret that is not base64 encoded secret will generate an error.
Examples
Errors
Error output goes to stderr so adding 2>/dev/null to the end of a command will suppress it.
No keyring
The login collection does not exist because the keyring does not exist. KDE may create kdewallet instead of login like GNOME.
No matching secret
A secret may not be returned even though a secret with the same label exists. If the secret was not created with lkru, it may not have the same attributes. Namely 'Agent', 'Application', and 'Id'.
No D-Bus Session
There may not be a D-Bus Session to host the Secret Service. This happens when the user is not logged into the GUI.
No D-Bus
The system may not host D-Bus. Several lightweight linux distributions ship without it by default.
Octopus Deploy
Keeper Secrets Manager Step Template for accessing secrets in Octopus Deploy
Features
Retrieve secrets from the Keeper Vault to use in Octopus Deploy Library
Inject credentials directly into Octopus Deploy projects
Get files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Octopus Deploy integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The Octopus Deploy integration accepts Base 64 format configurations
About
The Keeper Octopus Deploy Step Template utilizes Keeper Secrets Manager to provide access to secret credentials saved in the Keeper Vault. The script allows for injecting secrets directly into Octopus Deploy projects securely using Keeper's zero-knowledge infrastructure.
Installation
Community Step Template
To use the step template directly from Community Step Templates: Navigate: Library > Step Templates > Community Step Templates > Browse Library Search: "Keeper Secrets Manager - Retrieve Secrets" > Install > Save
Custom Step Template
To add as a Custom Step Template: Navigate: Library > Step Templates > Custom Step Templates > Import Paste the JSON obtained from community contributed templates library
Step Configuration
Settings
Name: Keeper Secrets Manager - Retrieve Secrets Description: This step retrieves one or more secrets from a Keeper Vault and creates sensitive output variables for each value retrieved. These values can be used in other steps in your deployment or runbook process. You can retrieve secrets using Keeper Notation URIs, and you can choose a custom output variable name for each secret. Required:
A Keeper Secrets Manager application with permissions to retrieve secrets from the Keeper Vault.
The
SecretManagement.Keeper.ExtensionPowerShell module installed on the target or worker. If the module can't be found, the step will fail. TheSecretManagement.Keepermodule(s) can be installed from the PowerShell gallery.
Parameters
Keeper Secrets Manager Configuration (type: Sensitive)
Variable name: #{Keeper.SecretsManager.RetrieveSecrets.Config}
Keeper Secrets Manager configuration for KSM Application with permissions to retrieve secrets from the Keeper Vault. To generate KSM Configuration in Web Vault: Secrets Manager - KSM Application Name - Edit - Add Device, and switch to Method: Configuration file, preferably in Base64 format.
Vault Secrets to retrieve (type: Multi-line text box)
Variable name: #{Keeper.SecretsManager.RetrieveSecrets.VaultSecrets}
Use Secrets Manager Notation URIs to specify the Secrets to be returned from Keeper Vault, in the format SecretsManagerNotation URI | OutputVariableName where:
OutputVariableNameis the optional Octopus output variable name to store the secret's value in. If this value isn't specified, an output name will be generated dynamically.
Multiple fields can be retrieved by entering each one on a new line. The line format is Notation | variable , where the variable name part is optional and if omitted auto generated variable names are used in the form of KsmSecret1, KsmSecret2, ...etc.
Print output variable names (type: Checkbox)
Variable name: #{Keeper.SecretsManager.RetrieveSecrets.PrintVariableNames}
Write out the Octopus output variable names to the task log.
Default: False
PowerShell Plugin
Utilize PowerShell's Secret Management module to access secrets with the Keeper Secrets Manager PowerShell Plugin
Features
Retrieve secrets from the Keeper Vault to use in PowerShell
Integrate Keeper vault with PowerShell Secrets Manager
Update secret values in the Keeper Vault from PowerShell
Get files from the Keeper vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager PowerShell integration. In order to utilize this integration, you will need:
Secrets Manager requires PowerShell version 6 or greater. Microsoft distributes PowerShell version 6+ as a separate application from versions 5 and earlier.
See Microsoft's Documentation for installation details
PowerShell Version 6.0 or later
See Microsoft's Documentation for installation details
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
About
The Keeper Secrets Manager PowerShell plugin utilizes Microsoft PowerShell's Secret Management module to inject secrets from the Keeper Vault into your PowerShell scripts.
The Keeper Secrets Manager extension can be easily configured added as a secret vault into new or existing PowerShell Secret Management workflows.
For more information about PowerShell Secret Management, see the PowerShell docs on their GitHub page.
Installation
1. Install PowerShell Secret Management Module
Keeper Secrets Manager uses the Microsoft.PowerShell.SecretManagement module to manage secrets in PowerShell.
Install using PowerShell:
See PowerShell Gallery for other installation options
2. Install Keeper Secrets Manager for PowerShell
Install the Keeper Secrets Manager PowerShell extension from the PowerShell Gallery.
See the PowerShell Gallery page for more installation options, or find the source code in GitHub.
To update SecretManagement, use the command: Update-Module -Name SecretManagement.Keeper
3. Install a PowerShell Secret Management Extension
If you already have a local secrets extension that you would like to use, you can skip this step
The Keeper Secrets Manager PowerShell plugin will need a secret management extension to store the plugin configuration locally to your machine.
Keeper recommends Microsoft.Powershell.SecretStore or SecretManagement.KeyChain
4. Register a Vault to use for Configuration Storage
If you already have a local secrets vault registered that you would like to use, you can skip this step
Register a secret vault for the previously installed secret management extension, so that the Keeper Secrets Manager plugin configuration can be stored.
The name of this vault will be used to register the Keeper extension. We used LocalStore in this example.
The Secret Management extension that you use for local storage may ask you to create a password for securely accessing the local vault.
Depending on your system settings, you may need to allow PowerShell to trust external modules. To do this, run the command:
set-executionpolicy remotesigned
5. Register the Keeper Vault
Register the Keeper Secrets Manager Vault using the local vault registered above to save your credentials, and a one time token to connect to Keeper.
Replace 'XXX' below with a one time token.
Alternatively you can use already generated config - replace 'XXX' below with a base64 encoded config.
6. Set Keeper Vault as Default Secret Storage (Optional)
Set the Keeper vault you just added as the default secret storage. This will tell the PowerShell SecretsManagement module to use your Keeper vault when getting and setting secrets.
This step is optional, but if you choose not to do it, you may receive secrets from your default vault if they have the same name, and you will need to add -Vault <keeper vault name> (e.g. -Vault keeper ) to Get-Secret, Set-Secret commands
The Keeper Secrets Manager PowerShell Plugin is now ready to be used
Source Code
Find the Keeper Secrets Manager PowerShell Plugin source code in the GitHub repository.
Usage
Find descriptions and examples of the most common usage of the Keeper Secrets Manager PowerShell plugin below.
For more information about PowerShell Secret Management commands, see the PowerShell docs on their GitHub page.
Starting with version 16.6.6 Get/Set commands allow use of \ as and escape character for dots in title. Use escape character only if there's dot in title, and escape both . and \ (ex. \., \\)
Listing Secrets
Run the following PowerShell command to see a list of secrets from Keeper
Use the name set for your Keeper secrets vault, in the examples above we use Keeper.
The secrets shown are any records shared with the Secrets Manager Application. The Name column displays each record's UID and title.
Getting a Single Secret
Get information and values of a single secret
Wrap the record name in quotation marks when there is a space in it.
-AsPlainText Shows the actual values of the secrets. Otherwise PowerShell shows them as a SecureString
Get a Value From a Secret
Utilize Keeper Dot Notation to identify a field to access. Note that you do not need the 'keeper://' prefix.
Set a Value to a Secret
Update the value of a single secret field
Download a File
Use dot notation to specify a file attached to a secret in the Keeper vault. Then pass that file to the Set-Content command to download it.
The specified file will be downloaded to the path location given to Set-Content
ServiceNow
Keeper credential storage integration with ServiceNow
About
The Management, Instrumentation, and Discovery (MID) Server integration with the Keeper Vault enables ServiceNow Orchestration, ServiceNow Discovery, and ServiceNow Service Mapping to dynamically retrieve credentials from the Keeper Vault without storing any credentials on the instance.
The instance maintains an unique identifier for every credential, along with its credential type (e.g., SSH, SNMP, or Windows) and any associated credential affinities. The MID Server obtains the credential identifier, credential type, and IP address from the instance, and then uses Keeper vault to resolve these elements into a usable credential.
Features
Use secrets from the Keeper vault as credentials for ServiceNow Orchestration, Discovery, and Service Mapping
Supports External Credential Storage for Discovery and Orchestration
Allows usage as a Custom Credential Provider
Use Cases
On-demand Discovery
Trigger: An admin in ServiceNow initiates a discovery process for newly added infrastructure.
Action: ServiceNow sends a request to the MID Server to start the discovery.
MID Server: Retrieves the necessary credentials (SSH, SNMP, etc.) from Keeper Vault and performs the discovery.
Result: The discovered assets are added to the ServiceNow Configuration Management Database (CMDB).
Incident Response
Trigger: An incident is created in ServiceNow, requiring immediate action on a specific server.
Action: ServiceNow triggers an orchestration workflow that involves the MID Server.
MID Server: Fetches the required credentials from Keeper Vault to log into the affected server and execute predefined remediation steps.
Result: The incident is resolved, and the actions taken are logged in ServiceNow.
Custom Credential Provider
Trigger: A custom application integrated with ServiceNow requires specific credentials for operation.
Action: The application queries ServiceNow for the required credentials.
MID Server: Intercepts the request, fetches the credentials from Keeper Vault, and provides them to the custom application.
Result: The custom application can proceed with its operation, using the credentials securely fetched from Keeper Vault.
Prerequisites
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper subscription
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
A ServiceNow instance with External Credential Storage plugin enabled
Setup
1. External Credential Storage (requires admin role)
The External Credential Storage plugin must be active.
The Enable External Credential Storage Discovery property is enabled.
System property:
A property called Enable External Credential Storage [com.snc.use_external_credentials] enables or disables the External Credential Storage plugin after it is activated. This property is located in Discovery Definition > Properties and Orchestration > MID Server Properties, and is enabled when you activate the plugin.
If you disable external credential storage with the system property, the system automatically sets all the external credentials to inactive in the instance. If you re-enable the feature with this property, the system does not reset the external credential records to active. You must reactivate each credential record manually.
2. Installing Keeper Credential Resolver
Download the latest version of Keeper Credential Resolver JAR file from here.
In ServiceNow, navigate to "MID server - JAR files" -> New
Manage Attachments -> upload Keeper Credential Resolver JAR
Fill in name, version etc. as desired
Click Submit
Navigate to "MID server - Properties" -> New
Set Name:
ext.cred.keeper.ksm_config, Value: base64 version of the configuration generated for the corresponding KSM Application.Optional: Set the property
ext.cred.keeper.ksm_label_prefixto the desired prefix (by default resolver usesmid_as a label prefix)Optional: Set the property
ext.cred.keeper.use_ksm_cacheto"true"to enable caching (use when you expect at least a few thousand requests per 10 seconds)
Alternatively you can edit config.xml directly (by default in /opt/servicenow/mid/agent/)add the keys and restart the server (setting the label prefix is optional - the default prefix is shown below)
<parameter name="ext.cred.keeper.ksm_config" secure="true" value="[KSM_CONFIG_BASE64_STRING]"/>
<!-- optional -->
<parameter name="ext.cred.keeper.ksm_label_prefix" value="mid_"/>
<!-- optional -->
<parameter name="ext.cred.keeper.use_ksm_cache" value="true"/>
Use secure="true" option for all sensitive parameters and remember to restart the server to encrypt the values.
3. Configuring discovery credentials
To consume Keeper vault credentials from your MID server, you will need to:
Create a secret in Keeper vault and share it to the corresponding KSM Application
Configure the resolver to use that secret
Creating a secret in Keeper vault and mapping fields
Keeper record types are dynamic and easy to customize, and there are no specific record types matching corresponding credential types in ServiceNow. Keeper External Credential Resolver uses custom field labels to match record data with MID Server's table columns (discovery_credential table) just label all required custom fields to match the table columns for a given credential type and prefix that label with "mid_" (see below how to configure custom prefix)
Credential types that require username/password should use records of type Login, and add any custom fields required by the credential type - ex. type=hidden, label="mid_pkey"
Any other types that may not have username/password is best to use File/Photo records which don't have any standard fields and that makes it easier to navigate the custom fields.
To change the custom field labels prefix update the config.xml in MID Server with the parameters below and restart the MID Server.
<parameter name="ext.cred.keeper.ksm_label_prefix" value="mid_"/>
Use custom fields with type text, multiline or hidden depending on the visibility you want in your Keeper Vault.
When Login record type is used any custom fields for username/password are ignored (even if properly labeled mid_user, mid_pswd) as these values always come from the Login record type standard fields - Login/Password.
When used with "External credential store" option the map keys returned from resolve method must conform to IExternalCredential interface from snc-automation-api.jar (values start with VAL_ prefix). Supported key values in current version (Utah): user, pswd, passphrase, pkey, authprotocol, authkey, privprotocol, privkey, secret_key, client_id, tenant_id, email - corresponding field labels should be prefixed with mid_ in Keeper records to be extracted and mapped properly.
When used as Custom External Credential Resolver any custom field could be mapped if properly prefixed in Keeper vault and present in corresponding credential type. The credential map returned from the resolve method is expected to have keys matching with the column names in discovery_credential table ex. sn_cfg_ansible, sn_disco_certmgmt_certificate_ca, cfg_chef_credentials, etc.
Examples:
Credential type
jdbc- map to Keeper record typeLogin(using standard Login/Password fields, no additional setup required)Credential type
api_key- map to Keeper record typeLoginand manually add custom fields of typehiddenwith labelsmid_ssh_private_key, andmid_ssh_passphrase(optional)Credential type
gcp- map to Keeper record typeFile Attachment/Photoand manually add the required custom fieldsmid_email- text,mid_secret_key- hidden.
Finding credentials in Keeper vault
Credential ID passed from MID Server to Credential Resolver must be either a valid record UID (22 alphanumeric characters incl. "-" and "_") or in the following format type:title The second format also allows searches by record type only or by title only (or both, but single ":" is invalid combination)
When using type:title format for the credential make sure there's only one matching record, since multiple matches result in error.
Using record UID is recommended to guarantee a single record match, and to avoid downloading all records with every single request to do local searches by type:title (due to the zero knowledge nature of the Keeper vault - searches must be local).
Examples (zero or two or more matches result in an error)
Find by Record UID - Credential ID:
ABCDABCDABCDABCDABCDABFind by type and title - Credential ID:
login:MyLoginFind by title - Credential ID:
:MyLoginFind by type - Credential ID:
login:
Configuring the resolver to use a secret
In the ServiceNow UI:
Navigate to "Discovery - Credentials" -> New
Select a credential type from the list
Tick "External credential store" check box. The Username and Password fields disappear, and the Credential ID field and Credential storage vault menu appear.
Fill in a meaningful name
Set "Credential ID" to the record UID of your secret or provide a search string in the form
type:titleor just:titleand make sure it resolves to a single recordFrom the Credential storage vault menu, you can select either None, the Keeper vault, or a custom external credential storage vault.
To use a custom external credential storage vault, navigate to Vault Configurations
[vault_configuration.list]in the instance.Create a new record using a name associated with an imported JAR file for a custom credential resolver.
Optional: Click "Test credential" and select a MID server and a target to test against to test everything is working
Throttles and cache
The plugin will try to resolve "throttled" errors by default by adding a random delays and retrying later, which works well for up to 1000-3000 requests per 10 sec interval (throttles start after 300-600 requests/10 sec) If you expect 5000+ requests in less than 10 seconds we recommend to enable caching by setting ext.cred.keeper.use_ksm_cache parameter to "true" in config.xml and restarting the MID Server. Cached data is stored in an encrypted file ksm_cache.dat in MID Server's work folder. Cache is updated at most once every 5 minutes or with the next request.
Troubleshooting
Check the logs
Check the log files inside logs/ in the agent installation folder for logs and errors. The resolver logs a line for each credential ID that it successfully queries, and also logs the fields that the credentials were extracted from.
If a particular credential ID is failing, search for that ID in the logs, and check that it is successfully queried and that the credentials were extracted from the fields you expected.
You will also find any exceptions that the resolver throws in the logs, including errors locating a record or finding fields, or if it couldn't communicate with Keeper vault.
Use the Test credential feature
When creating or configuring a credential in the ServiceNow UI, you should be able to click "Test credential" to perform a quick targeted test. Select the MID server that should query Keeper vault, and select a target that the credential should work for to check that everything works as expected. If it doesn't, check the logs for errors and debug information as detailed above.
Teller
Keeper Secrets Manager integration with Teller for dynamic secrets retrieval
Features
Retrieve secrets from the Keeper Vault within Teller environments
Set secret credentials as environment variables in Teller
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Teller integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The Teller integration accepts Base64 format configurations
Setup
Getting a Secrets Manager configuration
Using Keeper Commander, add a new client to an application and initialize the configuration to a Base64 string. This will be the long text hash that appears after the "Initialized Config:" label.
That value needs to be assigned to an environment variable with the name KSM_CONFIG.
Creating a Teller configuration
teller will pull variables from your Keeper Vault, and will populate your current working session so you can work safely and much more productively.
teller needs a tellerfile. This is a .teller.yml file that lives in your repo, or one that you point teller to with teller -c your-conf.yml.
Run teller new and follow the wizard, pick the providers you like and it will generate a .teller.yml for you.
Alternatively, you can use the following minimal template:
Running from command line
With a .teller.yml file in the current directory, or one that you point teller to with teller -c your-conf.ymlnow you can just run processes with:.
Using a GitHub Action
Add a teller step.
Full example below is using the default config file .teller.yml which can be replaced in the run command with a custom file that you point teller to with teller -c your-conf.yml.
TeamCity
Keeper Secrets Manager plugin for accessing secrets in TeamCity builds
About
TeamCity is a general-purpose CI/CD software platform that allows for flexible workflows, collaboration and development practices. A solution that will allow for successful continuous integration, continuous delivery, and continuous deployment within your DevOps process.
The plugin allows TeamCity servers (version 2018.1 or newer) to integrate with Keeper Secrets Manager to make managing secrets in TeamCity easier and more secure.
Features
Use secrets from the Keeper vault in TeamCity builds
Keeper Secrets Manager plugin installs as a TeamCity Connection
Prerequisites
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager add-on enabled for your Keeper subscription
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The TeamCity plugin accepts Base 64 format configurations
Installation
Installing Plugin from JetBrains Plugins Repository
Go to Administration | Plugins in TeamCity and click Browse plugins repository.
Find the Keeper Secrets Manager plugin, click Get, and then Install to http[s]://<teamcityUrl>.
Confirm the plugin installation by clicking Install.
To enable the plugin after installation, click the plugin context menu and select Load.
Installing Plugin via Web UI
Download the latest version of TeamCity KSM plugin ZIP file from here.
Go to the Administration | Plugins page and upload the plugin ZIP archive from your local machine using the corresponding link.
Installing Plugin Manually
Copy the ZIP plugin package into the
<TeamCity Data Directory>/pluginsdirectory. If you have an earlier version of the plugin in the directory (though the plugin package can be named differently), remove it.
Enabling Plugin
To enable the plugin after installation, click the plugin context menu and select Load. The plugin will be enabled without the server restart.
Uninstalling Plugin via Web UI
Go to Administration | Plugins, locate an external plugin in the list, click the arrow icon next to it, and select Delete.
Once the plugin is deleted, the option to restart the server appears on the page. Click it and check that the plugin version is no longer listed in Administration | Plugins.
Uninstalling Plugin Manually
Remove the plugin package from the
<TeamCity Data Directory>/pluginsdirectory and restart the TeamCity server.
Setup
Configuring Connections
When created, a connection can be used in all the nested subprojects of the current project. If you add a connection in the Root project, it will become available on the whole server.
To add a connection, go the target project's settings, open the Connections page, and click Add Connection. Select the connection type Keeper Vault, set its Display name to distinguish it from the others, and configure it as described below.
In Project Administration | Connections, click Add Connection.
Select Keeper Vault as the connection type.
Specify the token - paste a valid KSM config (see Prerequisites).
Save the connection.
Using secrets in TeamCity builds
To consume Keeper vault secrets from your TeamCity server, you will need to:
Create a secret in Keeper vault and share it to the corresponding KSM Application
Configure a TeamCity parameter that resolves the secret using Secrets Manager Notation URIs
Using Build Parameters in Build Configuration Settings
In most build configuration settings, you can use a reference to a build parameter instead of using the actual plain-text value. Before starting a build, TeamCity resolves all references with the available parameters. If there are references that cannot be resolved, they are left as is, and a respective warning appears in the build log. To reference a build parameter, use its name enclosed in percentage characters: for example, %env.KsmSecret1%.
Parameters tab allows adding, editing, and deleting new parameters/properties/variables, or redefining their predefined values.
Any text enclosed in percentage characters will be interpreted by TeamCity as a reference to a parameter. If the parameter cannot be found in the build configuration, this reference becomes an implicit agent requirement and such build configuration can only be run on an agent with this parameter defined. The agent-defined value will be used in the build.
If you want to prevent TeamCity from treating the text in the percentage characters as a reference to a parameter, use two percentage characters. Every occurrence of %% in the values where parameter references are supported will be replaced with % before passing the value to the build. For example, if you want to pass %Y%m%d%H%M%S into the build, change it to %%Y%%m%%d%%H%%M%%S.
Example Workflow
Define a build parameter on a build configuration level and use it in a build step.
Go to Build Configuration Settings | Parameters.
Click Add new parameter.
Enter the parameter's name and value. Change parameter's Kind to Environment variable (env.).
Name:
usernameValue:
%keeper://UserRecord1/fields/login%
Adding New Parameter
Save the parameter.
Go to Build Steps.
Click Add build step.
Choose the Command Line runner type.
In the Custom script field, enter the following command:
echo UserName %env.username%For a build, this command will be resolved as follows (note that actual value is masked in logs but used in actual commands):
Save the build step and run a new build.
The plugin accepts both Keeper Notation prefix keeper://NotationURI and TeamCity style prefix keeper:NotationURI in build parameters, environment variables etc. Check the examples below.
Parameter Examples:
Environment variable
env.User-keeper:abcdABCDabcdABCDuvwxyz/field/loginEnvironment variable
env.Secret-keeper://MyRecord1/custom_field/Secret1
Terraform Plugin
Keeper Secrets Manager Terraform plugin for accessing secrets in Terraform builds
Features
Retrieve secrets from the Keeper Vault to use in Terraform builds
Inject credentials directly into Terraform build scripts
Get Files from the Keeper Vault
For a complete list of Keeper Secrets Manager features see the Overview
Prerequisites
This page documents the Secrets Manager Terraform integration. In order to utilize this integration, you will need:
Keeper Secrets Manager access (See the Quick Start Guide for more details)
Secrets Manager addon enabled for your Keeper account
Membership in a Role with the Secrets Manager enforcement policy enabled
A Keeper Secrets Manager Application with secrets shared to it
See the Quick Start Guide for instructions on creating an Application
An initialized Keeper Secrets Manager Configuration
The Terraform integration accepts JSON and Base 64 format configurations
About
The Keeper Terraform Plugin utilizes Keeper Secrets Manager to provide access to secret credentials saved in the Keeper Vault. The Keeper Terraform plugin allows for injecting secrets directly into Terraform builds securely using Keeper's zero-knowledge infrastructure.
Installation
Registry install
The Keeper Secrets Manager provider page is located here
To install this provider, add the following code to your Terraform configuration and run terraform init:
Manual Installation
Download the latest version of the Terraform Provider for your platform from our GitHub release page and copy the archive to the corresponding Terraform plugin folder (creating any missing folders in the path). Initialize source with full provider URL: source = "github.com/keeper-security/secretsmanager"
For help on manually installing Terraform Providers, please refer to the official Terraform documentation.
Usage
Configure the Provider
The Keeper Secrets Manager provider is used to interact with the resources supported by Keeper Secrets Manager. The provider needs to be configured with Keeper credentials before it can be used.
Configuration File Contents
app_key- (Required) Application key.client_id- (Required) Client ID.private_key- (Required) Private key.hostname- (Optional) By default plugin will connect tokeepersecurity.com
For more information on creating a Secrets Manager configuration, see the Configuration Documentation
Get Secrets Using Data Sources
A data source is provided for each standard Keeper record type, which facilitates easy fetching of secret credentials.
Data sources are accessed using the following format:
For example, using a Login type record:
To access any additional custom fields or standard fields for user defined record types use secretsmanager_field data source
List of supported record types
"secretsmanager_address"
"secretsmanager_bank_account"
"secretsmanager_bank_card"
"secretsmanager_birth_certificate"
"secretsmanager_contact"
"secretsmanager_database_credentials"
"secretsmanager_drivers_license"
"secretsmanager_encrypted_notes"
"secretsmanager_field"
"secretsmanager_file"
"secretsmanager_health_insurance"
"secretsmanager_login"
"secretsmanager_membership"
"secretsmanager_passport"
"secretsmanager_photo"
"secretsmanager_record"
"secretsmanager_server_credentials"
"secretsmanager_software_license"
"secretsmanager_ssh_keys"
"secretsmanager_ssn_card"
To see the fields available to each data source see Record Types Data Source Reference
For more information on record types see record types documentation
Accessing Record Fields
To access a secret credential saved to a field in a record, access the field as part of the data source.
Access the field of a typed record data source
Use this format to access fields of a typed data resource
Example: access the password of a login type data source
Use the field data source to query any field in a record with Keeper Notation
Create a data source using the "secretsmanager_field" data source type, and specify a field query in the path property.
The field query uses the format: "<UID>/field/<field type>"
Creating Records With Resources
Keeper provides Terraform resources for the major Keeper record types shown above. Using these resources, Keeper records can be created using the Keeper Secrets Manager Terraform plugin.
To create a record, use the resource corresponding to the record type that you would like to use.
Each record resource requires at least a folder_uid and title as well as values for each record field.
Example login resource
Folder UID
To create records, Keeper Secrets Manager requires a folder UID so that it knows where to create the new records.
A folder UID can be found in the Keeper Vault or by using Keeper Commander.
The given folder must by accessible by the Keeper Secrets Manager Application being used by your Terraform plugin. The folder must also have at least one record in it before being used by Keeper Secrets Manager.
Title
The record title.
Record Fields
The value and settings for each record field can be set in the resource. For information on the available fields per record type, see the resource definitions.
Each field is represented as an object in the resource.
Example login field
Setting Field Values
Use the value field to set the intended value for each field. The format of fields can differ, for example the login field type takes a string, while the name field takes an object with "first", "middle" and "last" fields.
For reference of each field's value format see the resource documentation.
Setting Field Settings
Each field can be configured with various settings:
label
string
The field label
required
boolean
if True, the field will be considered required by the Keeper Vault
privacy_screen
boolean
if True, the field will be hidden in the Keeper Vault
Password Field
The password field has some special features.
Password Generation
Records created using the Terraform plugin can have a password generated automatically. To have the plugin generate a password, do not provide a value field to the password, and instead use generate = "True"
The password generation can be configured to generate a password of a specified length using the complexity field
Additionally, password fields have an extra configuration setting: enforce_generation which when true will make the Keeper Vault enforce that the password can only be generated and not set by a user.
To have Terraform regenerate a password, it needs to notice a difference in the generate field. To allow for triggering a difference, the generate field accepts both "true" and "yes" values. Change from one to the other to trigger a regeneration.
Examples
Read Credentials
This example provisions Keeper Secrets Manager, reads a login type data source, and accesses each field of the data source.
Create a Keeper Record
For more examples, check out the examples folder in the source code.
Windows Credential Manager
Store and Retrieve Secrets from the Windows Credential Manager
Overview
Windows Credential Manager is a native Windows utility that stores sensitive information, such as passwords and secrets, and allows applications to securely access it.
Keeper provides a utility, the Windows Credential Utility, that interacts with native windows APIs to store and retrieve secrets from the Windows Credential Manager. It can be used by any integration, plugin, or code base to store and retrieve credentials, secrets, and passwords in the Windows Credential Manager simply and natively.
The code base for the Windows Credential Utility can be found here:
The binary needed to use the above utility can be found here:
To use the Windows Credential Utility, you can either
deploy the pre-built binary from the releases page
or import it into your code base.
Both use cases are covered below.
Usage - Executable
Downloading the Executable
Download the latest version executable from the releases page and optionally add it to PATH to get started.
Using the Executable
The executable supports two commands:
setget
Both commands require an application name (i.e. the name of the credential in / to be stored in the Windows Credential Manager) as the first argument.
set
setset requires a second argument of the secret to be stored. This can be either a:
BASE64 string
JSON string
Path to an existing JSON file
When the secret is saved to Windows Credential Manager it is first encoded into a BASE64 format (if not already a BASE64 string). This standardizes the format for both consistent storage and to make it easier to consume by Keeper integrations and products.
get
getget returns the stored BASE64 encoded config to stdout and exits with a 0 exit code. The requesting integration can capture the output for consumption. Any errors encountered retrieving the config will return an non-zero exit code and write to stderr.
Example
XSOAR
Use Secrets Manager with automated workflows in Cortex XSOAR
About
Use credentials from your Keeper Vault in XSOAR workflows. Integrate with Keeper Secrets Manager to securely access all the platforms and services you connect to with XSOAR.
Setup
Activate Keeper Secrets Manager
Follow the Quick Start Guide to enable Keeper Secrets Manager on your account.
Create A Keeper Secrets Manager Configuration
Follow the steps in the documentation page to create a Secrets Manager configuration.
Configure Keeper Secrets Manager on Cortex XSOAR
In XSOAR, follow these steps to configure the Keeper Secrets Manager integration.
Navigate to Settings > Integrations > Servers & Services.
Search for "Keeper Secrets Manager"
Click Add instance to create and configure a new integration instance.
The following options are available to configure your XSOAR integration:
KSM Configuration (Required)
The KSM config to use for connection. Paste in the configuration generated by the steps above.
Trust any certificate
When 'trust any certificate' is selected, the integration ignores TLS/SSL certificate validation errors. Use to test connection issues or connect to a server without a valid certificate.
Fetches credentials
If selected, credentials are fetched from login records.
Concat username to credential object name
when selected, the username and credential name will be combined. Use to make the credential object unique in case of duplicate names in different folders/secrets.
A comma-separated list of credential names to fetch.
Partial names are not supported. If left empty, all credentials will be fetched.
Once configured, click Test to validate the URLs, token, and connection.
Available KSM Commands
The following commands can be used in XSOAR. Use these commands to fetch records and files from the Keeper Vault. Only records that are shared to the Secrets Manager Application can be accessed by these commands.
List Available Credentials
This command will only show records which can be used as credentials in XSOAR. Records must have a login and password to be used as a credential.
List Available Records
This command shows all records available to XSOAR through the KSM Application.
Get a Keeper Record by Title
add partial_match=True to use partial matching of the record title
Get a Value From a Keeper Record
See the Keeper Notation documentation for more details on using keeper notation to identify fields
List Files Attached to Keeper Records
Get a File from a Keeper Record
Find Records That Have Files Attached With Given Filename
Using Commands in a Playbook
To use Keeper Secrets Manager commands in your XSOAR playbooks, click "Task Library" and search for "Keeper" to show all the available commands.
Select a command to use and fill in the required fields if any.
Example: Get a Password From a Keeper Record
Fetch a password from the Keeper Vault to login to other services in your playbook.
Search for the "ksm-get-field" command and click to add it to your playbook
Enter Keeper notation pointing to the password using the UID of the record you want to use. This will look like:
<UID>/fields/password
Any field in a record can be fetched this way. See Keeper Notation documentation for more information
Click "OK" to add the task to your playbook
You can add additional tasks after the ksm-get-field task to use the password.