DevOps Secret Manager CLI

The DSM CLI is a unified tool for managing senhasegura services. With this tool, you can use services through command lines and automate them using scripts. The primary purpose of this tool is to be an agnostic plugin for intercepting environment variables and injecting secrets into CI/CD systems and pipelines.

Agnostic means using the executable in any CI/CD tool or environment. However, the DSM CLI already has some additional settings, allowing you to integrate more easily with your tool.

With this plugin, DevOps teams easily centralize application and secret data through the senhasegura DSM, providing a secure way for the application to consume sensitive variables during the build and deploy stages.

Get the tool through our senhasegura/dsmcli repository.

DSM CLI as Running Belt

Before implementing the plugin, it is essential to have an application configured using OAuth 2.0 and authorization in senhasegura DSM. See the Applications and Authorizations instructions for more information on registering applications and authorizations.

Afterward, it is necessary to upload the executable in a directory in your environment or CI/CD tool with a configuration file for authentication in senhasegura DSM. The DSM CLI needs the configured application information, such as name, system, and environment, to retrieve the secrets.

The configuration file must be in .yaml format with the following senhasegura DSM information:

• SENHASEGURA_URL: The URL of your senhasegura where DSM is enabled;
• SENHASEGURA_CLIENT_ID: An authorization Client ID for authentication.
• SENHASEGURA_CLIENT_SECRET: An authorization Client Secret for authentication.

Example of a .config.yaml file:

SENHASEGURA_URL: "<senhasegura URL>"
SENHASEGURA_CLIENT_ID: "<senhasegura Client ID>"
SENHASEGURA_CLIENT_SECRET: "<senhasegura Client Secret>"
SENHASEGURA_MAPPING_FILE: "<secrets variable name mapping file with path>"
SENHASEGURA_SECRETS_FILE: "<file name with the path to inject secret>"
SENHASEGURA_DISABLE_RUNB: 0

To execute the binary, you can run the following command line providing the needed information:

dsm runb \
    --application <application name> \
    --system <system name> \
    --environment <environment name> \
    --config <path to config file>

After executing the binary with the necessary information, it collects all the environment variables available in this pipeline execution and sends them to senhasegura DSM.

Next, it consults all registered secrets of the application, injecting them into a file called .runb.vars, which can be submitted to the system to update the environment variables with the new values using the command below:

source .runb.vars

That way, developers don't have to worry about injecting secrets during pipelines, for example. They can be managed directly via the API or the senhasegura DSM interface by any developer or member of the security team.

DSM CLI to register secrets

The DSM CLI also allows developers to create or update secret values directly from the pipeline using a mapping file called senhasegura-mapping.json. This file facilitates the identification of sensitive variables through their names and automatically registers them as secrets in the senhasegura DSM.

The only additional configuration required is to provide the mapping file with the executable and configuration file. Below is an example of the contents of the mapping file:

{
  "access_keys": [
    {
      "name": "AWS_VARIABLES",
      "type": "aws",
      "fields": {
        "access_key_id": "AWS_ACCESS_KEY_ID_VARIABLE",
        "secret_access_key": "AWS_SECRET_ACCESS_KEY_VARIABLE"
      }
    }
  ],
  "credentials": [
    {
      "name": "CREDENCIAL_VARIABLES",
      "fields": {
        "user": "USER_VARIABLE",
        "password": "PASSWORD_VARIABLE",
        "host": "HOST_VARIABLE"
      }
    }
  ],
  "key_value": [
    {
      "name": "SECRET_VARIABLES",
      "fields": ["KEY_VALUE_VARIABLE"]
    }
  ]
}

This file can be broken down into three main blocks:

• access_keys: array of objects consisting of the attributes name and type, and the subobject fields, where this one is composed of an access_key_id and secret_access_key. The values of these attributes must be the name of the variables that contain the values so that senhasegura DSM validates whether the data provided exists in the Cloud IAM module. If the data exists, it records as a secret for this given authorization. Otherwise, it registers as a key/value.
• credentials: array of objects consisting of the attribute name, and the subobject fields, where this one is composed of user, password and host. The values of these attributes must be the name of the variables that contain this information so that senhasegura DSM validates whether the data provided exists in the PAM module. If the data exists, it records as a secret for this given authorization. Otherwise, it registers as a key/value.
• key_value: array of objects consisting of the attribute name, and the subobject fields. The array values must be the name of the variables to register as key/value type secrets in the senhasegura DSM.