CLI
O DSM CLI é uma ferramenta unificada para gerenciar serviços do senhasegura. Com essa ferramenta, você poderá utilizar serviços através da linha 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.
Usando este plugin, as equipes de DevOps têm uma maneira fácil de centralizar 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.
Usando o DSM CLI como Running Belt
O CLI pode ser utilizado de duas principais formas: RunB e Kubernetes. Nesta seção vamos explicar o uso através da opção RunB.
Como um binário executável, sua instalação é bastante simples. Antes de implantar o plugin é importante 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 os guias de Aplicações e Autorizações.
A primeira coisa necessária é fazer o upload do executável em um diretório no seu ambiente ou ferramenta CI/CD juntamente com um arquivo de configuração para autenticação no senhasegura DSM. Depois disso, o DSM CLI precisa de informações do aplicativo configurado, como nome, sistema e ambiente, para que ele possa recuperar os segredos.
Para o arquivo de configuração, deve ser no formato .yaml contendo as seguintes informações do senhasegura DSM:
- SENHASEGURA_URL: A URL do seu senhasegura onde o DSM está habilitado;
- SENHASEGURA_CLIENT_ID: Um Client ID de uma autorização para autenticação.
- SENHASEGURA_CLIENT_SECRET: Um Client Secret de uma autorização para autenticação.
Examplo de um arquivo .config.yaml:
SENHASEGURA_URL: "<senhasegura URL>"
SENHASEGURA_CLIENT_ID: "<senhasegura Client ID>"
SENHASEGURA_CLIENT_SECRET: "<senhasegura Client Secret>"
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 utiizar o binário, você pode executar a seguinte linha de comando fornecendo as informações necessárias:
dsm runb \
--app-name <nome da aplicação> \
--system <nome do sistema> \
--environment <nome do ambiente> \
--config <caminho para o arquivo de configuração>
Ser agnóstico significa que o executável pode ser utilizado em qualquer ambiente ou ferramenta de CI/CD, porém o DSM CLI já vem com algumas configurações adicionais, permitindo que você se integre mais facilmente à sua ferramenta.
Após executar o binário com as informações necessárias, ele coletará todas as variáveis de ambiente dispiníveis nessa execução do pipeline e as enviará para o senhasegura DSM.
Em seguida, ele irá consultar todos os segredos cadastrados de uma 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 precisarão 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.
Certifique-se de excluir o arquivo de variáveis do ambiente para evitar vazamento de dados.
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.
Usando o DSM CLI como Kubernetes Sidecar
O DSM CLI também tem a opção de ser executado de forma semelhante a um Sidecar para Kubernetes, onde ele busca os segredos do senhasegura DSM e os injeta como arquivos em uma pasta definida pelo usuário (por padrão /var/run/secrets/senhasegura).
Este método também permite executá-lo como sidecar ou init-container. Como sidecar, o DSM CLI será executado continuamente, atualizando os segredos a cada 120 segundos, enquanto como init-container será executado apenas uma vez durante.
Você pode usar o seguinte comando para executá-lo como sidecar:
dsm kubernetes sidecar \
--app-name <nome da aplicação>
--system <nome do sistem> \
--environment <nome do ambiente> \
--config <caminho para o arquivo de configuração>
Ou o seguinte para executá-lo como init-container:
dsm kubernetes init-container \
--app-name <nome da aplicação>
--system <nome do sistem> \
--environment <nome do ambiente> \
--config <caminho para o arquivo de configuração>
A pasta padrão para injeção de segredo é /var/run/secrets/senhasegura/<identificador secreto>. Para injetar segredos na pasta padrão, certifique-se de executár o binário com privilégios administrativos.
No arquivo de configuração você pode definir o um valor para o SENHASEGURA_SECRETS_FOLDER com um caminho onde deseja que o plugin disponibilize os dados dos segredos, como no exemplo:
SENHASEGURA_URL: "<senhasegura URL>"
SENHASEGURA_CLIENT_ID: "<senhasegura Client ID>"
SENHASEGURA_CLIENT_SECRET: "<senhasegura Client Secret>"
SENHASEGURA_SECRETS_FOLDER: "<senhasegura Secrets Destination Folder>"
Usando o DSM CLI para Registrar Segredos
O uso da 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.
Para fazer isso, a única configuração adicional necessária é fornecer o arquivo de mapeamento junto com o executável e o arquivo de configuração. Aqui está 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 3 blocos principais:
- access_keys: Um array de objetos composto pelos atributos
name,typee um subobjeto chamadofields, onde este é composto por umaccess_key_ide umasecret_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 e, se existir, os registrará como segredo para essa autorização fornecida, caso contrário os mesmos serão registrados como chave/valor. - credentials: Um array de objetos composto pelo atributo
namee um sub-objetofields, onde este é composto poruser,passwordehost. 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 e, se existir, os registrará como Secret para essa autorização fornecida, caso contrário os mesmos serão cadastrados como chave/valor. - key_value: Um array de objetos composto pelo atributo
namee um sub-array defields, onde os valores do array devem ser o nome das variáveis a serem registradas como segredos do tipo chave/valor no senhasegura DSM.
Esse arquivo deve ser nomeado exatamente como senhasegura-mapping.json e deve estar no mesmo nível de diretório que o executável.
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.