Pular para o conteúdo principal
Version: 3.20

Guia de Referência DevOps

DevOps

Dentro do universo DevOps a flexibilidade e performance são cruciais para que as aplicações tenham acesso a todos recursos necessários para executar seus trabalhos.

Os orquestradores e virtualizadores contam com abstrações de tecnologias afim de que aplicações de ecosistemas diferenciados possam coexistir e compartilharem informações através funcionalidades básicas dos sistemas operacionais.

Dentro de um ciclo SDLC moderno, os desenvolvedores tem a possibilidade de executar suas aplicações utilizando as mesmas variáveis e canais de obtenção que um ambiente produtivo.

Esta facilidade porém traz a preocupação de que informações sensíveis sejam fixadas nos códigos fonte ou arquivos de configuração.

Dentro deste escopo, o senhasegura fornece aos fabricantes de software diversas maneiras de solicitar informações confidenciais como senhas, chaves e demais informações que devam ser segregadas e gerenciadas por uma equipe externa à equipe de desenvolvimento.

As tecnologias aqui apresentadas são todas desenvolvidas dentro da camada de customização dos fabricantes, seguindo rigorosamente suas especificações e preocupações quanto a segurança e integridade da informação.

info

O principal canal desta comunicação é o senhasegura WebService A2A . Os demais plugins, APIs e requisições descritos neste documento, são facilitadores de integração.

sectionKubernetes e OpenShift O Kubernetes1 é um orquestrador de containers que dispõem de diversas formas de compartilhamento de informações entre seus containers ativos. Para abstrair a tecnologia no qual o aplicativo alvo foi construída, 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.

Integrações possíveis entre Kubernetes e senhasegura
caution

O senhasegura recomenda o uso de seu DSM internamente nas aplicações, deixando apenas os dados de autenticação OAuth disponíveis via secret.

senhasegura-sidecar

Utilizando um modelo de container sidecar, o Kubernetes disponibiliza um compartilhamento de recursos mais abrangente dentro de um Pod. Esse compartilhamento permite não apenas o isolamento da informação apenas para os containers que residem no Pod, mas entrega mais possibilidades de desenvolvimento, customização e integração.

Isso é possível por conta da arquitetura do próprio Kubernetes que permite que o sidecar consulte a identidade do solicitante diretamente ao orquestrador, levando em conta seu Namespace, Deploy, Pod e Container. Impedindo que a aplicação tente mascarar sua identidade e garantindo que apenas as credenciais pertencentes a essa quadra de identificadores sejam disponibilizadas ao solicitante.

O senhasegura utiliza desta funcionalidade do Kubernetes para entregar um container que hospeda uma aplicação cliente simplificada do senhasegura WebService A2A . Essa aplicação normaliza o acesso ao senhasegura e permite que aplicações já existentes não precisem ser refeitas para acessar informações compartilhadas.

A URL do senhasegura e os dados para autenticação OAuth devem ser fornecidas através da configuração YAML.

apiVersion: v1
kind: Namespace
metadata:
name: senhasegura-demo
---
apiVersion: v1
kind: Secret
metadata:
name: senhasegura-tokens
namespace: senhasegura-demo
type: Opaque
data:
apiUrl: MS4xLjEuMQ==
apiClient: ZXhhbXBsZUNsaWVudA==
apiToken: ZXhhbXBsZVRva2Vu
---
apiVersion: v1
kind: Pod
metadata:
name: application-with-senhasegura-sidecar
namespace: senhasegura-demo
spec:
volumes:
- name: senhasegura-tokens
secret:
secretName: senhasegura-tokens
containers:
- name: senhasegura-sidecar
image: senhasegura-sidecar
volumeMounts:
- name: senhasegura-tokens
mountPath: "/etc/senhasegura/tokens"
readOnly: true
- name: busybox-container
image: busybox
command:
- sleep
- "3600"

senhasegura-custom-resource

O uso de um Kubernetes Custom Resource2 permite que o gerenciamento de secrets em variáveis de ambiente ou arquivos sejam repassados ao senhasegura garantindo que os valores atribuídos serão sempre os valores reais e permitidos.

apiVersion: v1
kind: Pod
metadata:
name: senhasegura-demo
spec:
containers:
- name: db
image: mongo
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
key: username
name: SENHASEGURA_IDENTIFICATOR
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
key: password
name: SENHASEGURA_IDENTIFICATOR
restartPolicy: Never

Com a configuração YAML em mãos, utilize o senhasegura-kubectl-plugin para que os valores sensíveis sejam alterados.

kubectl senhasegura senhasegura-demo.yaml 

sectionAnsible

Consulta de segredos direto no playbook

O Ansible3 é um software de provisionamento fornecido pela Red Hat Inc4.

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.

Instalação dos módulos senhasegura Ansible

caution

Toda execução do Ansible utilizando o senhasegura Ansible plugin, irá se comunicar com o servidor do senhasegura através do WebService A2A . E a aplicação registrada no WebService A2A deve estar configurada para utilizar OAuth2.0.

Primeiramente você deve solicitar ao nosso time de suporte para obter os plugins senhasegura Ansible. Então você poderá executar os seguintes passos para instalar nossos plugins em seu servidor Ansible.

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

    [defaults]
    library = /path/to/ansible/custom_modules/
  2. Criar o diretório definido no arquivo de configuração e copiar o arquivo src/senhasegura_credential.py

    mkdir -p /path/to/ansible/custom_modules/
    cp src/senhasegura_credential.py /path/to/ansible/custom_modules/
  3. Verificar se o módulo é carregado usando um ansible-doc

    ansible-doc -t module senhasegura_credential

Uso básico do módulos senhasegura Ansible

Após executar as etapas de instalação, você precisará: Exportar nas variáveis de ambiente os parâmetros de autenticação para A2A e definir um conjunto de tarefas no Playbook que utiliza o módulo senhasegura .

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

Parâmetros de autenticação:

export SENHASEGURA_A2A_URL=https://company.security.com
export SENHASEGURA_A2A_CONSUMER_KEY=valueHere
export SENHASEGURA_A2A_TOKEN=valueHere
Para usuários de Ansible Tower ou AWX

Por favor, configure "Custom Credential Type" para parâmetros de autenticação senhasegura :

  1. Com um usuário que tenha privilégios administrativos, registrar um novo "Custom Credential Type" 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 injetor, preencha os valores abaixo

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

    Example
  5. Com um usuário que tenha privilégios administrativos, registrar uma nova credencial em Resources ➔ Credentials. Preencher os valores requeridos:

    Example

senhasegura_credential module

Ao executar um PlayBook Ansible, você precisa consultar uma credencial registrada na senhasegura para realizar tarefas como, por exemplo

  • Conectar no banco de dados com o usuário cbda

  • Abrir arquivo criptografado

  • Executar qualquer tarefa com elevação de privilégios

  • Qualquer tarefa que necessite de uma credencial

Exemplo de Playbook
---
### Example: Creating a credential
- hosts: all
tasks:
- name: Create credential
senhasegura_credential:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
state: present
ip: 127.0.0.1
hostname: my_credential_hostname
username: my_credential_username
password: my_credential_password
tags: ['mytag1', 'mytag2']
additional_info: 'created by ansible'
register: cred_created

- name: "Credential created | Print credential"
debug:
var: cred_created
---
### Example: Deleting a credential
- hosts: all
tasks:
- name: Delete credential id 9
senhasegura_credential:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
identifier: '9'
state: absent
register: cred

- name: "Credential ID 9 | Print credential"
debug:
var: cred
Descrição dos parâmetros
  • system_url: O URL de ambiente senhasegura usado para auth, configurado como variável de ambiente chamado SENHASEGURA_A2A_URL

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_id: A A2A cliente_id para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_ID

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_secret: A A2A client_secret para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_SECRET

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • state: Especifica o estado necessário para a credencial. present para criar ou atualizar a credencial, absent para apagar a credencial.

    • Type: String

    • Options: absent, present

    • Required: Não, o valor padrão é present

  • id_credential: A identificação da credencial de gestão. Necessário para atualizar e excluir. Se omitido e o Estado estiver presente, uma nova credencial será criada.

    • Type: int

    • Required: Somente quando a state está absent

  • identifier: O identificador secreto para a gerência, apelidado de credential_id. Necessário para atualizar e excluir. Se omitido e o state estiver present, será criada uma nova credencial.

    • Type: int

    • Required: Somente quando o id_credencial é omitido

  • hostname: Hostname a ser definido na credencial

    • Type: String

    • Required: Somente quando a state está present

  • ip: IP a estabelecer na credencial

    • Type: String

    • Required: Somente quando a state está present

  • credential_type: Especifica o tipo de credencial.

    • Type: String

    • Options: local_user, local_administrator, domain_user

    • Required: Não, o valor padrão é local_user

  • username: Nome de usuário para definir no segredo se encontrado por id_credential ou identificador, ou será usado para encontrar a credencial

    • Type: String

    • Required: Somente quando a state está present

  • password: A senha a ser estabelecida no segredo. Esta senha deve atender aos requisitos da política de senhas.

    • Type: String

    • Required: Somente quando a state está present

  • domain: O domínio das credenciais.

    • Type: String

    • Required: No

  • tags: The credential tags.

    • Type: list

    • Required: No

  • additional_info: As informações adicionais para credenciais.

    • Type: String

    • Required: No

  • parent_credential: Identificação credencial pai

    • Type: String

    • Required: No

senhasegura_device module

Ao executar um PlayBook Ansible, você pode precisar provisionar novos dispositivos dentro do senhasegura ou consultar os dispositivos existentes.

Playbook example
---
### Example: Creating a device
- hosts: all
tasks:
- name: Create device
senhasegura_device:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
state: present
hostname: mydevicehost
ip: 172.10.20.30
type: server
vendor: mydevicevendor
model: mydevicemodel
connectivity_protocol: ['SSH','Telnet']
connectivity_port: [22, 23]
site: default

register: device_created

- name: "Device created | Print device"
debug:
var: device_created
---
### Example: Deleting a device
- hosts: all
tasks:
- name: Delete device id 9
senhasegura_device:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
identifier: '9'
state: absent
register: device

- name: "Device ID 9 | Print device"
debug:
var: device
Descrição dos parâmetros
  • system_url: A URL de ambiente senhasegura usada para auth, configurada como variável de ambiente chamada SENHASEGURA_A2A_URL

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_id: O A2A client_id para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_ID

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_secret: O A2A client_secret para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_SECRET

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • state: Especifica o estado necessário para o dispositivo. present para criar ou atualizar e absent para excluir.

    • Type: String

    • Required: None

    • Options: absent, present

  • identifier: Identificador para encontrar o dispositivo

    • Type: Integer

    • Required: Yes

  • hostname: Hostname para consultar ou definir um novo dispositivo

    • Type: String

    • Required: Yes

  • ip: IP para definir um novo dispositivo

    • Type: String

    • Required: Yes

  • type: Especifica o tipo de dispositivo.

    • Type: String

    • Required: Somente se a state estiver present

  • vendor: Especifica o fabricante do dispositivo. Será criado automaticamente se não existir.

    • Type: String

    • Required: Somente se a state estiver present

  • model: Especifica o modelo do dispositivo. Será criado automaticamente se não existir.

    • Type: String

    • Required: Somente se a state estiver present

  • site: Especifica o site do dispositivo. Será criado automaticamente se não existir.

    • Type: String

    • Required: Somente se a state estiver present

  • domain: Especifica o domínio do dispositivo.

    • Type: String

    • Required: No

  • connectivity_protocol: Os protocolos de conectividade do dispositivo.

    • Type: List

    • Required: No

    • Options: HTTP, HTTPS, LDAP, LDAPS, MySQL, Oracle, PostgreSQL, RDP, SQL Server, SSH, TDS Sybase, Telnet, VNC, Windows RM, Windows RPC, X11 Forward

  • connectivity_port: As portas de conectividade no dispositivo. Deve ser uma lista inteira para o protocolo de conectividades enviado.

    • Type: List

    • Required: No

senhasegura_key module

Usando este plugin você pode criar, alterar ou inativate chaves SSL gerenciadas pelo senhasegura .

Exemplo de Playbook
---
### Example: Creating a key
---
- hosts: all
tasks:
- name: Delete key
senhasegura_key:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
id_key: '999'
state: absent
register: key

- name: "Key ID 1 | Print key"
debug:
var: key

- name: Create key
senhasegura_key:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
state: present
ip: 172.10.20.30
hostname: mydevicehost
username: myuser
password: mypassword
public_key: |
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIUB7WzL+hW0LOjErtgfebM5zE8gl0wDQYJKoZIhvcNAQEL
BQAwRTELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVB...
private_key: |
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,384DE75465B87200
xc7xR0lo1MlgBbZ+8RW/OoMMK5sAs3EaVzahSh5MPfUOMJG9ppVz35iNdnB2bwa6
ksyKfEv2guW3zRb9GVAdFsLoGA4qtOE/FOgeuJKA/RcYSxHnUNmrNzPq38EQl...
tags: ['mytag01', 'mytag02']
register: key_created

- name: "Key created | Print key"
debug:
var: key_created
---
### Example: Deleting a key
---
- hosts: all
tasks:
- name: Delete key
senhasegura_key:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
id_key: '9999'
state: absent
register: key
- name: "Key ID 9999 | Print key"
debug:
var: key
Descrição dos parâmetros
  • system_url: O URL de ambiente senhasegura usado para auth, configurado como variável de ambiente chamado SENHASEGURA_A2A_URL

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_id: O A2A client_id para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_ID

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_secret: O A2A client_secret para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_SECRET

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • state: Especifica o estado necessário para o dispositivo. present para criar ou atualizar e absent para excluir.

    • Type: String

    • Required: None

    • Options: absent, present

  • id_key: A identificação do registro chave para a gestão. Necessário para atualizar e excluir. Se omitido, e o state estiver present, uma nova chave será criada.

    • Type: Integer

    • Required: Somente se a state estiver absent

  • identifier: O identificador secreto para a gerência, apelidado de id_key. Necessário para atualizar e excluir operações. Se omitido e o state estiver present, uma nova chave será criada.

    • Type: Integer

    • Required: Somente se a tecla id_key for omitida

  • hostname: Hostname a ser colocado na chave do dispositivo

    • Type: String

    • Required: Somente se a state estiver present

  • ip: IP a ser colocado na chave do dispositivo

    • Type: String

    • Required: Somente se a state estiver present

  • key_type: Especifica o tipo de chave.

    • Type: String

    • Required: Não, o valor padrão é local_user

    • Options: local_user

  • username: Nome de usuário para definir no segredo se encontrado pelo identificador id_key, ou será usado para encontrar a chave

    • Type: String

    • Required: Somente se a state estiver present

  • password: A senha a ser estabelecida no segredo. Esta senha deve atender aos requisitos da política de senhas.

    • Type: String

    • Required: Somente se a state estiver present

  • private_key: A chave privada SSH.

    • Type: String

    • Required: No

  • public_key: A chave pública SSH.

    • Type: String

    • Required: No

  • tags: As tags de chave

    • Type: list

    • Required: No

senhasegura_query_credential module

Usando este módulo, sua aplicação pode consultar as credenciais registradas no servidor senhasegura .

Exemplo de Playbook
---
- hosts: all
tasks:
- name: Find credential by it's id
senhasegura_query_credential:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
id_credential: '10035'
register: cred

- name: "Credential ID 10035 | Print credential"
debug:
var: cred

- name: Fetch credential for 'ansible' user on server 'AIX7.2 ' with IP '150.238.77.93'
senhasegura_query_credential:
system_url: 'https://company.security.com/'
client_id: 'your_application_oauth_client_id'
client_secret: 'your_application_oauth_client_secret'
username: ansible
ip: '150.238.77.93'
hostname: AIX7.2
register: cred

- name: "Print credential"
debug:
var: cred
Descrição dos parâmetros
  • system_url: O URL de ambiente senhasegura usado para auth, configurado como variável de ambiente chamado SENHASEGURA_A2A_URL

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_id: O A2A client_id para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_ID

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • client_secret: O A2A client_secret para o usuário, configurada como variável de ambiente chamada SENHASEGURA_A2A_CLIENT_SECRET

    • Type: String

    • Required: Somente se a variável ambiente não estiver definida

  • hostname: O hostname do segredo para fetch, somente se omitir o id_credential e do identifier.

    • Required: No

    • Type: String

  • id_credential: A identificação da credencial para o fetch

    • Required: No

    • Type: String

  • identifier: O identificador secreto para o fetch, somente se omitir a identificação do id_credential

    • Required: No

    • Type: String

  • ip: O IP ou DNS do segredo para fetch, somente se omitir o IP ou DNS do segredo para fetch, somente se omitir o IP ou DNS do segredo para fetch

    • Required: No

    • Type: String

  • username: O username da secret para fetch, somente se id_credential e identifier forem omitidos.

    • Required: No

    • Type: String

sectionGitlab CI/CD O GitLab5 CI/CD6 permite que as variáveis sejam configuradas na camada de projeto. Permitindo que os valores das variáveis sejam determinados dependendo de seu escopo.

O senhasegura consegue interagir diretamente com os valores destas variáveis no momento em que as credenciais sofram alterações manuais ou através de processos de execução automatizada.

Credenciais, como por exemplo uma senha de banco de dados, podem ser alteradas em todos projetos onde essa credencial seja utilizada através do Executor GitLab.

Requisição ao GitLab para atualização de credencial

Neste caso, entre as credenciais filhas desta credencial pai alterada, deve constar a credencial relativa a variável de projeto que ostenta a senha atualizada. Quando acionado a troca da senha filha, uma requisição será direcionada ao servidor do GitLab conforme o padrão do fabricante, solicitando a atualização da variável no projeto.

Cadastro da variável de ambiente do projeto
Configuração da cadeia de execução de troca de senha
info

Consulte o Manual do Administrador de Operações para ter mais informações sobre o módulo de Execuções

Assim que a credencial pai for alterada, as credenciais filhas que correspondam ao executor GitLab realizarão uma requisição conforme manda a documentação oficial do fabricante7

  • PRJ_TOKEN: Senha da credencial que armazena o token do projeto

  • GIT: Hostname da credencial que armazena o token do projeto

  • PRJ_ID: Informação adicional da credencial que armazena o token do projeto

  • CHILD_CRED_USER: Username da credencial filha. É o nome da variável de ambiente.

  • PARENT_CRED_PASSWORD: Senha da credencial pai que sofreu a mudança

curl --request POST --header 'PRIVATE-TOKEN: \[#PRJ_TOKEN#\]' 'https://\[#GIT#\]/api/v4/projects/\[#PRJ_ID#\]/variables' --form 'key=\[#CHILD_CRED_USER#\]' --form 'value=\[#PARENT_CRED_PASSWORD#\]' 

Template de execução senhasegura

set-request-method PUT
set-content-type application/x-www-form-urlencoded
set-request-header PRIVATE-TOKEN [#COE_SENHA#]
set-request-content value=[#SENHA_NOVA#]

request http://[#IP#]/api/v4/projects/[#INFO_ADICIONAL#]/variables/[#USERNAME#]

expect [#USERNAME#]

Jenkins CI/CD

O Jenkins CI/CD8 permite que variáveis de ambiente sejam configuradas dentro dos pipelines de execução. Permite também o armazenamento seguro de valores que possam ser utilizadas dentro destes mesmos pipelines sem necessidade de exposição.

A dificuldade que os administradores encontram está em garantir que essas mesmas variáveis sejam rotacionadas de forma automática.

Através da arquitetura nativa do Jenkins, o senhasegura possibilita que as variáveis sejam injetadas em tempo de execução do pipeline a partir de nosso plugin Jenkins.

caution

Esteja atento as recomendações de segurança do Jenkins-CLI.

Plugin de Integração

O plugin de integracão do senhasegura com o Jenkins tem como objetivo:

  • Interceptar todas as variáveis de ambiente no momento de sua execução enviando para o senhasegura

  • Buscar todas as secrets que tiveram na autorização

  • Atualizar as variáveis de ambiente

  • Fornecer secrets em tempo de execução como variáveis de ambiente

O plugin auxilia para que as informações não fiquem expostas, já que só as utiliza quando é necessário, e as informações estarão centralizadas em uma única solução, sendo assim facilitando o seu gerenciamento.

Para fazer uso deste plugin é necessário que o usuário:

  1. Obtenha o plugin de integração com nossa equipe de suporte

  2. Instale o plugin de integração no Jenkins

  3. Realize a configuração adicionando na seção chamada senhasegura DSM Plugin em um dos níveis: Global, Folder ou Job

  4. Execute o plugin

Variáveis

Após a execução do plugin acesse o senhasegura para consultar todas variáveis enviadas através do menu: DevSecOps ➔ CI/CD ➔ Variáveis.

Variáveis sensíveis

O senhasegura considera como variáveis sensíveis aquelas que contêm informações confidenciais como senhas e tokens, por exemplo.

É possível enxergar a quantidade de variáveis enviadas que foram consideradas pelo senhasegura como sensíveis através do dashboard de variáveis: DevSecOps ➔ Dashboard ➔ Variáveis CI/CD.

Este dashboard também ajuda a entender quais informações podem estar expostas, quando não deveriam.

Secrets

Ao receber algumas variáveis o senhasegura entende a sensibilidade da informação e cria, de forma automatizada uma Secret para gestão destas variáveis.

As secrets poderão ser consultadas no seguinte relatório: DevSecOps ➔ Secret Management ➔ Secrets.

info

Da mesma forma o Jenkins poderá utilizar as secrets gerenciadas pelo senhasegura . Para isso será necessário criar uma autorização para aplicação e vincular as secrets que o Jenkins poderá fazer uso. Consulte o capítulo Secrets deste livro para entender como realizar este procedimento.

sectionDocker Secrets O Docker9 é um software container que fornece a abstração do sistema operacional na camada de kernel. Seu uso, no entento, não atua como um orquestrador, mas tem também a responsabilidade de disponibilizar informações sensíveis aos containers de aplicação. Seguindo sempre o mesmo princípio DevOps, estas aplicações abstraem o ambiente de execução de forma que o mesmo código de desenvolvimento possa ser implementado em um container produtivo sem ter seu comportamento afetado.

Tendo em vista que os arquivos de configuração de um container são arquivos texto abertos, o Docker fornece uma camada de gerenciamento de informações sensíveis chamada Docker Secrets10.

Execução de troca de senha com replicação no Docker Secrets

Sem necessidade de plugins extras, o senhasegura consegue replicar a senha pai alterada diretamente no servidor Docker utilizando o binário do fabricante.

Template de execução senhasegura

## general definitions
set-connect-timeout 10
set-read-timeout 5
set-ssh-version 2

## set english language
expect "*$"
exec "export LC_ALL=C"

## execute as root
expect "*$"
exec "sudo su"
expect "[sudo]*[#AUTH_USER#]*"
exec "[#AUTH_PASSWORD#]"

## remove docker secret
expect "*#"
exec "docker secret rm [#USERNAME#]"

## create new secret
expect "*#"
exec "echo "[#NEW_PASSWORD#]" | docker secret create [#USERNAME#] -"

expect "*#"
exec "exit"

expect "*$"
exec "exit"

end
caution

Consulte o manual do Docker Secrets para melhor compreensão de como você pode aprimorar o template de execução do senhasegura a sua necessidade.

chapterSecret Secrets são um conjunto de informações sensíveis que é usado para autenticação digital em ambientes DevOps. Pode incluir senhas, chaves de acesso, tokens ou mesmo um conjunto de chaves/valores a serem usados em contas, aplicações e serviços privilegiados.

Dada a crescente complexidade e crescimento da cultura e ferramentas DevOps para a suportar, o desafio é centralizar, armazenar, transmitir e auditar segredos de forma segura.

senhasegura Secret Management foi concebida/desenvolvida/criada para superar estes desafios, oferecendo uma forma segura de gerir todo o ciclo de vida do secret.

Criar uma secret

Para criar uma secret manualmente acesse: DevSecOps ➔ Secret Management ➔ Secrets.

  1. Clique no botão de ações e selecione Nova secret.

  2. Na guia Principal, preencha os seguintes campos:

    Formulário de configuração secreto
    CampoDescrição
    NomeSecret name
    IdentidadeIdentificador do Secret
    AtivoIndica se o segredo está ou não ativo
    VersãoVersão da secret
    Data de validadeDate and time for the secret to expire
    MotorMotor para o segredo a ser usado
    DescriçãoDescrição detalhada do segredo
    Chave/ValorUm conjunto de entradas chave/valor
  1. Clique na guia Access Keys para adicionar as chaves de acesso ao segredo:

    Formulário de configuração secreto - Chaves de acesso
  2. Clique sobre os registros para selecionar as chaves desejadas e em seguida clique no botão Adicionar.

  3. Clique na aba Credenciais para incluir as credenciais para o segredo:

    Formulário de configuração secreto - Credenciais
  4. Clique sobre os registros de credenciais para selecionar as desejadas e em seguida clique no botão Adicionar.

  5. Clique no botão Salvar para completar o registo

Criar aplicações

Para que os secrets sejam utilizados, eles precisam estar vinculados a uma autorização relacionada ao pedido.

Para criar uma nova aplicação, vá para DevSecOps ➔ Applications ➔ Applications.

  1. Clique no botão de ação e selecione Novo

  2. Na tela de Configuração da aplicação, complete os campos:

    CampoDescrição
    Nome da aplicaçãoIdentificação da aplicação
    Use OAuth signatureOpção para escolher que tipo de assinatura usar
    EnabledIndica se aplicação estará ativa ou não
    Line of BusinessLinha de negócio da aplicação
    Tipo de aplicaçãoIndica a categoria da aplicação
    Provisionamento automático de secretsPermite que novos par de chaves sejam criados automaticamente quando houver necessidade
    Provisioning profileIndica o perfil que será usado para o provisionamento automático
    TagsTags usadas para localizar uma segregação nesta aplicação
    DescriçãoDescrição detalhada para a aplicação
  1. Clique no botão de ações e selecione a opção Nova aplicação.

Vincular uma secret a uma autorização

É necessária uma autorização para identificar e autenticar com segurança o requerente de um segredo de aplicação e para restringir os segredos que podem ser solicitados.

Para criar uma nova autorização, siga o menu DevSecOps ➔ Applications ➔ Authorization by application.

caution

É necessário um requerimento para que uma nova autorização possa ser criada.

  1. Clique na opção Nova autorização na aplicação desejada.

  2. Na guia Securitu, preencha os seguintes campos:

    Application authorization security form
    CampoDescrição
    Recursos autorizadosLista de recursos permitidos para esta autorização
    Data/Hora de ExpiraçãoData e hora para a autorização expirar
    AtivoIndica se a autorização está ou não ativa
    Ativar a criptografia de informações sensíveisIndica se a informação sensível deve ser encriptada ou não
    AmbienteSegregação do ambiente onde a aplicação esta
    SistemaSegregação do sistema onde a aplicação utiliza
    IPs permitidosLista de IPs permitidos para esta autorização
    Referências HTTP permitidasLista de referências HTTP permitidas para esta autorização
  1. Clique na guia Secrets para ligar os segredos a serem permitidos a esta autorização:

    Formulário de autorização de pedido de autorização
    CampoDescrição
    IDID da Secret
    SecretNome da Secret
  1. Clique sobre sobre as secrets desejadas para seleciona-las

  2. Clique no botão Salvar para completar o registo

Dashboard

Através do menu: DevSecOps ➔ Dashboard ➔ Secrets você vai encontrar dados e gráficos sobre os secrets do sistema como por exemplo:

  • Aplicação por linha de negócio

  • Número de autorizações

  • Quantidade de secrets consultados por dia

  • Autorizações por ambientes

Provisionamento dinâmico de credenciais

Acesse o relatório de Dynamic provisioning: PAM ➔ Dynamic provisioning ➔ Profile. Clique no botão de ação do relatório Adicionar profile. Em seguida preencha o formulário:

  1. No campo Identificador insira um termo para que este perfil seja de fácil identificação nos relatórios.

  2. Indique se ele estrá Ativo para o uso.

  3. Em seguida selecione o Tipo deste profile que podem ser:

    • Linux

    • MySQL

    • Oracle

    • SQL Server

    • Windows

  4. No campo Dispositivos selecione um dispositivo já cadastrado no senhasegura

  5. Indique o Template de criação de credencial que será usado por este profile. Ao clicar no ícone de adição próximo ao campo um campo adicional para inserir um outro template de criação de credencial será disponibilizado.

  6. Da mesma forma selecione o Template de remoção de credencial, ícone de adição realiza a mesma ação do campo anterior disponibilizando a opção de inserir mais de um template de remoção de credencial que poderá ser usado pelo profile.

  7. Em seguida insira o TTL Padrão, ou seja, o tempo em segundos em que esta credencial será válida antes de ser deletada automaticamente.

Após finalizar o cadastro do profile siga para o menu DevSecOps ➔ Applications ➔ Applications e no formulário preencha:

  1. Insira o Nome da aplicação

  2. Selecione se assinatura OAuth estrá habilitada ou não, e se esta aplicação estará disponível para o uso do profile criado anteriormente.

  3. Em seguida indique se a aplicação será automaticamente provisionada para o secrets.

  4. No campo Profile de provisionamento dinâmico de cloud selecione o perfil responsável por essa ação.

  5. Do mesmo modo selecione o Perfil de provisionamento dinâmico de credencial que será usado.

  6. Se desejar insira tags para associação no campo Tags e no campo Descrição insira um descritivo para melhor entendimento da aplicação.

  7. Por fim clique em Salvar

Plugin de integração com Jenkins