DevOps Secret Manager CLI
  • 4 minutos de leitura
  • Tema escuro
    Tema claro
  • Pdf

DevOps Secret Manager CLI

  • Tema escuro
    Tema claro
  • Pdf

Article Summary

O DSM CLI é uma ferramenta unificada para gerenciar serviços do senhasegura. Com essa ferramenta, você pode utilizar serviços através de linhas de comando e automatizá-los usando scripts. O principal objetivo desta ferramenta é ser um plugin agnóstico para interceptar variáveis de ambiente e injetar segredos em sistemas e pipelines de CI/CD. 

Ser agnóstico significa utilizar o executável em qualquer ambiente ou ferramenta de CI/CD, porém o DSM CLI já vem com algumas configurações adicionais, as quais permitem que você se integre mais facilmente à sua ferramenta.

Com esse plugin, as equipes de DevOps centralizam facilmente dados de segredos e de aplicativos por meio do senhasegura DSM, fornecendo uma maneira segura para o aplicativo consumir variáveis sensíveis durante as etapas de build e deploy.

Obtenha a ferramenta através do nosso repositório senhasegura/dsmcli.


DSM CLI como Running Belt

Antes de implantar o plugin é fundamental ter um aplicativo configurado usando OAuth 2.0 e uma autorização no senhasegura DSM. Para obter mais informações sobre como registrar aplicativos e autorizações, consulte as instruções de Aplicações e Autorizações.

Depois, é necessário fazer o upload do executável em um diretório no seu ambiente ou ferramenta CI/CD com um arquivo de configuração para autenticação no senhasegura DSM. O DSM CLI precisa das informações do aplicativo configurado, como nome, sistema e ambiente, para recuperar os segredos.

O arquivo de configuração deve ser no formato .yaml com as seguintes informações do senhasegura DSM:

  • SENHASEGURA_URL: URL do seu senhasegura onde o DSM está habilitado;
  • SENHASEGURA_CLIENT_ID: Client ID de uma autorização para autenticação.
  • SENHASEGURA_CLIENT_SECRET: Client Secret de uma autorização para autenticação.

Exemplo de um arquivo .config.yaml:

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 path to inject Secret>"
SENHASEGURA_DISABLE_RUNB: 0
Info

Em vez de usar um arquivo de configuração, o DSM CLI pode obter informações de autenticação por meio de variáveis de ambiente, tornando o arquivo opcional.

Para utilizar o binário, você pode executar a seguinte linha de comando fornecendo as informações necessárias:

dsm runb \
    --application <nome da aplicação> \
    --system <nome do sistema> \
    --environment <nome do ambiente> \
    --config <caminho para o arquivo de configuração>

Após executar o binário com as informações necessárias, ele coleta todas as variáveis de ambiente disponíveis nessa execução do pipeline e as envia para o senhasegura DSM.

Em seguida, ele consulta todos os segredos cadastrados da aplicação, injetando-os em um arquivo chamado .runb.vars, que pode ser submetido ao sistema para atualizar as variáveis de ambiente com os novos valores através do comando abaixo:

source .runb.vars

Dessa forma, os desenvolvedores não precisam se preocupar em injetar segredos durante pipelines, por exemplo. Eles podem ser gerenciados diretamente via API ou pela interface DSM senhasegura por qualquer desenvolvedor, ou membro da equipe de segurança.

Cuidado

Certifique-se de excluir o arquivo de variáveis do ambiente para evitar vazamento de dados.

Info

Por padrão, o DSM CLI pode descobrir os segredos e injetá-los em ferramentas como GitHub, Azure DevOps, Bamboo, BitBucket, CircleCI, TeamCity e Linux (opção padrão). Você pode alterar a opção padrão com o argumento --tool-name durante sua execução.


DSM CLI para registrar segredos

O DSM CLI também permite que os desenvolvedores criem ou atualizem valores de segredos diretamente a partir da pipeline usando um arquivo de mapeamento chamado senhasegura-mapping.json. Esse arquivo facilita a identificação de variáveis sensíveis por meio de seus nomes e as registra automaticamente como segredos no senhasegura DSM.

A única configuração adicional necessária é fornecer o arquivo de mapeamento com o executável e o arquivo de configuração. Segue abaixo um exemplo do conteúdo do arquivo de mapeamento:

{
  "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"]
    }
  ]
}

Este arquivo pode ser dividido em três blocos principais:

  • access_keysarray de objetos, composto pelos atributos name, type e um subobjeto chamado fields, onde este é composto por um access_key_id e uma secret_access_key. Os valores desses atributos devem ser o nome das variáveis que contém os valores, para que o senhasegura DSM valide se os dados fornecidos existem no módulo Cloud IAM. Se os dados existirem, serão registrados como segredo para essa autorização fornecida. Caso contrário, os mesmos serão registrados como chave/valor.
  • credentials: array de objetos, composto pelo atributo name e um subobjeto fields, onde este é composto por user, password e host. Os valores desses atributos devem ser o nome das variáveis que contêm essas informações para que o senhasegura DSM valide se os dados fornecidos existem no módulo PAM. Se os dados existirem, serão registrados como segredo para essa autorização fornecida. Caso contrário, os mesmos serão registrados como chave/valor.
  • key_value: array de objetos, composto pelo atributo name e um subobjeto de fields. Os valores do array devem ser o nome das variáveis a serem registradas como segredos do tipo chave/valor no senhasegura DSM.
Cuidado

Esse arquivo deve ser nomeado como senhasegura-mapping.json e estar no mesmo nível de diretório que o executável.

Cuidado

Atualmente o senhasegura DSM suporta apenas chaves de acesso por meio de integração com AWS, Azure ou GCP, portanto o atributo type informado deve ser um dos suportados.


Este artigo foi útil?