O DSM CLI é uma ferramenta consolidada para gerenciar os serviços oferecidos pela Segura. Esta utilidade permite que os serviços sejam utilizados por meio de linhas de comando, possibilitando automação via scripts. O objetivo principal desta ferramenta é ser um plugin agnóstico capaz de interceptar variáveis de ambiente e inserir secrets em sistemas e pipelines de CI/CD.
A natureza agnóstica do DSM CLI significa que ele pode ser usado em qualquer ambiente ou ferramenta de CI/CD. No entanto, o DSM CLI já possui algumas configurações adicionais, simplificando a integração com várias ferramentas.
Este plugin permite que as equipes de DevOps centralizem secrets e dados de aplicações de forma eficaz através do Segura DSM, estabelecendo uma abordagem segura para consumir variáveis sensíveis durante as fases de build e implantação.
Baixe a ferramenta do nosso repositório em Segura® DSM CLI.
DSM CLI como Running Belt
Se você não tem os arquivos runb
e senhasegura-mapping.json
, solicite-os à equipe de suporte da Segura.
Até o momento, o Segura DSM CLI só pode ser executado como um Running Belt. Em outras palavras, o DSM CLI irá ler os secrets do módulo Segura DSM e injetá-los como variáveis de ambiente.
Para implementar o plugin DSM CLI, você deve configurar uma aplicação com OAuth 2.0 e autorização no Segura DSM.
Após configurar a aplicação, faça o upload do executável para um diretório em seu ambiente ou ferramenta de CI/CD. Além disso, certifique-se de incluir um arquivo de configuração para autenticação no Segura DSM. O DSM CLI precisa de informações sobre a aplicação configurada, como seu nome, sistema e ambiente, para recuperar os secrets.
O arquivo de configuração deve estar no formato .yaml
e conter os seguintes detalhes sobre o Segura DSM:
SENHASEGURA_URL
: URL da sua Segura onde o DSM está habilitado.SENHASEGURA_CLIENT_ID
: ID do cliente para autorização de autenticação.SENHASEGURA_CLIENT_SECRET
: segredo do cliente para autorização de autenticação.
Exemplo de um arquivo .config.yaml
:
SENHASEGURA_URL: "<URL da Segura>"
SENHASEGURA_CLIENT_ID: "<ID do Cliente do Segura DSM>"
SENHASEGURA_CLIENT_SECRET: "<Segredo do Cliente do Segura DSM>"
SENHASEGURA_MAPPING_FILE: "<Arquivo de mapeamento de nomes de variáveis de secrets com caminho>"
SENHASEGURA_SECRETS_FILE: "<Nome do arquivo com caminho para injetar Secret>"
SENHASEGURA_DISABLE_RUNB: 0
Em vez de um arquivo de configuração, o DSM CLI pode obter informações de autenticação através de variáveis de ambiente, tornando o arquivo opcional.
Para usar o binário, você pode executar a seguinte linha de comando fornecendo as informações necessárias:
./dsm-cli --config /path/to/your/.config.yaml
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 essenciais, todas as variáveis de ambiente disponíveis durante a execução do pipeline são coletadas e encaminhadas para o Segura DSM.
Subsequentemente, todos os secrets registrados pela aplicação são consultados e integrados em um arquivo chamado .runb.vars
. Este arquivo pode ser enviado para o sistema para atualizar as variáveis de ambiente com os novos valores usando o seguinte comando: source .runb.vars
Isso permite que os desenvolvedores não se preocupem com a injeção de secrets durante os pipelines, uma vez que podem ser gerenciados diretamente através da API ou da interface do DSM, acessível a qualquer membro da equipe de desenvolvimento ou segurança.
Certifique-se de excluir o arquivo de variáveis de ambiente para evitar vazamento de dados.
Por padrão, o DSM CLI pode descobrir secrets e injetá-los em ferramentas como GitHub Actions, Jenkins e GitLab CI. Isso é feito automaticamente durante a execução do pipeline, facilitando a integração e o uso seguro de secrets em diferentes ambientes de CI/CD.
Você pode alterar a opção padrão com o argumento --tool-name
durante a execução.
DSM CLI para registrar secrets
O DSM CLI também permite criar ou atualizar valores de secrets diretamente do pipeline. Para isso, utilize um arquivo de mapeamento chamado senhasegura-mapping.json
. Este arquivo simplifica a identificação de variáveis sensíveis pelos seus nomes, registrando-as automaticamente como secrets no DSM.
A única configuração adicional necessária consiste em fornecer o arquivo de mapeamento, o executável e o arquivo de configuração. Abaixo está um exemplo do conteúdo do arquivo de mapeamento:
"access_keys": [
{
"name": "ACCESS_KEY_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": "GENERIC_VARIABLES",
"fields": ["KEY_VALUE_VARIABLE"]
}
]
}
Este arquivo pode ser dividido em três blocos principais
access_keys
: um array de objetos compostos pelos atributos nome, tipo e um subobjeto chamado fields. Este último é composto pelos atributosaccess_key_id
esecret_access_key
. Os valores desses atributos devem ser os nomes das variáveis que contêm os valores, permitindo que o Segura DSM valide a existência desses dados no módulo Cloud IAM. Se os dados existirem, serão registrados como um secret para a autorização fornecida. Caso contrário, serão registrados como key/value.credentials
: um array de objetos compostos pelo atributo nome e um subobjeto chamado fields. Este último inclui os atributosuser
,password
ehost
. Os valores desses atributos devem ser os nomes das variáveis que contêm essas informações, permitindo que o Segura DSM valide a existência desses dados no módulo PAM. Se os dados existirem, serão registrados como um secret para a autorização fornecida. Caso contrário, serão registrados como key/value.key_value
: um array de objetos compostos pelo atributo nome e um subobjeto fields. Os valores do array devem ser os nomes das variáveis a serem registradas como secrets do tipo key/value no Segura DSM.
- Este arquivo deve ser nomeado
senhasegura-mapping.json
e estar no mesmo nível de diretório que o executável. - Atualmente, o Segura DSM só suporta access keys via integração com AWS, Azure ou GCP, o que significa que o atributo tipo fornecido deve ser um dos suportados.
Ainda tem dúvidas? Entre em contato com a Comunidade Segura.