Pular para o conteúdo principal
Version: 3.20

DSM

Introdução​

O módulo senhasegura DevOps Secret Management (DSM) permite o fácil gerenciamento de aplicações e de secrets em um ambiente DevOps.

Neste módulo, é possível gerenciar o ciclo de vida das Secrets e as aplicações e como estas se comunicam com o senhasegura DSM .

O administrador pode gerir os acessos das aplicações através das autorizações definindo políticas de acesso ao senhasegura DSM , além de gerenciar o ciclo de vida das secrets através de automações.

Por estar integrado a outros módulos da plataforma senhasegura , como o Cloud, PAM e Certificate Management, uma secret pode ser composta por Access Keys, Credenciais, Chaves SSH, Certificados e outras informações genéricas através da combinação de Chaves e Valores.

O time de desenvolvimento também pode realizar com facilidade integrações através de APIs e plugins de diferentes plataformas de conteinerização, CI/CD, automação de infraestrutura e configurações, serviços de provedores de cloud, dentre outros.

Dashboards​

O módulo senhasegura DSM possui uma seção de dashboards para visualização de dados como: Aplicações, Secrets, Variáveis, Deploys e outros. Para acessar todos os gráficos e boards deste módulo siga através do menu: DSM ➔ Dashboards. Nesta seção você irá encontrar os seguintes dashboards:

  • Secret Management;

  • Aplicação;

  • Variáveis CI/CD.

Secret Management​

No dashboard Secret Management é possível encontrar informações gerais sobre as aplicações e secrets gerenciadas pelo módulo senhasegura DSM .

Secret Management dashboard

Ele conta com as seguintes informações:

  • Quantidade de linhas de negócio;

  • Quantidade de tipos de aplicações;

  • Quantidade de aplicações;

  • Quantidade de autorizações;

  • Quantidade de secrets;

  • Gráfico de pizza de aplicações por linha de negócio;

  • Gráfico de pizza de aplicações por tipo;

  • Gráfico de pizza de autorizações por ambiente;

  • Gráfico de pizza de autorizações por aplicação;

  • Gráfico de linha de consultas de secrets por data;

caution

Com exceção da Quantidade de linhas de negócio e da Quantidade de tipos de aplicações, as informações são afetadas pelos filtros de Ativo e Período.

Aplicação​

No dashboard Aplicação é possível encontrar informações sobre uma aplicação específica gerenciada pelo módulo senhasegura DSM .

Aplicação dashboard

Ele conta com as seguintes informações:

  • Nome da aplicação;

  • Linha de negócio da aplicação;

  • Tipo da aplicação;

  • Estado do recurso de Provisionamento Automático de Secrets;

  • Data de cadastro da aplicação;

  • Quantidade de autorizações ativas;

  • Quantidade de ambientes da aplicação;

  • Quantidade de sistemas da aplicação;

  • Quantidade de secrets ativas;

  • Quantidade de credenciais nas secrets;

  • Quantidade de chaves de acesso nas secrets;

  • Gráfico de pizza de autorizações por ambiente;

  • Gráfico de pizza de autorizações por sistema;

  • Gráfico de linha de autorizações criadas nas últimas 24 horas;

  • Gráfico de linha de consulta de secrets por data;

  • Gráfico de barra de consulta de secrets por dia da semana;

caution

Os dados podem ser filtrados por status e intervalo de datas. Os "números dos tipos de negócios" e "números dos tipos de aplicação" só podem ser filtrados por intervalo de horas.

Variáveis CI/CD​

No dashboard Variáveis CI/CD é possível encontrar informações sobre as variáveis que trafegam nos ambientes das aplicações.

Variables dashboard

Estas variáveis são enviadas ao senhasegura através de plugins para ferramentas de CI/CD e/ou através de chamadas via API.

Este dashboard conta com as seguintes informações:

  • Quantidade de variáveis;

  • Quantidade de variáveis sensíveis;

  • Quantidade de aplicações;

  • Quantidade de sistemas;

  • Quantidade de ambientes;

  • Quantidade de deploys;

  • Gráfico de barra de deploys nos últimos 15 dias;

  • Gráfico de pizza de deploys por aplicação;

  • Gráfico de pizza de deploys por sistema;

  • Gráfico de pizza de deploys por ambiente;

  • Gráfico de barras de deploys por horário do dia;

  • Gráfico de barras de variáveis recebidas por data;

  • Gráfico de pizza de variáveis por aplicação;

  • Gráfico de pizza de variáveis sensíveis;

  • Gráfico de pizza de variáveis por sistema;

  • Gráfico de pizza de variáveis por ambiente;

caution

Os dados podem ser filtrados por status e intervalo de datas. Os "números dos tipos de negócios" e "números dos tipos de aplicação" só podem ser filtrados por intervalo de horas.

info

Sao consideradas Variáveis Sensíveis aquelas que contenham as seguintes palavras: TOKEN, PASSWORD, USER, SECRET_ACCESS_KEY, ACCESS_KEY_ID, USERNAME, SECRET, CLIENT_ID, CLIENT_SECRET

Secrets​

Uma secret é um conjunto de informações sensíveis, como credenciais, chaves de acesso, certificados, chaves SSH, tokens de APIs ou um par de chave e valor.

As secrets podem ser consumidas por aplicações ou scripts através de chamadas de APIs utilizando as autorizações com políticas de acesso e através de automações criadas diretamente na solução, onde ativamente as secrets serão injetadas, rotacionadas e excluídas sem a necessidade de alteração no código das aplicações.

Cadastrar secret​

Para cadastrar uma secret siga o menu: DSM ➔ Secret Management ➔ Secrets

  1. Clique no botão de ações e selecione a opção Novo segredo.

    Formulário de cadastro de secret

  2. Na aba Principal, preencha os seguintes campos:

    • Name: Nome da secret para gestão dentro do senhasegura ;

    • Identity: Identificador da secret. É através deste identificador que as aplicações conseguiram encontrar o arquivo ou variável que será criado;

    • Enabled: Indicador se essa secret está disponível para ser utilizada pelas aplicações;

    • Expiration date: Data em que a secret será automaticamente inativada;

    • Engine: Engine a ser utilizada;

    • Description: Descrição de uso da secret alinhada a regra de negócio do cliente. Não terá uso pelas aplicações;

  3. Na aba Access Keys selecione as chaves de acesso que farão parte da secret;

  4. Na aba Credentials selecione as credenciais que farão parte da secret;

  5. Na aba Key/Value insira um par de chave e valor sensível. O nome e valor devem obedecer os critérios das aplicações e ambientes onde serão publicadas;

  6. Para finalizar clique em Save;

Visualizar secrets​

Para visualizar as secrets siga o menu: DSM ➔Secret Management ➔Secrets.

Nesta tela, você pode visualizar as secrets existentes junto com informações como Engine, identificador, status, versão e data de expiração.

Relatório Secrets

Visualizar versões de uma secret​

Para visualizar as secrets siga o menu: DSM ➔Secret Management ➔Secrets.

  1. Na coluna ação da linha da secret, clique na opção Versão Secret;

    Versão Secret

  2. Na tela apresentada, clique no botão View history da versão que deseja visualizar;

  3. Por fim, clique no ícone View information para visualizar a informação;

Aplicações​

Cadastrar aplicações permitirá criar e gerenciar autorizações, que darão acesso aos recursos do senhasegura DSM e também possibilitará consumir secrets via API.

Cadastrar aplicação​

Para cadastrar uma aplicação siga para o menu: DSM ➔ Aplicações ➔ Aplicações

  1. Nas ações da página, clique na opção Nova;

    Formulário de configuração de aplicação

  2. Na aba Configurações preencha os seguintes campos:

    • Nome da aplicação: Nome da aplicação. Será utilizado para identificação nas telas de relatório, logs e dashboards;

    • Método de autenticação: Tipo de autenticação que será utilizada. As opções são:

      • OAuth 1.0: A aplicação cliente utilizará o WebService A2A através de autenticação OAuth 1.0;

      • OAuth 2.0: A aplicação cliente utilizará o WebService A2A através de autenticação OAuth 2.0;

    • Ativado: Defina se a aplicação estará ativa ou não;

    • Line of Business: Defina a linha de negócio que a aplicação atende. Esta propriedade é utilizada apenas no senhasegura para relatórios, dashboards e segregações;

    • Tipo de aplicação: Tipo de aplicação. Utilizado apenas no senhasegura para relatórios, dashboards e segregações. E.g.: Business, DevOps, Security;

    • Tags: Utilizado para filtros, dashboards e segregações;

    • Descrição: Adicione uma descrição detalhada da aplicação;

  3. Na aba Automatic provisioning preencha ative o provisionamento automático, caso queira e preencha os seguintes campos:

    • Cloud dynamic provisioning profile: Selecione o perfil de provisionamento criado no módulo senhasegura Cloud;

    • Credential dynamic provisioning profile: Selecione o perfil de provisionamento criado no módulo senhasegura PAM;

  4. Para finalizar clique em Save;

caution

Utilize sempre tipos de autenticações modernos que garantam a integridade dos dados. A possibilidade de autenticar se através de OAuth 1.0 existe por impossibilidade de atualizações de aplicações legadas. Desencorajamos o uso.

info

Provisionamento automático permite que secrets com credenciais e chaves de acesso sejam geradas e excluídas automaticamente a partir da criação e inativação de uma autorização. Saiba mais na sessão Provisionamento automático de secrets deste manual.

Visualizar aplicações​

Para visualizar as secrets siga o menu: DSM ➔ Aplicações ➔ Aplicações.

Relatório de aplicação

Nesta tela, você pode visualizar as aplicações existentes junto com informações como nome, descrição, sistemas, ambientes, linha de negócio, tipo de aplicação, tags, status, método de autenticação, data de criação.

Visualizar autorizações da aplicação​

Para visualizar as autorizações de uma aplicação siga o menu: DSM ➔ Aplicações ➔ Aplicações.

Na coluna ação da linha da aplicação, clique na opção Authorizations. Nesta tela, você pode visualizar as autorizações da aplicação junto com informações como: Nome da aplicação, Ambientes, Sistemas, Data de criação e Status;

Autorizações de aplicação

Autenticadores​

Autenticadores são uma forma segura de intermediar a confiança entre diferentes aplicações com o propósito de trocar segredos e gerenciar autorizações e funções relacionadas. O senhasegura proporciona integração com os autenticadores mais utilizados, conforme descrito na seção seguinte.

Autenticador OAuth 1.0​

OAuth 1.0 é um método de autenticação que consiste no uso de quatro tokens para identificar e autorizar o acesso de um aplicativo.

caution

Utilize sempre tipos de autenticações modernos que garantam a integridade dos dados. A possibilidade de autenticar se através de OAuth 1.0 existe por impossibilidade de atualizações de aplicações legadas. Desencorajamos o uso.

Configuração do Autenticador OAuth 1.0​

Para utilizar este método de autenticação, siga estes passos:

  1. Ir para DSM ➔Aplicações ➔Aplicações;

  2. Edite ou crie uma Nova aplicação e selecione o método de autenticação OAuth 1.0;

Formulário de configuração da aplicação - OAuth 1.0

Quando um recurso precisa usar um segredo, ele pode usar suas fichas OAuth 1.0 para solicitar as informações da senhasegura .

Se os dados utilizados forem válidos, o senhasegura deixará a aplicação interagindo com os segredos e autorizações da senhasegura DSM .

Confira nosso manual WebService A2A para uma descrição completa dos Métodos REST senhasegura DSM .

Autenticador OAuth 2.0​

OAuth 2.0 é um método de autenticação que consiste em usar um ID de cliente e um segredo de cliente para solicitar um token de tempo limitado e usá-lo para acessar os recursos senhasegura .

Configurando o OAuth 2.0 Authenticator​

Para utilizar este método de autenticação, siga estes passos:

  1. Ir para DSM ➔ Aplicações ➔ Aplicações;

  2. Edite ou crie uma Nova aplicação e selecione o método de autenticação OAuth 2.0;

Formulário de configuração da aplicação - OAuth 2.0

Quando um recurso precisa usar uma secret, ele pode usar seus clientes OAuth 2.0 para solicitar um token de tempo limitado e usá-la para solicitar as informações do senhasegura .

Se o token utilizada for válido, o senhasegura deixará a aplicação interagindo com as secrets e autorizações da senhasegura DSM .

Confira nosso manual WebService A2A para uma descrição completa dos Métodos REST senhasegura DSM .

Autorizações e políticas de acesso​

Nas autorizações o administrador poderá definir as políticas de acesso ao senhasegura DSM . Também é possível definir políticas de acesso, como:

  • Quais recursos podem ser acessados;

  • Data de expiração da autorização;

  • IPs permitidos nas requisições;

  • Endereço de origem da requisição;

  • Ambiente em que a autorização será utilizada;

  • Sistema em que a autorização será utilizada;

  • Secrets que podem ser acessadas;

Uma aplicação pode ter mais de uma autorização com políticas de acesso distintas.

Cadastrar autorização​

Para cadastrar uma autorização siga para o menu: DSM ➔ Aplicações ➔ Autorização por aplicação

  1. Na coluna ação, na linha da aplicação que deseja, clique na ação Nova autorização.

    Caso a aplicação para qual deseja criar uma autorização não apareça no relatório, limpe o filtro;

    Formulário de configuração de autorização

  2. Preencha os seguintes campos na aba Configurações:

    • Expiration date/time: Determine a data e hora em que a autorização será automaticamente revogada;

    • Ativado: Determine se a autorização está ativa para uso ou não;

    • Ativar a criptografia de informações sensíveis?: Utilize para determinar se os dados sensíveis, como senhas, serão retornados criptografados para a aplicação;

      • Caso esteja habilitado, após salvar a autorização, exporte a chave para descriptografar os dados indo em: DSM ➔ Aplicações ➔ Autorização por aplicação;

      • Na coluna ação da autorização, clique em Download public key;

    • Environment: Determine o ambiente da autorização. Será utilizado apenas para controle interno do senhasegura . Não irá influenciar no uso da aplicação;

    • System: Determine o sistema da autorização. Será utilizado apenas para controle interno do senhasegura . Não irá influenciar no uso da aplicação;

    • Allowed IPs: Relação de IPs, separado por vírgula, que tem permissão para utilizar esta autorização. Utilize o caractere curinga * para permitir intervalos de IPs. E.g.: 192.168.1.*;

    • Allowed HTTP referers: HTTP referers da aplicação cliente. Será validado se existir;

  3. Na aba Secrets selecione quais secrets estão relacionadas à autorização;

  4. Para finalizar clique em Save;

Visualizar clientes de API da autorização​

Para cadastrar uma secret siga o menu: DSM ➔ Aplicações ➔ Autorização por aplicação.

Na linha da autorização que deseja visualizar os clients, clique na ação View Authorization.

Por fim, clique no ícone View information para visualizar as informações.

Detalhes da autorização

CI/CD​

O menu CI/CD exibe informações como variáveis e deploys interceptados pelo senhasegura DSM através de integrações com ferramentas como GitLab, GitHub, Azure DevOps, Jenkins, dentre outras.

Estas informações são úteis para identificar secrets que estejam sendo utilizadas por aplicações, mas não estão sendo gerenciadas pelo senhasegura DSM .

Variáveis​

Relatório de variáveis

Neste relatório são exibidas todas as variáveis interceptadas pelo senhasegura DSM através de seus plugins e integração via API.

Estas variáveis podem possuir ou não informações sensíveis, como, nomes de usuários, senhas, chaves de acesso, chaves SSH dentre outras. Neste relatório é possível encontrar as seguintes informações:

  • Nome da variável;

  • Status da aprovação;

  • Nome da aplicação;

  • Sistema;

  • Ambiente;

  • Data de criação;

Visualizar detalhes da variável​

Para visualizar o detalhes de uma variável siga o menu: DSM ➔ CI/CD ➔ Variáveis. Na coluna ação da linha da variável, clique na opção Variable details.

info

O senhasegura DSM é capaz de identificar algumas variáveis como sendo sensíveis, por exemplo, AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY e automaticamente criar uma secret para que elas possam ser facilmente gerenciadas na solução.

Detalhes de uma variável

Deploys​

Neste relatório são exibidos os deploys identificados pelo senhasegura DSM através de seus plugins e integração via API. Neste relatório é possível encontrar as seguintes informações:

  • Nome da aplicação;

  • Sistema;

  • Ambiente;

  • Data do deploy;

Relatório de deploys

Automações​

O senhasegura DSM permite a criação de automação para gestão ativa do ciclo de vida das secrets em aplicações como, Kubernetes e serviços de cloud como Google Cloud Manager, Azure Key Vault dentre outros.

As automações são baseadas em triggers, como, a partir da criação ou atualização de uma secret. As triggers são:

  • Criação de uma secret;

  • Atualização de uma secret;

  • Ativação de uma secret;

  • Inativação de uma secret;

  • Criação de uma autorização;

  • Atualização de uma autorização;

  • Ativação de uma autorização;

  • Inativação de uma autorização;

O módulo de automação já conta com diversos conectores pré-definidos para facilitar o uso do recurso, mas novos podem ser facilmente criados a partir de templates.

As automações podem ser utilizadas para - mas não limitadas à estes casos - adicionar, atualizar e excluir secrets:

  • em banco de dados;

  • em arquivos de configuração de uma aplicação ou servidor;

  • nas secrets do Kubernetes, OpenShift ou outro serviço Kubernetes;

  • em serviços de cloud como Google Secret Manager;

As automações podem também executar Playbooks Ansible dentro de containers Dockers para garantir mais segurança e permitir maiores possibilidades de integrações.

Criar automação​

Para criar uma automação, siga o menu: DSM ➔ Automações ➔ Automações

Configurar trigger de uma automação

  1. Clique no botão de ações e selecione a opção Novo;

  2. Determine os campos gerais da automação:

    • Nome: Será o nome da automação. Este nome será utilizado internamente no senhasegura para identificação em outras telas;

    • Ativado: Indica se a automação está disponível para uso;

  3. Na aba Informação, preencha os seguintes campos:

    • Descrição: Uma descrição detalhada sobre a automação;

    • Tags: Utilizadas em filtros e segregações dentro do senhasegura ;

  4. Na aba Gatilho preencha os campos:

    • Gatilho: São os gatilhos de evento que irão disparar a automação. Selecione uma ou mais opções;

    • Aplicação: Selecione uma ou mais aplicações em que as triggers deverão estar associadas. Desta forma as triggers selecionadas serão aplicadas apenas nas aplicações selecionadas;

    • Secret: Selecione uma ou mais secrets em que as triggers deverão estar associadas. Desta forma as triggers serão aplicadas nas credenciais selecionadas;

  5. Na aba Ação preencha os campos:

    • Plugin: que o template que será executado utiliza;

    • Template: selecione o template, dentre as opções disponíveis, com os comandos de execução da automação;

    • Dispositivo: selecione os dispositivos onde o template deverá ser executado;

  6. Para finalizar clique em Salvar

info

É possível criar novos templates para integração com outras soluções ou outros casos de uso de forma simples.

Visualizar automações​

Para visualizar as secrets siga o menu: DSM ➔ Automações ➔ Automações.

Relatório de automações

Nesta tela, você pode visualizar as automações existentes junto com informações como name, tags, applications da automação, secrets da automação, creation date, last execution date and status.

Visualizar detalhes de execução da automação​

Para visualizar o resultado de execução de uma automação, siga o seguinte menu: DSM ➔ Automações ➔ Execuções. Na coluna ação da linha da execução, clique na opção Details

Detalhes da execução de uma automação

Na sessão Execution clique no ícone Execution details para visualizar os detalhes de execução do template.

Por segurança, nos detalhes da execução do template as informações sensíveis, como senhas e chaves de acesso, são substituídas por 8 asteriscos (*).

Injetar e rotacionar secrets no Azure Key Vault, AWS Secret Manager, Google Secret Manager e Kubernetes​

Criei uma automação seguindo os passos descritos na sessão Criar automação mais acima e na aba Action selecione o template correspondente à solução que deseja integrar:

Azure Key Vault = Azure Key Vault - Inject Secret

AWS Secret Manager = AWS Secret Manager - Inject Secret

Google Secret Manager = Google Secret Manager - Inject Secret

Kubernetes = Kubernetes - Inject Secret

Provisionamento dinâmico de secrets Just in Time (JIT)​

Para garantir o maior nível de segurança em ambientes elásticos, o senhasegura DSM permite o provisionamento e desprovisionamento automático just in time de secrets e provedores de cloud e ambientes e sistemas. Este cenário é mais utilizado para ambientes efêmeros e dinâmicos, onde há o desejo de criação de secrets Just In Time (JIT).

Configurar provisionamento dinâmico de chaves de acesso em Provedores de Cloud​

Chaves de acesso são credenciais utilizadas por aplicações e scripts para acessar serviços de provedores de cloud como AWS, Azure, Google Cloud dentre outros.

O senhasegura DSM permite o provisionamento dinâmico de chaves de acesso nos principais provedores como AWS, Azure e Google Cloud através dos perfis de provisionamento.

Para criar um perfil de provisionamento dinâmico, acesse o menu: Cloud ➔ Cloud IAM ➔ Provisionamento dinâmico ➔ Perfis.

Formulário de criação de perfil de provisionamento de chave de acesso

  1. Clique no botão de ação do relatório Add profile;

  2. Preencha os seguintes campos do formulário;

    • Identifier: Insira um termo para que este perfil seja de fácil identificação nos relatórios. O nome dos usuários também irá possuir este identificador mais uma string baseada em tempo;

    • Enabled: Indique se ele estará ativo para o uso;

    • Account: Selecione a conta do provedor onde os usuários e chaves de acesso deverão ser criadas;

    • Policies: Selecione quais são as políticas que este usuário deverá possuir;

    • Default TTL: Defina o tempo de vida do usuário. Após o fim deste período ele será automaticamente excluído pelo senhasegura no provedor;

  3. Para finalizar, clique em Salvar;

Após a criação do perfil de provisionamento dinâmico de chaves de acesso, relacione-o à uma aplicação em DSM ➔ Aplicações ➔ Aplicações editando uma existente ou criando uma nova. Visite a sessão Cadastrar aplicação deste manual para saber mais detalhes.

Configurar provisionamento dinâmico de credenciais​

O senhasegura DSM permite o provisionamento dinâmico de credenciais em diversos sistemas e dispositivos como bancos de dados, como MySQL, Oracle e SQL server, servidores linux e windows e outros serviços.

Acesse o relatório de Dynamic provisioning através do menu PAM ➔ Dynamic provisioning ➔ Profile.

Formulário de criação de perfil de provisionamento de credencial

  1. Clique no botão de ação do relatório Novo perfil;

  2. Preencha os seguintes campos do formulário:

    • Identificador: Insira um termo para que este perfil seja de fácil identificação nos relatórios;

    • Ativado: Indique se ele estará ativo para o uso;

    • Type: Indique o tipo de sistema que este profile representa. As opções são pré-definidas.

      • Linux;

      • MySQL;

      • Oracle;

      • SQL Server;

      • Windows;

    • Credential for execution: Defina qual credencial deverá ser utilizada para se conectar nos dispositivos onde o perfil será executado;

    • Templates: São os templates para o Type selecionado. Contém as regras de execução para determinadas ações. Selecione dentre as opções:

      • Criação da credencial;

      • Exclusão da credencial;

    • TTL: Defina o tempo de vida da credencial. Após o fim deste período ela será automaticamente excluída pelo senhasegura no destino;

  3. Para finalizar, clique em Confirmar;

Após a criação do perfil de provisionamento dinâmico de credenciais, relacione-o à uma aplicação em DSM ➔ Aplicações ➔ Aplicações editando uma existente ou criando uma nova. Visite a sessão Cadastrar aplicação deste manual para saber mais detalhes.

Discovery de artefatos DevOps​

No senhasegura , os times de segurança e DevOps podem contar com uma poderosa ferramenta de discovery. Com ela é possível realizar a descoberta de diversos artefatos de um ambiente, como, Containers, Roles, Users e Secrets em ferramentas como Ansible, Jenkins e Kubernetes.

Containers Docker​

Docker é uma tecnologia que permite aos desenvolvedores empacotar, entregar e executar aplicações em containers Linux leves e autossuficientes.

Configurar discovery de containers Docker​

Para configurar um discovery de containers, acesse o menu Discovery ➔ Configurações ➔ Discovery.

  1. Clique no botão de ação do relatório Novo;

  2. Na janela apresentada, clique na opção Containers;

  3. Preencha os seguintes campos:

    • Nome: Preencha o nome do discovery para identificação no senhasegura em relatórios;

    • Container host: Insira o IP ou nome do dispositivo do controlador. Este é o dispositivo onde os containers estão hospedados. Todos os nomes de host de container registrados serão listados;

    • Ativo: Indique se esta configuração de discovery estará ativo para o uso;

  4. Na aba Conexão, preencha os seguintes campos:

    • Credencial de acesso: Selecione a credencial que será utilizada para autenticação no host;

  5. Na aba Containers, preencha os seguintes campos:

    • Buscar somente containers em execução?: Defina se irá buscar todos os containers ou apenas os que estiverem em execução no momento;

  6. Na aba Plugins, , defina os plugins que serão utilizados no discovery e as portas que serão utilizadas. Os plugins possuem a inteligência necessária para realizar a conexão com os dispositivos e realizarem dos discoveries. Algumas das opções de plugins para este tipo de discovery são:

    • Unix/Linux;

    • Windows;

    Na aba Execução, defina a frequência do discovery. As opções são:

    • Manter scan ativo após importação?: Defina se o discovery deverá continuar em execução, mesmo após a descoberta e importação dos containers;

    • Dias permitidos para execução: marque quais dias da semana em que o discovery será executado;

    • Períodos permitidos para execução: marque os períodos do dia em que o discovery será executado com as seguintes faixas de horas:

      • 8:00 AM - 12:00 PM;

      • 12:00 PM - 4:00 PM;

      • 4:00 PM - 8:00 PM;

      • 8:00 PM - 12:00 AM;

      • 12:00 AM - 4:00 AM;

      • 4:00 AM - 8:00 AM;

    • Intervalo mínimo entre as execuções: Selecione intervalo em horas entre uma execução e outra;

  7. Para finalizar, clique no botão Salvar;

Visualizar containers Docker​

Para visualizar as informações dos containers encontrados nos Discoveries, vá para Discovery ➔ Devops ➔ Containers.

Relatório de Containers

Nesta tela, você pode visualizar os containers encontrados junto com informações como código, imagem, criação, estado, IP e host do container.

Kubernetes e OpenShift​

Kubernetes é um orquestrador de contêineres que tem muitas maneiras de compartilhar informações entre seus contêineres ativos. Para abstrair a tecnologia sobre a qual a aplicação alvo foi construída, Kubernetes recomenda usar variáveis do sistema e o sistema de arquivos, que pode ser compartilhado ou não, para fornecer os dados sensíveis que a aplicação precisa para executar suas tarefas.

Configurar discovery de secrets Kubernetes e OpenShift​

Para configurar um discovery de secrets no Kubernetes e no OpenShift, é necessário que exista uma credencial cadastrada no senhasegura PAM com um token de acesso à API do cluster com permissão para listar e consultar as secrets. Para gerar o token, siga as instruções descritas na seção dsm-token-kubernetes deste manual.

Para configurar um discovery de secrets no Kubernetes, acesse o menu: Discovery ➔ Configurações ➔ Discovery.

  1. Clique no botão de ação do relatório Novo;

  2. Na janela apresentada, clique na opção Dispositivo;

  3. Na janela que abrir, preencha os seguintes campos:

    • Nome: será o nome do discovery cadastrado para identificação no senhasegura em relatórios;

    • IP Inicial: será o endereço de IP inicial do cluster de Kubernetes. Dispositivo onde as secrets estão hospedadas;

    • IP Final: será o endereço de IP final do cluster de Kubernetes. Dispositivo onde as secrets estão hospedadas;

    • Ativo: indica se o discovery está ativo ou não;

  4. Na aba Buscas, marque a opção Buscar artefatos DevOps para que a aba DevOps seja exibida.

  5. Na aba DevOps, preencha os seguintes campos:

    • Ativar serviço Kubernetes: habilita a execução do discovery no Kubernetes;

    • Buscar secrets: habilita a busca de secrets no Kubernetes;

    • Bearer token: habilita o uso de um bearer token do Kubernetes para autenticação e consulta das secrets. Selecione a credencial que possua o token de autenticação no Kubernetes;

    • Porta de acesso: porta de acesso à API do Kubernetes. Por padrão, a porta de conexão segura é a 6443, porém, ela pode ser alterada pelo administrador;

  6. Na aba Plugins, defina os plugins que serão utilizados no discovery e as portas que serão utilizadas. Os plugins possuem a inteligência necessária para realizar a conexão com os dispositivos e realizarem dos discoveries. Algumas das opções de plugins para este tipo de discovery são:

    • Unix/Linux;

    • Windows;

  7. Na aba Execução, defina a frequência do discovery. As opções são:

    • Manter scan ativo após importação?: define se o discovery continuará em execução, mesmo após a descoberta e importação dos containers;

    • Dias permitidos para execução: define os dias da semana que em o discovery será executado;

    • Períodos permitidos para execução: define o período do dia em que o discovery será executado com as seguintes faixas de horas:

      • 8:00 AM - 12:00 PM;

      • 12:00 PM - 4:00 PM;

      • 4:00 PM - 8:00 PM;

      • 8:00 PM - 12:00 AM;

      • 12:00 AM - 4:00 AM;

      • 4:00 AM - 8:00 AM;

    • Intervalo mínimo entre as execuções: intervalo de horas entre uma execução e outra;

  8. Para finalizar, clique no botão Salvar;

Gerar bearer token no Kubernetes e OpenShift​

Bearer token é um Schema para autenticação HTTP. Ele identifica recursos protegidos por um OAuth 2.0. O Kubernetes fornece alguns métodos de autenticação e um deles é através de tokens. Para gerar um Bearer token no Kubernetes ou OpenShift, siga os seguintes passos:

  1. Acesse o servidor onde o Kubernetes ou o OpenShift está em execução, via terminal;

  2. Aplique a política para permitir o acesso aos recursos do Kubernetes ou do OpenShift. Abaixo um exemplo de uma política que permite ler e listar secrets.

    kubectl apply -f - <<EOF
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: senhasegura-discovery
      namespace: kube-system
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: senhasegura-discovery
    rules:
    - apiGroups:
      - ""
      resources:
      - secrets
      verbs:
      - get
      - list
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: senhasegura-discovery
    subjects:
    - kind: ServiceAccount
      name: senhasegura-discovery
      namespace: kube-system
    roleRef:
      kind: ClusterRole
      name: senhasegura-discovery
      apiGroup: rbac.authorization.k8s.io
    EOF

  3. Após aplicada a política, exporte o Token para uma variável em seu terminal com o comando abaixo:

    export K8S_TOKEN=$(kubectl get secrets/$(kubectl get serviceaccount/senhasegura-discovery -n kube-system -o jsonpath='{.secrets[0].name}') -n kube-system -o jsonpath='{.data.token}' | base64 -d)

  4. Exiba o token no terminal e o copie:

    echo $K8S_TOKEN

  5. Crie uma credencial no senhasegura PAM e insira o token no campo senha;

Cadastrando a credencial​

Após a execução dos comandos e com o token em mãos é necessário associá-lo a uma credencial de acesso ao servidor Kubernetes.

Acesse o menu PAM ➔ Credenciais ➔ Todas clique no botão de ação do relatório para criar uma nova credencial.

  1. Insira o username da credencial;

  2. Defina o Tipo da Senha;

  3. No campo Dispositivo selecione o servidor Kubernetes;

  4. Selecione o campo Definir senha atual e no campo Senha insira o token obtido;

  5. Clique em Salvar;

Visualizar secrets Kubernetes e OpenShift​

Acesse o menu Discovery ➔ DevOps ➔ Kubernetes ➔ Secrets. Nesta tela será exibida a lista de Secrets encontradas durante a busca. Clique no botão de ação para ter mais informações sobre a Secret.

Ansible​

Ansible é um software de código aberto de provisionamento, gerenciamento de configuração e ferramenta de implantação de aplicativos, permitindo infra-estrutura como código. Ele funciona em muitos sistemas do tipo Unix, e pode configurar tanto sistemas do tipo Unix quanto o Microsoft Windows.

Configurar discovery de playbooks, roles e hosts do Ansible​

Para configurar um discovery de playbooks, roles e hosts do Ansible, acesse o menu Discovery ➔ Configurações ➔ Discovery.

  1. Clique no botão de ação do relatório Novo;

  2. Na janela apresentada, clique na opção Dispositivo;

  3. Na janela que abrir, preencha os seguintes campos:

    • Nome: será o nome do discovery cadastrado para identificação no senhasegura em relatórios;

    • IP Inicial: será o endereço de IP inicial dos dispositivos onde o Ansible esteja em execução;

    • IP Final: será o endereço de IP final dos dispositivos onde o Ansible esteja em execução;

    • Ativo: indica se o discovery está ativo ou não;

  4. Na aba Buscas, marque a opção Buscar artefatos DevOps. Uma aba de nome DevOps será exibida;

  5. Na aba DevOps, preencha os seguintes campos:

    • Ativar serviço Ansible: habilita a execução do discovery no Ansible;

    • Buscar playbooks: habilita a busca de playbooks;

    • Buscar roles: habilita a busca de roles;

    • Buscar hosts: habilita a busca dos hosts;

  6. Na aba Plugins, defina os plugins que serão utilizados no discovery e as portas que serão utilizadas. Os plugins possuem a inteligência necessária para realizar a conexão com os dispositivos e realizarem dos discoveries. Algumas das opções de plugins para este tipo de discovery são:

    • Unix/Linux

    • Windows

    Na aba mtelExecução, defina a frequência do discovery. As opções são:

    • Manter scan ativo após importação?: define se o discovery continuará em execução, mesmo após a descoberta e importação dos containers;

    • Dias permitidos para execução: define os dias da semana que em o discovery será executado;

    • Períodos permitidos para execução: define o período do dia em que o discovery será executado com as seguintes faixas de horas:

      • 8:00 AM - 12:00 PM;

      • 12:00 PM - 4:00 PM;

      • 4:00 PM - 8:00 PM;

      • 8:00 PM - 12:00 AM;

      • 12:00 AM - 4:00 AM;

      • 4:00 AM - 8:00 AM;

    • Intervalo mínimo entre as execuções: intervalo de horas entre uma execução e outra;

  7. Para finalizar, clique no botão Salvar;

Visualizar playbooks e hosts Ansible​

Ansible Playbooks report

Para visualizar informações dos playbooks e hosts encontrados, vá para Discovery ➔ DevOps ➔ Ansible ➔ Playbooks.

Nesta tela, você pode visualizar os playbooks encontrados. Você ainda pode visualizar as tarefas de um playbook, clicando no botão Tarefas ou seus hosts, clicando no botão Hosts.

Visualizar roles Ansible​

Ansible Roles report

Para ver informações dos papéis encontrados, vá para Discovery, DevOps, Ansible, Roles.

Jenkins​

Jenkins é um servidor de automação gratuito e de código aberto. Ele ajuda a automatizar as partes do desenvolvimento de software relacionadas à construção, teste e implantação, facilitando a integração contínua e a entrega contínua. É um sistema baseado em servidor que roda em contêineres de servlet, como o Apache Tomcat.

Configurar discovery de jobs, nodes e usuários do Jenkins​

Antes de iniciar, é necessário que exista uma credencial cadastrada no senhasegura PAM com um token de acesso à API do Jenkins. Para gerar o token, siga as instruções descritas na seção Gerar token no Jenkins.

Para configurar um discovery de jobs, nodes e usuários do Jenkins, acesse o menu: Discovery ➔ Configurações ➔ Discovery.

  1. Clique no botão de ação do relatório Novo;

  2. Na janela apresentada, clique na opção Dispositivo;

  3. Na janela que abrir, preencha os seguintes campos:

    • Nome: será o nome do discovery cadastrado para identificação no senhasegura em relatórios;

    • IP Inicial: será o endereço de IP inicial dos dispositivos onde o Jenkins esteja em execução;

    • IP Final: será o endereço de IP final dos dispositivos onde o Jenkins esteja em execução;

    • Ativo: indica se o discovery está ativo ou não;

  4. Na aba Buscas, marque a opção Buscar artefatos DevOps. Uma aba de nome DevOps será exibida;

  5. Na aba DevOps, preencha os seguintes campos:

    • Ativar serviço Jenkins: habilita a execução do discovery no Jenkins;

    • Buscar jobs: habilita a busca de jobs;

    • Buscar nodes: habilita a busca de nodes;

    • Buscar usuários: habilita a busca dos usuários;

    • Token de acesso Jenkins: seleção da credencial com o token de acesso ao Jenkins;

    • Porta de acesso: porta de acesso à API do Jenkins;

  6. Na aba Plugins, defina os plugins que serão utilizados no discovery e as portas que serão utilizadas. Os plugins possuem a inteligência necessária para realizar a conexão com os dispositivos e realizarem dos discoveries. Algumas das opções de plugins para este tipo de discovery são:

    • Unix/Linux;

    • Windows;

  7. Na aba Execução, defina a frequência do discovery. As opções são:

    • Manter scan ativo após importação?: define se o discovery continuará em execução, mesmo após a descoberta e importação dos containers;

    • Dias permitidos para execução: define os dias da semana que em o discovery será executado;

    • Períodos permitidos para execução: define o período do dia em que o discovery será executado com as seguintes faixas de horas:

      • 8:00 AM - 12:00 PM;

      • 12:00 PM - 4:00 PM;

      • 4:00 PM - 8:00 PM;

      • 8:00 PM - 12:00 AM;

      • 12:00 AM - 4:00 AM;

      • 4:00 AM - 8:00 AM;

    • Intervalo mínimo entre as execuções: intervalo de horas entre uma execução e outra;

  8. Para finalizar, clique no botão Salvar;

Gerar token no Jenkins​

Os tokens permitem que aplicações e scripts interajam com os artefatos do Jenkins por meio de APIs. Para gerar um token no Jenkins, siga os seguintes passos:

  1. Acesse a interface de usuário do Jenkins com o usuário para o qual deseja gerar o token;

  2. No canto superior direito, clique no nome do usuário e selecione a opção Configure;

  3. Na sessão API Token, clique no botão Add new Token;

  4. Insira um nome para este token, por exemplo, senhasegura-discovery e clique em Generate;

  5. Copie o valor Token;

  6. Crie uma credencial no módulo senhasegura PAM e insira o token no campo senha.

Cadastrando a credencial​

Após a execução dos comandos e com o token em mãos é necessário associá-lo a uma credencial de acesso ao servidor Jenkins.

Acesse o menu o PAM ➔ Credenciais ➔ Todas e clique no botão de ação do relatório para criar uma nova credencial.

  1. Insira o username da credencial;

  2. Defina o Tipo da Senha;

  3. No campo Dispositivo selecione o servidor Kubernetes;

  4. Selecione o campo Definir senha atual e no campo Senha insira o token obtido;

  5. Clique em Salvar;

Visualizar jobs Jenkins​

Para ver informações dos jobs encontrados, vá para: Discovery ➔ DevOps ➔ Ansible ➔ Jobs;

Relatório Jenkins Jobs

Visualizar nodes Jenkins​

Para ver informações dos nodes encontrados, vá para: Discovery ➔ DevOps ➔ Ansible ➔ Nodes;

Relatório Jenkins Nodes

Visualizar usuários Jenkins​

Para ver informações dos usuários encontrados, vá para: Discovery ➔ DevOps ➔ Ansible ➔ Users;

Relatório Jenkins Users

Plugins​

Por ser uma solução completa de DevOps, o senhasegura DSM conta com uma biblioteca vasta de plugins para auxiliar desenvolvedores e o time de segurança a terem a maior segurança com o menor esforço possível.

O senhasegura DSM conta com diversos plugins e integrações, algumas delas são:

  • Kubernetes e OpenShift;

  • Docker Swarm;

  • Ansible;

  • GitLab;

  • GitHub;

  • Jenkins;

  • Azure DevOps;

  • dentre outros;

caution

Solicite ao time de suporte a lista completa e o manual de utilização de cada um dos plugins disponíveis.

Kubernetes e OpenShift​

O Kubernetes é um orquestrador de containers que dispõe de diversas formas de compartilhamento de informações entre seus containers ativos. Para abstrair a tecnologia no qual o aplicativo alvo foi construído, o Kubernetes recomenda o uso de variáveis de sistema e o sistema de arquivo, que pode ser compartilhado ou não, para disponibilizar os dados sensíveis que o aplicativo necessita para executar suas tarefas.

senhasegura Sidecar​

Utilizando um modelo de contêiner lateral, a Kubernetes oferece um compartilhamento de recursos mais abrangente dentro de uma Pod. Este compartilhamento não só permite o isolamento de informações somente para os containers que residem na Pod, mas oferece mais possibilidades de desenvolvimento, personalização e integração.

Isto é possível devido à arquitetura própria da Kubernetes que permite que o sidecar possa consultar a identidade do requerente diretamente ao Orquestrador, levando em conta seu Namespace, Deploy, Pod e Container. Evitando que o aplicativo tente mascarar sua identidade e assegurando que somente as credenciais pertencentes a este bloco identificador sejam disponibilizadas ao requerente..

senhasegura DSM Kubernetes utiliza este recurso da Kubernetes para fornecer um container que hospeda uma aplicação simplificada do cliente senhasegura DSM WebService. Esta aplicação normaliza o acesso ao senhasegura e permite que aplicações existentes não sejam refeitas para acessar informações compartilhadas.

Funcionamento da integração com Kubernetes
Injeção dinâmica de secrets no Kubernetes com senhasegura Sidecar​

Com o plugin senhasegura Sidecar é possível que uma aplicação dentro de um container consuma secrets gerenciadas pelo senhasegura DSM sem a necessidade de desenvolvimento de integração direta.

O senhasegura Sidecar irá buscar a secret durante a criação de um novo Pod da aplicação e irá atualizá-la sempre que o TTL dela expirar.

Para configurar o plugin senhasegura Sidecar é necessário que possua o Client ID e Client Secret para autenticação via API. Para gerar as chaves de acesso, siga os passos descritos nas seções dsm-register-auth e dsm-view-auth.

Para configurar o senhasegura Sidecar , siga os passos abaixo:

  1. Crie uma secret no Kubernetes com o seguinte conteúdo com as informações de autenticação no senhasegura DSM ;

    apiVersion: v1
    kind: Secret
    metadata:
        name: senhasegura-authentication-parameters
    stringData:
        SENHASEGURA_CLIENT_ID: <senhasegura Client ID>
        SENHASEGURA_CLIENT_SECRET: <senhasegura Client Secret>
        SENHASEGURA_URL: <senhasegura IP or host>
        SENHASEGURA_APPLICATION_NAME: <application name>
        SENHASEGURA_APPLICATION_ENVIRONMENT: <application environment>

  2. Atualizar o seu arquivo de deployment incluindo as configurações do senhasegura Sidecar ou crie um para uma nova aplicação, como no exemplo abaixo:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <application name>
      labels:
        app: <application name>
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: <application name>
      template:
        metadata:
          labels:
            app: <application name>
        spec:
          volumes:
          - name: senhasegura-secrets
            emptyDir: {}
          - name: senhasegura-authentication-parameters
            secret:
              secretName: senhasegura-authentication-parameters

          imagePullSecrets:
            - name: registry-mt4

          containers:
          - image: busybox
            name: busybox
            command: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']

            volumeMounts:
            - name: senhasegura-secrets
              mountPath: /var/run/secrets/senhasegura/
      initContainers:
      - image: <senhasegura Sidecar binary address>
        name: senhasegura-secrets-provider

        volumeMounts:
        - name: senhasegura-secrets
          mountPath: /var/run/secrets/senhasegura/
          readOnly: false

        - name: senhasegura-authentication-parameters
          mountPath: /etc/senhasegura
          readOnly: true

        env:
          - name: SENHASEGURA_EXECUTION_TYPE
            value: sidecar
```

  1. Construindo a imagem do container;

    cd src
    docker build . --tag senhasegura/sidecar:<version >

  2. Enviar imagem do contêiner para seu registro portuário ou importar manualmente em nós;

  3. Após configurado é só executar o deploy da aplicação. Validando o deploy:

    kubectl get pods

    NAME                                READY   STATUS   RESTARTS   AGE
    demo-application-57f8b89bdf-22csj   2/2     Running  0          27m
caution

As secrets serão adicionadas no diretório compartilhado pelo Pod onde está executando a aplicação e o senhasegura Sidecar . O diretório será o /var/run/secrets/senhasegura/<application_name>

Injeção dinâmica de autorizações senhasegura no Kubernetes com senhasegura Sidecar​

Com o plugin senhasegura Sidecar é possível que uma aplicação dentro de um container solicite autorizações de acesso ao senhasegura DSM sem a necessidade de desenvolvimento de integração direta.

O senhasegura Sidecar irá provisionar uma autorização e receber as chaves de API para que a aplicação possa consultar as secrets gerenciadas pelo senhasegura DSM .

Para configurar o senhasegura Sidecar , siga os passos abaixo:

  1. Cadastre uma aplicação no senhasegura DSM com o método de autenticação OAuth 2.0. Para isso, siga os passos descritos na seção dsm-register-app;

  2. Cadastre uma autorização e pegue os dados do Client ID e Client Secret. Siga as instruções descritas nas seções dsm-register-auth e dsm-view-auth;

  3. Crie uma secret no Kubernetes com o seguinte conteúdo com as informações de autenticação no senhasegura DSM :

    apiVersion: v1
    kind: Secret
    metadata:
      name: senhasegura-authentication-parameters
    stringData:
      SENHASEGURA_CLIENT_ID: <senhasegura Client ID>
      SENHASEGURA_CLIENT_SECRET: <senhasegura Client Secret>
      SENHASEGURA_URL: <senhasegura IP or host>
      SENHASEGURA_APPLICATION_NAME: <application name>
      SENHASEGURA_APPLICATION_ENVIRONMENT: <application environment>

  4. Atualizar o seu arquivo de deployment incluindo as configurações do senhasegura initContainer ou crie um para uma nova aplicação, como no exemplo abaixo:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <application name>
      labels:
        app: <application name>
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: <application name>
      template:
        metadata:
          labels:
            app: <application name>
        spec:
          volumes:
          - name: senhasegura-secrets
            emptyDir: {}
          - name: senhasegura-authentication-parameters
            secret:
              secretName: senhasegura-authentication-parameters

          imagePullSecrets:
            - name: registry-mt4

          containers:
          - image: busybox
            name: busybox
            command: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']

            volumeMounts:
            - name: senhasegura-secrets
              mountPath: /var/run/secrets/senhasegura/
      initContainers:
      - image: <senhasegura Sidecar binary address>
        name: senhasegura-secrets-provider

        volumeMounts:
        - name: senhasegura-secrets
          mountPath: /var/run/secrets/senhasegura/
          readOnly: false

        - name: senhasegura-authentication-parameters
          mountPath: /etc/senhasegura
          readOnly: true

        env:
          - name: SENHASEGURA_EXECUTION_TYPE
            value: iso
```

  1. Construindo a imagem do container;

    cd src
    docker build . --tag senhasegura/sidecar:<version>

  2. Enviar imagem do contêiner para seu registro portuário ou importar manualmente em nós;

  3. Após configurado é só executar o deploy da aplicação;

  4. Validando o deploy:

    kubectl get pods

    NAME                                READY   STATUS   RESTARTS   AGE
    demo-application-57f8b89bdf-22csj   2/2     Running  0          27m
caution

As autorizações serão adicionadas no diretório compartilhado pelo Pod onde está executando a aplicação e o senhasegura Sidecar .

O diretório será o /var/run/secrets/senhasegura/<application_name>.

Jenkins​

O Jenkins permite que as variáveis ambientais sejam definidas dentro da execução dos trabalhos. Ele também permite o armazenamento seguro de valores que podem ser usados dentro destas mesmas tubulações sem exposição. O desafio do administrador é garantir que essas mesmas variáveis sejam automaticamente giradas.

Através da arquitetura nativa de Jenkins, o senhasegura permite que as variáveis sejam definidas em tempo de execução do pipeline através de nosso plugin Jenkins.

Além disso, para garantir maior visibilidade para os administradores, todas as variáveis que estiverem trafegando no ambiente do Job serão enviadas para o senhasegura DSM .

Funcionamento da integração com Jenkins

Instalar plugin do Jenkins​

Para instalação do plugin senhasegura Jenkins, com o arquivo .hpi de instalação em mãos, siga os seguintes passos:

  1. Acesse sua conta Jenkins;

  2. Na página inicial, clique na opção Manage Jenkins no menu lateral;

  3. Após isso clique na opção Manage Plugins;

  4. Na guia Advanced, selecione o arquivo do plugin em seu computador;

  5. Clique no botão Upload;

  6. Para finalizar a instalação, reinicie o Jenkins;

Injeção de secrets em Jenkins pipelines​

Para configurar o plugin senhasegura Jenkins é necessário que possua o Client ID e Client Secret para autenticação via API. Para gerar as chaves de acesso, siga os passos descritos nas seções dsm-register-auth e dsm-view-auth.

Para configurar o plugin, siga os seguintes passos:

  1. Acesse sua conta Jenkins;

  2. Crie um Job ou selecione um existente;

  3. No menu lateral, clique na opção Configure;

  4. Role a página até a sessão Build Environment e ative o uso do senhasegura DSM Plugin;

  5. Insira no campo senhasegura URL o IP ou hostname do senhasegura ;

  6. Clique no botão Add para criar uma nova credencial;

  7. Ao abrir a janela, no campo Kind, selecione a opção senhasegura Auth Credential;

  8. Preencha os campos Client ID, Client Secret e Description e clique no botão Add;

  9. Para finalizar, no campo senhasegura Auth Credential selecione a credencial.;

GitLab CI/CD​

GitLab CI/CD é uma ferramenta integrada na plataforma GitLab para o desenvolvimento de software através de metodologias contínuas:

  1. Integração contínua (CI);

  2. Entrega contínua (CD);

  3. Implantação contínua (CD);

A integração contínua funciona empurrando pequenos pedaços de código para a base de código de sua aplicação hospedada em um repositório Git e, a cada empurrão, executar um pipeline de scripts para construir, testar e validar as mudanças de código antes de fundi-los no ramo principal.

A Entrega e Implantação Contínua consiste em um passo além do CI, implantando sua aplicação para a produção a cada empurrão para o ramo padrão do repositório.

Estas metodologias permitem detectar bugs e erros no início do ciclo de desenvolvimento, garantindo que todo o código implantado para a produção esteja de acordo com os padrões de código que você estabeleceu para seu aplicativo.

Funcionamento da integração com GitLab

Instalar plugin do GitLab​

info

Peça a nossa equipe de suporte para receber o link para download do plugin do senhasegura GitLab.

Para instalação do plugin senhasegura GitLab, com o arquivo em mãos, siga os seguintes passos:

  1. Acesse um projeto em sua conta GitLab;

  2. Adicione o binário e o arquivo senhasegura-mapping.json no repositório do projeto;

    info

    O arquivo senhasegura-mapping.json pode ser utilizado para informar ao senhasegura DSM quais variáveis devem ser tratadas como secret.

  3. Edite o arquivo .gitlab-ci.yml no diretório de seu projeto;

  4. Na sessão before_script, insira o seguinte trecho de código: 

    chmod +x senhasegura`\newline` ./senhasegura ${APP} ${SYSTEM} ${ENVIRONMENT}`\newline` source .runb.vars`\newline` rm .runb.vars

  5. Salve o arquivo;

  6. Após isso, acesse a opção Settings ➔ CI/CD ➔ Variables;

  7. Insira as variáveis APP, ENVIRONMENT e SYSTEM;

    GitLab variables
    info

    As variáveis APP, ENVIRONMENT e SYSTEM informarão ao senhasegura DSM qual é a aplicação e em qual ambiente e sistema ela estará em execução.

  8. Por fim, bastará executar o pipeline do GitLab;

Injeção de secrets em pipelines do GitLab​

Após ter instalado o plugin no projeto, siga os passos para injetar as secrets em seu pipeline:

  1. Acesse o menu CI/CD ➔ Pipelines;

  2. Clique no botão Run Pipeline;

  3. Na etapa seguinte, clique em Run Pipeline;

  4. Por fim, clique no botão do deploy para visualizar o resultado;

Saída do plugin senhasegura GitLab

GitHub​

GitHub é uma plataforma de hospedagem de código-fonte e arquivos com controle de versão usando o Git. Ele permite que programadores, utilitários ou qualquer usuário cadastrado na plataforma contribuam em projetos privados e/ou Open Source de qualquer lugar do mundo.

Através do GitHub Actions é possível automatizar, personalizar e executar fluxos de trabalho de desenvolvimento do software diretamente no repositório.

Com o plugin senhasegura GitHub, é possível interceptar todas as variáveis de ambiente e injetar as secrets diretamente nos pipelines durante a execução da automação sem a necessidade de exposição das secrets.

Funcionamento da integração com GitHub

Instalando plugin do GitHub​

Para instalar o plugin senhasegura GitHub é necessário que possua o Client ID e Client Secret para autenticação via API. Para gerar as chaves de acesso, siga os passos descritos nas seções dsm-register-auth e dsm-view-auth.

  1. Acesse um projeto em sua conta GitHub;

  2. Adicione o binário e o arquivo senhasegura-mapping.json no repositório do projeto;

    info

    O arquivo senhasegura-mapping.json pode ser utilizado para informar ao senhasegura DSM quais variáveis devem ser tratadas como secret.

  3. Edite o arquivo cicd.yml localizado em <project_name>/.github/workflows/ no diretório de seu projeto;

  4. Na sessão jobs ➔build ➔steps, insira o seguinte trecho de código:

    - name: senhasegura
          env:
            APP: ${{ secrets.APP }}
            SYSTEM: ${{ secrets.SYSTEM }}
            ENVIRONMENT: ${{ secrets.ENVIRONMENT }}
            ENHASEGURA_URL: ${{ secrets.SENHASEGURA_URL }}
            SENHASEGURA_CLIENT_ID: ${{ secrets.SENHASEGURA_CLIENT_ID }}
            SENHASEGURA_CLIENT_SECRET: ${{ secrets.SENHASEGURA_CLIENT_SECRET }}
          run: |
            chmod +x senhasegura
            ./senhasegura $APP $SYSTEM $ENVIRONMENT
            source .runb.vars
            rm .runb.vars

  5. Salve o arquivo;

  6. Após isso, acesse a opção Settings ➔ Secrets;

  7. Insira as variáveis APP, ENVIRONMENT, SYSTEM, SENHASEGURA_URL, SENHASEGURA_CLIENT_ID e SENHASEGURA_CLIENT_SECRET;

  8. Por fim, bastará executar o workflow do GitHub;

GitHub secrets
info

As variáveis APP, ENVIRONMENT e SYSTEM informarão ao senhasegura DSM qual é a aplicação e em qual ambiente e sistema ela estará rodando.

Injeção de secrets em pipelines do GitHub​

Após ter instalado o plugin no projeto, siga os passos para injetar as secrets em seu pipeline:

  1. Siga o menu Actions;

  2. Selecione o workflow;

  3. Clique na opção Run workflow e em no botão Run workflow;

  4. Por fim, acesse job criado e clique no botão Build para visualizar o resultado;

Saída do plugin senhasegura GitHub

Microsoft®Azure DevOps​

O Azure Pipelines constrói e testa automaticamente projetos de código para torná-los disponíveis a outros. Funciona com praticamente qualquer idioma ou tipo de projeto. O senhasegura Azure DevOps Plugin Pipelines combina integração contínua (CI) e entrega contínua (CD) para testar e construir de forma constante e consistente seu código e enviá-lo para qualquer destino.

Com o plugin senhasegura Azure DevOps Plugin é possível a injeção de secrets em tempo real durante a execução de um pipeline sem a necessidade de exposição das informações sensíveis.

Além disso, o plugin irá interceptar todas as variáveis do pipeline para que os administradores possam identificar se existem informações sensíveis não gerenciadas pela solução e irá inserir todas as secrets como variáveis de ambiente de forma transparente para os desenvolvedores.

Funcionamento da integração com Microsoft®Azure DevOps

Instalar plugin do Microsoft®Azure DevOps​

Para instalação do plugin Microsoft®Azure DevOps, com o arquivo em mãos, siga os seguintes passos:

  1. Acesse um projeto em sua conta Microsoft®Azure DevOps;

  2. Adicione o binário e o arquivo senhasegura-mapping.json no repositório do projeto;

    info

    O arquivo senhasegura-mapping.json pode ser utilizado para informar ao senhasegura DSM quais variáveis devem ser tratadas como secret.

  3. Edite o arquivo azure-pipelines.yml no diretório de seu projeto;

  4. Na sessão steps, insira o seguinte trecho de código:

    - task: Bash@3
          displayName: 'senhasegura Plugin'
          inputs:
            targetType: filePath
            filePath: ./senhasegura
            arguments: '${APP} ${SYSTEM} ${ENVIRONMENT}'
          env:
            APP: <app_name>
            SYSTEM: <app_system>
            ENVIRONMENT: <app_environment>

  5. Salve o arquivo;

    info

    As variáveis APP, ENVIRONMENT e SYSTEM informarão ao senhasegura DSM qual é a aplicação e em qual ambiente e sistema ela estará rodando.

  6. Por fim, bastará executar o pipeline;

Injeção de secrets em pipelines do Microsoft®Azure DevOps​

Após ter instalado o plugin no projeto, siga os passos para injetar as secrets em seu pipeline:

  1. Acesse o projeto e siga o menu Pipelines ➔ Pipelines;

  2. Selecione o pipeline e clique em Run Pipeline;

  3. Na etapa seguinte, clique em Run;

  4. Por fim, clique no nome no Job para visualizar o resultado;

Saída do plugin senhasegura Microsoft®Azure DevOps

Ansible​

Consulta de segredos direto no playbook

O Ansible1 é um software de provisionamento fornecido pela Red Hat Inc2.

Seu modelo de configuração baseado em arquivos YAML, contendo os grupos de servidores e tarefas a serem executadas, permite que os segredos sejam integrados através de um módulos. Desta forma, o senhasegura desenvolveu um módulo Python seguindo as especificações do fabricante de forma que os playbooks possam ser elaborados utilizando credenciais gerenciadas pelo senhasegura sem necessidade de exposição do seu valor.

Exemplo de integracão do módulo senhasegura​

---
- hosts: mygroup
  tasks:
    - name: Request senhasegura credential
      senhasegura:
        api_url: "https://demo.senhasegura.com.br/iso"
        consumer_key: "5cb2990b2259e068653d9ba00cbc99ca2b2361f5f"
        consumer_secret: "6c4e73f496ee2857f4692727d837d8aa"
        token: "5cd8074565bf0058653de9e6df650080cab63a279"
        token_secret: "bde3ad3a798c9aacc541e43b7a6f5e35"
        username: "ansibleapi"
        ip: "10.0.20.20"
        hostname: "cisco-asav"
      register: result

    - debug: var=sscred

    - name: Using the returned password
      shell: echo {{ sscred | hash('md5')}}

Uso do módulo por linha de comando​

ansible mygroup --module-name senhasegura -u root --ask-pass

Uso do módulo através de playbook​

ansible-playbook myplaybook.yml -u root --ask-pass

senhasegura_device module​

O objetivo deste módulo é executar tarefas relacionadas ao dispositivo, por exemplo:

  • Registro de dispositivo;

  • Desativar um dispositivo;

  • Atualizar um dispositivo;

Instalação​

  1. No arquivo de configuração ansible.cfg (normalmente em /etc/ansible/ansible.cfg), definir o diretório para módulos personalizados:

    [defaults]
        library = /path/to/ansible/custom_modules/

  2. Criar o diretório para módulos personalizados e copiar o arquivo senhasegura_device.py:

    mkdir -p /path/to/ansible/custom_modules/
        cp src/senhasegura_device.py /path/to/ansible/custom_module

  3. Verifique se o módulo foi reconhecido pelo ansible com o comando abaixo

    ansible-doc -t module senhasegura_device
Usar​

Após a realização dos procedimentos de instalação do módulo, será necessário:

  1. Exportar os parâmetros de autenticação no senhasegura nas variáveis de ambiente;

  2. Criar a tarefa no PlayBook que utiliza o módulo senhasegura_device;

Exportar os parâmetros de autenticação no senhasegura nas variáveis de ambiente​

  1. Variáveis

    export SENHASEGURA_A2A_URL=https://senhasegura.mycorp.com
        export SENHASEGURA_A2A_CONSUMER_KEY=valueHere
        export SENHASEGURA_A2A_TOKEN=valueHere

  2. Para usuários de Ansible Tower ou AWX, recomendamos usar um "Tipo de Credencial Personalizado" para definir os parâmetros de autenticação nas senhas, como descrito abaixo:

    1. Com um utilizador com privilégios administrativos, registre um novo "Tipo de Credencial Personalizado" em Administration ➔ Credential Types;

    2. No campo de configuração de entrada, preencha os valores abaixo;

      ---
      fields:
          - type: string
              id: senhasegura_url
              label: senhasegura URL
          - type: string
              id: senhasegura_client
              label: Consumer Key
              secret: true
          - type: string
              id: senhasegura_token
              label: Token
              secret: true
              required:
              - senhasegura_url
              - senhasegura_client
              - senhasegura_token

    3. No campo de configuração do injector, preencha os valores abaixo

      ---
      env:
          SENHASEGURA_A2A_CONSUMER_KEY: '{{ senhasegura_client }}'
          SENHASEGURA_A2A_TOKEN: '{{ senhasegura_token }}'
          SENHASEGURA_A2A_URL: '{{ senhasegura_url }}'

    4. Exemplo

      Example of the use of variables

    5. Registre uma credencial do tipo "senhasegura"

      Com um usuário que tenha privilégios administrativos, registre uma nova credencial em Recursos ➔ Credenciais

    6. Preencha os valores requeridos

Criar a tarefa na PlayBook que utiliza o senhasegura_device module​

Exemplo:

---
- hosts: 127.0.0.1
    tasks:
        - name: "senhasegura | Create device w2012-server"
            senhasegura_device:
            state: present
            ip: "10.0.0.30"
            name: "w2012-server"
            tenant: "MT4"
            type: "Server"
            vendor: "Microsoft"
            site: "Europe-001"
            connectivity_protocol: "RDP"
            tags: ["db", "team_dev"]
        - name: "senhasegura | Disable device 'Firewall_003'"
            senhasegura_device:
            state: absent
            ip: "192.168.41.3"
            name: "Firewall_003"
            tenant: "MT4"
        - name: "senhasegura | Update device 'LB_BSD'"
            senhasegura_device:
            state: present
            ip: "172.16.0.90"
            name: "LB_BSD"
            tenant: "MT4"
            type: "Server"
            vendor: "OpenBSD"
            site: "DC003"
            connectivity_protocol: "SSH"
            connectivity_port: "2222"
Parâmetros suportados pelo módulo​
ParametrosObrig.OpçõesNota
estadoSimPresent, ausenteEspecifica o status do dispositivo desejado
ipSimNecessário para ser registrado previamente
nomeSimNecessário para ser registrado previamente
tenantSim
tipoApenas quando o estado esta == presenteCluster
Database
Domain
Firewall
Load Balancer
Router
Server
Switch
Web Application
Workstation
fabricanteApenas quando o estado esta == presente
siteApenas quando o estado esta == presente
connectivity_protocolApenas quando o estado esta == presenteHTTP, HTTPS, LDAP, LDAPS, MySQL, Oracle, PostgreSQL, RDP, SQL Server, SSH, TDS Sybase, Telnet, VNC, Windows RM, Windows RPC, X11 Forward
connectivity_portNão
tagsNão

senhasegura_credential module​

O objetivo deste módulo é realizar tarefas no senhasegura relacionadas a credenciais, como por exemplo:

  • Registrar uma credencial

  • Desativar uma credencial

  • Atualizar uma credencial

Instalação​

  1. No arquivo de configuração ansible.cfg (normalmente no /etc/ansible/ansible.cfg), definir o diretório para módulos personalizados.

    [defaults]
        library = /path/to/ansible/custom_modules/

  2. Criar o diretório para módulos personalizados e copiar o arquivo

    senhasegura_credential.py

    mkdir -p /path/to/ansible/custom_modules/
        cp src/senhasegura_credential.py /path/to/ansible/custom_modules/

  3. Verifique se o módulo foi reconhecido pelo ansible com o comando abaixo:

    ansible-doc -t module senhasegura_credential
Uso​

Após a realização dos procedimentos de instalação do módulo, será necessário:

  1. Exportar os parâmetros de autenticação no senhasegura nas variáveis de ambiente

  2. Criar a tarefa na PlayBook que utiliza o módulo senhasegura_credential

Exportar os parâmetros de autenticação no senhasegura nas variáveis de ambiente​

  1. Variables

    export SENHASEGURA_A2A_URL=https://senhasegura.mycorp.com
        export SENHASEGURA_A2A_CONSUMER_KEY=valueHere
        export SENHASEGURA_A2A_TOKEN=valueHere

  2. Para usuários de Ansible Tower ou AWX, recomendamos usar um "Tipo de Credencial Personalizado" para definir os parâmetros de autenticação nas senhas, como descrito abaixo:

    1. Com um utilizador com privilégios administrativos, registe um novo "Tipo de Credencial Personalizado" em Administration ➔ Credential Types

    2. No campo de configuração de entrada, preencha os valores abaixo

      ---
      fields:
          - type: string
              id: senhasegura_url
              label: senhasegura URL
          - type: string
              id: senhasegura_client
              label: Consumer Key
              secret: true
          - type: string
              id: senhasegura_token
              label: Token
              secret: true
              required:
                  - senhasegura_url
                  - senhasegura_client
                  - senhasegura_token

    3. No campo de configuração do injector, preencha os valores abaixo

      ---
      env:
          SENHASEGURA_A2A_CONSUMER_KEY: '{{ senhasegura_client }}'
          SENHASEGURA_A2A_TOKEN: '{{ senhasegura_token }}'
          SENHASEGURA_A2A_URL: '{{ senhasegura_url }}'

    4. Exemplo

      Example of the use of variables

    5. Registar uma credencial do tipo "senhasegura".

      Com um usuário que tenha privilégios administrativos, registre uma nova credencial em Resources ➔ Credentials

    6. Preencha os valores requeridos

Criar a tarefa no PlayBook que utiliza o módulo senhasegura_credential​

Ler o arquivo PlayBook_example.yaml

Parâmetros suportados pelo módulo​
ParâmetroObrig.OpçõesNota
estadoSimPresente, ausenteDetermina o status do dispositivo
device_ipSimNecessário para ser registrado previamente
device_hostnameSimNecessário para ser registrado previamente
usernmaeSim
senhaNão
credential_typeSim
tenantSim
dominioQuando credential_type é do tipo ’Usuário de domínio’
tagsNão

senhasegura_query_credential module​

Este módulo propõe a consulta de uma credencial registrada no senhasegura , ao executar uma PlayBook Ansible, para realizar tarefas como, por exemplo:

  • Conectar uma base de dados com usuário cbda

  • Abrir arquivo criptografado

  • Executar qualquer task com privilégio elevado

  • Qualquer task que precise de credencial

Exemplo de execução​
---
- hosts: 127.0.0.1
    tasks:
        - name: "Credential ID 9 | Use senhasegura_query_credential for query credential"
            senhasegura_query_credential:
                identificator: "9"
                register: cred_id_9
        - name: "Credential ID 9 | Print credential"
            debug:
                var: cred_id_9
        - name: "Credential ID ansible_srv | Use senhasegura_query_credential for query credential"
            senhasegura_query_credential:
                identificator: "ansible_srv"
                register: cred_ansible_srv
        - name: "Credential by ansible_srv | Print credential"
            debug:
                var: cred_ansible_srv
        - name: "Credential for username 'ansible', ip '172.66.240.30' and hostname 'DevOps-GitLab' | Use senhasegura_query_credential for query credential"
            senhasegura_query_credential:
                username: ansible
                ip: 172.66.240.30
                hostname: DevOps-GitLab
                register: cred_host
        - name: "Credential for username 'ansible', ip '172.66.240.30' and hostname 'DevOps-GitLab' | Print credential"
            debug:
                var: cred_host
ansible-playbook PlayBook_example.yaml
Instalação​

  1. No arquivo de configuração ansible.cfg (normalmente em /etc/ansible/ansible.cfg), definir o diretório para módulos personalizados.

    [defaults]
        library = /path/to/ansible/custom_modules/

  2. Criar o diretório para módulos personalizados e copiar o arquivo

    src/senhasegura_query_credential.py

    mkdir -p /path/to/ansible/custom_modules/
        cp src/senhasegura_query_credential.py
        /path/to/ansible/custom_modules/

  3. Verifique se o módulo foi reconhecido pelo ansible com o comando abaixo

    ansible-doc -t module senhasegura_query_credential

senhasegura dynamic inventory plugin​

Este plugin recebe credenciais registradas no senhasegura com WebService A2A para autenticar em dispositivos remotos e executar Ansible PlayBooks para:

  • Apoiar credenciais individuais ou usernames para cada host

  • Suporte somente autenticação usando senha, chaves SSH não (ainda)

Exemplos de execução​
ansible-playbook --inventory senhasegura.yaml Example_playbook.yaml
Uso​

Após a realização dos procedimentos de instalação do módulo, será necessário:

  1. Definir parâmetros WebService A2A

    • Você pode usar variáveis de ambiente (recomendadas)

    • Ou você pode definir o parâmetro a2a_config no arquivo de inventário

  2. Popular o arquivo do inventário com os dispositivos desejados

  3. Executar PlayBook

Exportar em variáveis de ambiente os parâmetros de autenticação para WebService A2A​

  1. Variáveis

    $ export SENHASEGURA_A2A_URL=https://senhasegura.mycorp.com
        $ export SENHASEGURA_A2A_CONSUMER_KEY=valueHere
        $ export SENHASEGURA_A2A_TOKEN=valueHere

  2. Preencha o arquivo de inventário com os dispositivos desejados

    plugin: senhasegura
        username: dev ## Global username for all hosts
    hosts:
        - hostname: DevOps-GitLab
            ip: 172.66.240.30
            username: ansible ## Override global username for this host
        - hostname: DevOps-Ansible
            ip: 172.66.240.20
        - hostname: DevOps-Kubernetes-001
            ip: 172.66.240.41
            username: root ## Override global username for this host

  3. Executando exemplo de PlayBook

    $ ansible-playbook --inventory senhasegura.yaml Example_playbook.yaml

  4. Setting the WebService A2A authentication parameters within inventory file

    You can define authentication parameters on WebService A2A within inventory file, but we recommend that you use environment variables for :

    $ head -n 2 senhasegura.yaml
    plugin: senhasegura
    a2a_config: /path/to/a2a_parameters

    $ cat /path/to/a2a_parameters
    api_url: https://senhasegura.mycorp.com
    consumer_key: valueHere
    token: valueHere

senhasegura-credential module for Puppet​

This module offers a secure way for Puppet to fetch secrets from senhasegura .

Installation​

Download senhasegura-credential module and install with the command below:

\## puppet module install /path/to/puppet-senhasegura-X.Y.Z.tar.gz --ignore-dependencies
Usage​

The senhasegura::credential function can be called to fetch secrets from senhasegura to be used by Puppet.

By providing a credential-identifier, senhasegura::credential uses the node's identity to return the needed value.

$senhaseguracredential = senhasegura::credential(’credential-identifier’)

To inform which secrets should be retrieved, a Hiera attribute file can be defined as shown below:

file { '/opt/my_application/credential.yaml':
    content => $credential,
    ensure  => file,
    mode    => '0600',
}

The secrets values are returned in a Sensitive data type. This is necessary to avoid secrets to be mishandled.

For the secret to being used, it is required to use the unwrap function. Then the result should be wrapped in a Sensitive value.

$credential = Sensitive(”password: $senhaseguracredential.unwrap”))

Full example​
class { senhasegura:
    senhasegura_endpoint => 'senhasegura.corp',
    client_id            => Sensitive('OAuth2 info'),
    client_secret        => Sensitive('OAuth2 info'),
    tenant               => 'MT4',
}

$senhaseguracredential = senhasegura::credential('credential-identifier')

$credential = Sensitive("password: ${senhaseguracredential.unwrap}")

file { '/opt/my_application/credential.yaml':
    content => $credential,
    ensure  => file,
    mode    => '0600',
}

Terraform is an infrastructure provisioning tool that allows creation, management and maintenance of resources like Virtual Machines, Containers, network switches and more.

senhasegura Provider for Terraform offers a simple way to manage secrets used to provision infrastructure resources.

The resources senhasegura Provider offers are:

  • senhasegura_getcredential: Query a credential;

  • senhasegura_credential: Create, Update or Disable a credential;

Installation​

Make a directory for Terraform plugins at  /.terraform.d/plugins and copy senhasegura-provider folder.

$ mkdir -p ~/.terraform.d/plugins/
$ mv ../terraform-provider-senhasegura ~/.terraform.d/plug-ins

Usage​

Create senhasegura Provider with authentication parameters​
provider "senhasegura" {
    senhasegura_url = "https://senhasegura.corp"
    senhasegura_consumer_key = ""
    senhasegura_token = ""
}
Get credential with ID db_001​
data "senhasegura_getcredential" "my_credential" {
    identifier = "db_001"
    tenant = "MT4"
}
output "my_credential_out" {
    value = "${data.senhasegura_getcredential.my_credential.value}"
}
Local user credential example​
resource "senhasegura_credential" "my_new_credential" {
    username = "foo"
    password = "mySuperSecretPassword"
    tenant = "MT4"
    type = "Local user"
    tags = ["foo", "bar"]

    device {
        ip = "10.0.0.10"
        hostname = "linux_10"
    }
}
Domain credential example​
resource "senhasegura_credential" "my_new_domain_credential" {
    username = "bar"
    password = "myNewSuperSecretPassword"
    tenant = "MT4"
    type = "Domain user"
    domain = "corporate"

    device {
        ip = "10.0.0.20"
        hostname = "windows_20"
    }
}

senhasegura Running Belt​

senhasegura Running Belt é um plugin agnóstico para interceptação de variáveis de ambiente e injeção de secrets.

Com ele, times de DevOps podem ter visibilidade das aplicações e secrets com facilidade, além de fornecer secrets para aplicações, pipelines e ambientes de forma segura e instantânea.

Instalar plugin senhasegura Running Belt​

Por ser um binário desenvolvido em GO Lang, sua instalação é muito simples. Basta adicioná-lo em um diretório de seu ambiente ou ferramenta de CI/CD e executá-lo fornecendo 3 atributos:

  • APP: que será o nome de sua aplicação;

  • SYSTEM: que será o sistema onde a aplicação está instalada;

  • ENVIRONMENT: que será o ambiente onde a aplicação está rodando;

Injeção de secrets em variáveis de ambiente com senhasegura Running Belt​

Ao executar o plugin fornecendo as três informações APP, SYSTEM e ENVIRONMENT o plugin irá coletar todas as variáveis de ambiente e enviá-las ao senhasegura DSM . Em seguida, ele irá consultar o senhasegura DSM todas as secrets daquela aplicação e atualizar as variáveis de ambiente com os novos valores.

Desta forma, os desenvolvedores não precisarão se preocupar com a injeção de secrets durante pipelines, por exemplo. Elas poderão ser gerenciadas diretamente via API, CLI ou interface do senhasegura DSM pelo desenvolvedor ou time de segurança.

  1. https://www.ansible.com/↩
  2. https://www.redhat.com/en↩