Apresentação e considerações

  • Este projeto tem como objetivo apresentar de forma prática o Vault da HashiCorp
  • A configuração/orquestração do ambiente será realizado através do Ansible, que terá como objetivo preparar 2 containers:
    • 1 MySQL
    • 1 Vault Server
  • Após a configuração teremos um ambiente totalmente disponível para realização dos exemplos que teremos logo abaixo.
  • O ambiente foi configurado na Amazon AWS em um instância t2.micro, porém é possível que você execute em outros players de Cloud ou até mesmo em seu ambiente local.

O que é o Vault HashiCorp?

O Vault nada mais é que uma ferramenta para acessar de forma segura os "secrets". Um secret pode ser qualquer coisa que você deseja controlar o acesso, como chaves, API’s, senhas, certificados e etc.

O Vault fornece uma interface unificada para qualquer secret, proporcionando um controle de acesso totalmente seguro e com um registro de auditoria bem detalhado.

Escrito em Go (linguagem criada pelo Google) e distribuído em um único binário, é possível realizar sua instação com poucos comandos.

Uma vez que que o binário esteja em seu ambiente, basta executar os comandos, possibilitando a configuração de um client/server.

Orquestrando o ambiente

  • Configurando o ambiente (AWS ou OpenStack)

Passo 1 – Clone do projeto

$ git clone https://github.com/vandocouto/Vault-Meetup-Churrops.git

Passo 2 – Acessando o projeto

$ cd Vault-Meetup-Churrops/ansible/vault/

Passo 3 – Configurando o arquivo hosts

  • No arquivo hosts deverá conter o ip da instância (AWS ou OpenStack) – Ubuntu 16.04, e o caminha da chave de acesso (vault.pem)
  • No meu exemplo o ip da instância será 54.172.229.173
[vault]
54.172.229.173

[all:vars]
# EC2
ansible_ssh_user=ubuntu
ansible_ssh_private_key_file=../../keys/vault.pem

# SSL
fqdn=tutoriaisgnulinux.com

Passo 4 – Preparando a instância para “rodar” o playbook

  • Instalado via ansible o pacote python-simplejson.
$ ansible 54.172.229.173 -i hosts -m 'raw apt-get -y install python-simplejson' -b

Passo 5 – Ansible playbook

$ ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -i hosts ./tasks/main.yml

Vault na prática

Configurando o ambiente

Passo 6 – Criando a variável de dentro da instância EC2

$ export VAULT_ADDR=https://127.0.0.1:8200

Passo 7 – Criando a variável no ambiene local

$ export VAULT_ADDR=https://54.172.229.173:8200

keys – token – sealed – unseal

  • Durante inicialização (vault init) as chaves de criptografia serão geradas (chaves unseal e o token de root inicial).
  • Esta é a única vez que todos esses dados são conhecidos pelo Vault
  • É necessário que guarde todas essas chaves em um local seguro, distribuindo em ambientes diferentes.
  • Quando o Vault é resselado (“sealed”), reiniciado, ou parado, você deverá fornecer pelo menos 3 chaves para que ele volte ao estado (“desselado”) unseal.

Passo 8 – Inicialização – Vault init

$ vault init -tls-skip-verify
Unseal Key 1: QLBm12RW4diu7AEwzLW6V7WkEHA9/7OktJ2YcqZ3Vz15
Unseal Key 2: tdjpuYHFi+GNSv/CIZ5hC1WppjFKuBt5toeADGYIe9Ex
Unseal Key 3: qz/cKss9B91ueRtBqfkvy5zDsltQB774nr8FNNcyqv6R
Unseal Key 4: blbft5ofQXphq/3mwPm9uwQ705Oc/+qB+eRQdP5Kwamn
Unseal Key 5: KWNKH3BuSxqLodN0YxuPnLEh/3nMOIaFpp/yeNKD+qKD
Initial Root Token: cbbfb448-60ab-22f8-c585-afa4e6aed339

Vault initialized with 5 keys and a key threshold of 3. Please
securely distribute the above keys. When the vault is re-sealed,
restarted, or stopped, you must provide at least 3 of these keys
to unseal it again.

Vault does not store the master key. Without at least 3 keys,
your vault will remain permanently sealed.

Inserindo as chaves

Passo 9 – Chave 1 e Chave 2

 
evandrocouto@desktop:~$ vault unseal -tls-skip-verify QLBm12RW4diu7AEwzLW6V7WkEHA9/7OktJ2YcqZ3Vz15
Sealed: true
Key Shares: 5
Key Threshold: 3
Unseal Progress: 1

Unseal Nonce: 6b2fb500-bb6a-bdc7-2817-f3d5857d2407
evandrocouto@desktop:~$ vault unseal -tls-skip-verify tdjpuYHFi+GNSv/CIZ5hC1WppjFKuBt5toeADGYIe9Ex
Sealed: true
Key Shares: 5
Key Threshold: 3
Unseal Progress: 2
Unseal Nonce: 6b2fb500-bb6a-bdc7-2817-f3d5857d2407

root@ip-10-0-0-111:/home/ubuntu# vault unseal -tls-skip-verify qz/cKss9B91ueRtBqfkvy5zDsltQB774nr8FNNcyqv6R
Sealed: false
Key Shares: 5
Key Threshold: 3
Unseal Progress: 0
Unseal Nonce:

Passo 11 – Chave 3

$vault unseal -tls-skip-verify
Key (will be hidden): 
Sealed: false
Key Shares: 5
Key Threshold: 3
Unseal Progress: 0
Unseal Nonce:

Bingo!

evandrocouto@desktop:~$ vault unseal -tls-skip-verify
Vault is already unsealed.
  • O processo unseal é totalmente stateful, possibilitando que através de outro computador com o Vault instalado, possa executar o processo de desbloqueio (unseal),
    isso quanto o Vault estiver direcionado para o mesmo Vault Server.
  • Isso é extremamente importante para o processo de unseal. Somente assim, duas ou mais pessoas poderão liberar o Vault.
  • O Vault pode ser “aberto” de vários computadores e as chaves nunca deverão estarem juntas.
  • Desta forma, um único operador não possuirá chaves suficientes para ser mal-intencionado.

Vault Auth

  • Uma vez que o ambiente esteja unseal, o passo seguinte será o comando vault auth, que terá como função autenticar-se no Vault com o token root.
  • Com o token root, será possível fechar o Vault (Único operador que poderá fazer isso).
  • Isso permite que um único operador bloqueie o Vault em uma emergência sem consultar os demais operadores.
  • Qaundo o Vault é selado (sealed) novamente, ele limpa todo o estado (incluindo a chave de criptografia) da memória.

Passo 12 – vault auth

$ vault auth -tls-skip-verify 
Token (will be hidden): 
Successfully authenticated! You are now logged in.
token: 11fbbd18-3e55-e49d-f949-0148c6bb0c87
token_duration: 0
token_policies: [root]

Primeiro Secret

  • Para criar o primeiro secret, basta utilizar o comando vault write,
    informando o path.

Passo 13 – vault write

$ vault write -tls-skip-verify secret/hello value=world 
Success! Data written to: secret/hello

Lendo um secret

  • O Vault lê os dados do armazenamento e em seguida desencriptografa-os.
  • O formato de saída é propositadamente separado em espaços em branco para facilitar a utilização de ferramentas como cut, awk, grep e etc.
  • Além do formato do Vault, é possível também utilizar ferramentas como o jq (apt-get Install jq), podendo enviar os dados no formato JSON.

Passo 14 – vault read

$ vault read -tls-skip-verify secret/hello 
Key             	Value
---             	-----
refresh_interval	768h0m0s
value           	world

Passo 15 – vault read (json)

vault read -tls-skip-verify -format=json secret/hello
{
	"request_id": "55814798-f9bc-9740-594f-a862d8e76e87",
	"lease_id": "",
	"lease_duration": 2764800,
	"renewable": false,
	"data": {
		"value": "world"
	},
	"warnings": null
}

Passo 16 – vault read (json + jq)

$ vault read -tls-skip-verify -format=json secret/hello | jq -r .data.value
world

Excluindo um secret

  • Para excluir um secret, basta utilizar o comando vault delete.

Passo 17 – vault delete

$ vault delete -tls-skip-verify secret/hello
Success! Deleted 'secret/hello' if it existed.

Backends secret (secret/prefix)

  • Para que seja possível escrever os secrets no Vault é necessário especificar qual o backend que pretende utilizar.
  • Por padrão, o Vault monta um backend chamado de genérico.
  • O backend lê e grava os dados no Storage Backend.
  • O Vault suporte outros tipos de backends, além do genérico, e esse recurso em particular é o que torna o Vault exclusivo.
  • O Vault se comporta como um sistema de arquivos: Os backends são montados em caminhos específicos (backend/prefix).
Alguns backend suportados:
* CockroachDB
* Consul 
* DynamoDB
* Etcd
* Filesystem
* Google Cloud
* In-Memory
* Mysql
* PostrgreSQL
* Cassandra
* S3
* Swift
* Zookeper

Mount Backend

  • Assim como em um sistema de arquivos normal, o Vault pode montar um backend várias vezes em diferentes pontos de montagem.
  • Também é importante saber que com o Vault é possível aplicar politicas de segurança através de caminhos diferentes.

Passo 18 – vault mounts (list)

$ vault mounts -tls-skip-verify
Path        Type       Accessor            Plugin  Default TTL  Max TTL  Force No Cache  Replication Behavior  Description
cubbyhole/  cubbyhole  cubbyhole_3d283166  n/a     n/a          n/a      false           local                 per-token private secret storage
secret/     generic    generic_61fb4a37    n/a     system       system   false           replicated            generic secret storage
sys/        system     system_997f9d46     n/a     n/a          n/a      false           replicated            system endpoints used for control, policy and debugging

Passo 19 – vault mount (create)

$ vault mount -tls-skip-verify generic
Successfully mounted 'generic' at 'generic'!

Passo 20 – vault mount (list)

$ vault mounts -tls-skip-verify
Path        Type       Accessor            Plugin  Default TTL  Max TTL  Force No Cache  Replication Behavior  Description
cubbyhole/  cubbyhole  cubbyhole_3d283166  n/a     n/a          n/a      false           local                 per-token private secret storage
generic/    generic    generic_baf5911b    n/a     system       system   false           replicated            
secret/     generic    generic_61fb4a37    n/a     system       system   false           replicated            generic secret storage
sys/        system     system_997f9d46     n/a     n/a          n/a      false           replicated            system endpoints used for control, policy and debugging

Unmount backend

  • Uma vez que o backend for desmontado, todos os seus secrets serão revogados e seus dados excluídos.

Passo 21 – vault unmount

$ vault unmount -tls-skip-verify generic 
Successfully unmounted 'generic' if it was mounted

Vault Token

  • Você pode criar mais tokens usando o vault token-create
  • Por padrão, o Vault token criará um token filho do seu token atual (pai) que herdará todos as mesmos direitos (políticas).
$ vault token-create -tls-skip-verify
Key            	Value
---            	-----
token          	ee3afb8f-152d-3178-0fdc-c97ea03111f3
token_accessor 	8fa5e81f-71ad-27ca-d104-e69bba49891e
token_duration 	0s
token_renewable	false
token_policies 	[root]
  • Depois que um token é criado, é possível revogá-lo com o token-revoke.
$ vault token-revoke -tls-skip-verify ee3afb8f-152d-3178-0fdc-c97ea03111f3
Success! Token revoked if it existed.

Auth Backends

  • Além dos tokens, é possível também adicionar outros métodos de autenticação.
  • Auth backends permite métodos alternativos de identificação com o Vault.
  • Essas identidades são vinculadas de volta a um conjunto de políticas de acesso, assim como tokens.

Passo 22 – Habilitando o método de autenticação pelo GitHub

$ vault auth-enable -tls-skip-verify github
Successfully enabled 'github' at 'github'!

Passo 23 – Criando o secret/prefix e fixando a organização do GitHub

$ vault write -tls-skip-verify auth/github/config organization=tutoriaisgnulinux
Success! Data written to: auth/github/config

Passo 24 – Por fim, com o comando vault auth, basta informar o token gerado no GitHub para obter acesso no Vault.

$  vault auth -tls-skip-verify -method=github token=1a014ecc8e71d2938abba8d8d8830fd71dd052cd
Successfully authenticated! You are now logged in.
The token below is already saved in the session. You do not
need to "vault auth" again with the token.
token: 17229894-200b-80aa-f8af-e9ec813f7100
token_duration: 2764800
token_policies: [default]

Passo 25 – Para revogar a autenticação

$ vault token-revoke -tls-skip-verify -mode=path auth/github
Success! Token revoked if it existed.

Passo 26 – Desativando o backend

$ vault auth-disable -tls-skip-verify github

Policys

  • As policys do Vault controlam os acessos dos usuários.
  • Para autenticação, o Vault possui várias opções ou backends que podem ser ativados e usados.
  • Para autorização e políticas (policys), o Vault sempre usa o mesmo formato.
  • Todos os backends de autenticação devem mapear as identidades de volta para as políticas principais configuradas com o Vault.
  • Ao inicializar o Vault, sempre existe uma política (policy) especial que não pode ser removida: (root).
  • Está politica (policy) é uma política especial que lhe dará o acesso de super-user em tudo que há no Vault.
  • Uma identidade mapeada para a diretiva root pode fazer qualquer coisa.
  • As políticas do Vault controlam o acesso do usuário.
  • Para autenticação, o Vault possui várias opções ou backends que podem ser ativadas e usadas.
  • Para autorização e políticas, o Vault sempre usa o mesmo formato.
  • Todos os backends de autenticação devem mapear identidades de volta para as políticas principais configuradas com o Vault.
  • Ao inicializar o Vault, sempre existe uma política especial que não pode ser removida: a política raiz.
  • Esta política é uma política especial que lhe dá acesso de superusuário a tudo no Vault.
  • Uma identidade mapeada para a diretiva raiz pode fazer qualquer coisa.
  • As políticas (policys) no Vault são criadas no formato HCL.
  • O HCL é um formato de configuração legível para humanos e também é compatível com o formato JSON.
Exemplo:
ath "secret/*" {
  capabilities = ["create"]
}

path "secret/foo" {
  capabilities = ["read"]
}

path "auth/token/lookup-self" {
  capabilities = ["read"]
}

Passo 27 – vault auth token root

vault auth -tls-skip-verify
Token (will be hidden): 
Successfully authenticated! You are now logged in.
token: ba3534bd-cadc-5520-30f9-c51449ec29c6
token_duration: 0
token_policies: [root]

Passo 28 – Listando as policys

$ vault read -tls-skip-verify sys/policy
Key     	Value
---     	-----
keys    	[default root]
policies	[default root]

Criando policys

Passo 29 – Acesse o diretório policys

$ cd policys/

Passo 30 – Criando a policy meetup

$ vault write -tls-skip-verify sys/policy/meetup rules=@meetup.hcl
Success! Data written to: sys/policy/meetup

Passo 31 – Criando a policy github

$ vault write -tls-skip-verify sys/policy/github rules=@github.hcl
Success! Data written to: sys/policy/github

Passo 32 – Lendo a estrutura da policy
meetup

$ vault read -tls-skip-verify sys/policy/meetup
Key  	Value
---  	-----
name 	meetup
rules	path "secret/meetup" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

github

$ vault read -tls-skip-verify sys/policy/github
Key  	Value
---  	-----
name 	github
rules	path "secret/github/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

Mapeando policys para outros Backends

Passo 33 – Novamente acessando o Vault com o token do GitHub

$ vault auth -tls-skip-verify -method=github token=1a014ecc8e71d2938abba8d8d8830fd71dd052cd
Successfully authenticated! You are now logged in.
The token below is already saved in the session. You do not
need to "vault auth" again with the token.
token: 17229894-200b-80aa-f8af-e9ec813f7100
token_duration: 2764800
token_policies: [default]

Passo 34 – Criando um novo secret no path secret/github “hello” com o valor “world”

$ vault write -tls-skip-verify secret/github/hello value=world
Error writing data to secret/github/hello: Error making API request.

URL: PUT https://127.0.0.1:8200/v1/secret/github/hello
Code: 403. Errors:

* permission denied

ERROR!

Resolvendo o problema

Passo 35 – Mapeando a indentidade (github) para o token do GitHub.

$ vault write -tls-skip-verify auth/github/map/teams/default value=github
Success! Data written to: auth/github/map/teams/default

Passo 36 – Novamente com o token do GitHub.

$ vault auth -tls-skip-verify -method=github token=1a014ecc8e71d2938abba8d8d8830fd71dd052cd
Successfully authenticated! You are now logged in.
The token below is already saved in the session. You do not
need to "vault auth" again with the token.
token: 996b80c8-7bc5-b67f-2aad-80796bdcf821
token_duration: 2764800
token_policies: [default github]

PAsso 37 – Escrevendo no secret/github com o token do GitHub.

$ vault write -tls-skip-verify secret/github/hello value=world
Success! Data written to: secret/github/hello

Bingo!

Brincando com os tokens

Passo 38 – Autenticando com o token root

vault auth -tls-skip-verify
Token (will be hidden): 
Successfully authenticated! You are now logged in.
token: ba3534bd-cadc-5520-30f9-c51449ec29c6
token_duration: 0
token_policies: [root]

Passo 39 – Criando o token para a policy meetup

$ vault token-create -tls-skip-verify -policy=meetup
Key            	Value
---            	-----
token          	45f823ce-fc72-8ca1-f8f0-9c9f4e38078d
token_accessor 	0cd5d109-1976-5791-2882-32fd03c48a36
token_duration 	768h0m0s
token_renewable	true
token_policies 	[default meetup]

Passo 40 – Acessando com o token criado para policy meetup

$ vault auth -tls-skip-verify
Token (will be hidden): 
Successfully authenticated! You are now logged in.
token: 45f823ce-fc72-8ca1-f8f0-9c9f4e38078d
token_duration: 2764641
token_policies: [default meetup]

Passo 41 – Escrevendo no secret/meetup

vault write -tls-skip-verify secret/meetup value=world
Success! Data written to: secret/meetup

Passo 41 – Escrevendo no secret/meetup e criando um novo prefix com o valor world

ERROR!

vault write -tls-skip-verify secret/meetup/teste value=world
Error writing data to secret/meetup/teste: Error making API request.

URL: PUT https://127.0.0.1:8200/v1/secret/meetup/teste
Code: 403. Errors:

* permission denied
  • Não foi possivel pelo fato da policy (meetup.hcl) não permitir que seja criado novos prefix.
path "secret/meetup" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
  • Para resolver, basta alterar o arquivo (meetup.hcl), inserindo o /*.
path "secret/meetup/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

Passo 42 – Ajustando novamente a policy

$ vault write -tls-skip-verify sys/policy/meetup rules=@meetup.hcl
Success! Data written to: sys/policy/meetup

Passo 43 – Testando novamente com o token do meetup

$ vault write -tls-skip-verify secret/meetup/teste value=world
Success! Data written to: secret/meetup/teste

Vault e AWS

Backend secret AWS

  • Com o Backend AWS é possível gerir as credenciais de acesso no Amazon AWS dinamicamente bom base nas políticas IAM.
  • As credenciais podem ser geradas facilmente, podendo ser revogadas quando a concessão (lease) do Vault expirar.

Passo 44 – Montando o backend aws.
Obs: Ao contrário do backend genérico, o backend da Aws não é montado por padrão.

$ vault mount -tls-skip-verify aws
Successfully mounted 'aws' at 'aws'!

Passo 45 – Em seguida, será preciso informar as credenciais (AWS) que o Vault usuará para gerenciar o IAM

$ vault write -tls-skip-verify aws/config/root access_key="$AWS_ACCESS_KEY_ID" secret_key="$AWS_SECRET_ACCESS_KEY" region="us-east-1"
Success! Data written to: aws/config/root

Passo 46 – Neste passo será necessário importar o arquivo iam-policy.json

  • Isso é usado para criar dinamicamente um novo par de credenciais IAM quando necessário.
  • A policy será carregada através do arquivo chamado iam-policy.json.
 cat iam-policy.json 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}
  • Function: Nome lógico que será mapeado para uma policy, usado para gerenciar as credenciais.
  • Por exemplo: Criando a function “dev” através da policy inline:
$ vault write -tls-skip-verify aws/roles/dev policy=@iam-policy.json
Success! Data written to: aws/roles/dev
Criando dinamicamente um par de credenciais IAM, quando necessário.

Passo 46 – Para gerar um novo conjunto de credenciais IAM, bastar ler executar a function abaixo:

$ vault read -tls-skip-verify aws/creds/dev
Key            	Value
---            	-----
lease_id       	aws/creds/dev/a6ef57b6-1187-1ca1-4f11-6bfafe9fb642
lease_duration 	768h0m0s
lease_renewable	true
access_key     	AKIAJMZFG5PAZ5EPFS7Q
secret_key     	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
security_token

Passo 47 – Caso execute novamente, será criado um novo conjunto de credenciais

$ vault read -tls-skip-verify aws/creds/dev
Key            	Value
---            	-----
lease_id       	aws/creds/dev/a6ef57b6-1187-1ca1-4f11-6bfafe9fb642
lease_duration 	768h0m0s
lease_renewable	true
access_key     	AKIAJZ5YRPHFH3QHRRRQ
secret_key     	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
security_token

Passo 48 – Neste outro exemplo, será cria uma function “de leitura” usando uma nova policy AWS

$ vault write -tls-skip-verify aws/roles/readonlyec2 arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
Success! Data written to: aws/roles/readonlyec2

Passo 49 – Para gerar o conjunto de chaves IAM, bastar ler executar a function readonlyec2

$ vault read -tls-skip-verify aws/creds/readonlyec2
Key            	Value
---            	-----
lease_id       	aws/creds/readonlyec2/675a475f-3adf-ef3c-3de5-936b8f7d736b
lease_duration 	3m0s
lease_renewable	true
access_key     	AKIAJTTKWCRXB3QE2JLA
secret_key     	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
security_token

Passo 50 – Criando um policy para o prefix ec2rdss3vpcfull, carregando a policy do arquivo ec2rdss3vpcfull.json

$ cd policys
$ vault write -tls-skip-verify aws/roles/ec2rdss3vpcfull policy=@ec2rdss3vpcfull.json

Passo 51 – Gerando o access_key e o secret_key

Obs: A policy ec2rdss3vpcfull irá conceder a permissão Full para EC2 e RDS.

$ vault read -tls-skip-verify aws/creds/ec2rdss3vpcfull
Key            	Value
---            	-----
lease_id       	aws/creds/ec2rdss3vpcfull/aefcc6f6-59e9-5be1-cdfa-4b89432a0b73
lease_duration 	3m0s
lease_renewable	true
access_key     	AKIAJ3BCNUC6X2SYYACA
secret_key     	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
security_token

Vault SSH

  • O backend secret SSH do Vault fornece autenticação segura e autorização para acesso a máquinas através do protocolo SSH.
  • O backend SSH do Vault ajuda a gerenciar a infra-estrutura da máquina, fornecendo várias maneiras de emitir credenciais para o protocolo SSH.
  • Temos três tipos suportados para o backend SSH, são eles:

Signed Certificates

  • O Vault gerencia novas chaves privadas e públicas.

SSH OTP

  • O Vault emite uma senha SSH de uma única vez (OTP).
  • A principal preocupação com o tipo de backend OTP é a conexão do host remoto com o Vault; se comprometido, um invasor poderia falsificar o servidor do Vault retornando pedido bem-sucedido.

Dynamic Key:

  • O administrador registra uma chave secret com privilégios.
  • Para cada solicitação de credencial autorizada, o Vault cria um novo par de chaves SSH e acrescenta a chave pública recém-gerada ao arquivo authorized_keys para o nome de usuário configurado no host remoto.
  • O Vault usa o script de instalação configurável para conseguir isso.
Veremos os métodos Signed Certificates e Dynamic Key

Passo 52 – Montando o backend SSH

$ vault mount ssh

Passo 53 – Carregando a chave (.pem) default, para o Vault

$ vault write ssh/keys/jenkins key=@jenkins.pem

Método 1 – (Signed Certificates)

Passo 54 – Criando a role chamada jenkins (instância – EC2 / IP:54.197.7.243/32)

$ vault write ssh/roles/jenkins key_type=dynamic key=jenkins admin_user=ubuntu default_user=ubuntu cidr_list=54.197.7.243/32

Passo 55 – Logando através do Vault na instância (jenkins / IP: 54.197.7.243)

$ vault ssh -role jenkins ubuntu@54.197.7.243

Método 2 – (Dynamic Key)

Passo 56 – Gerando uma chave (pem) temporário e salvando no arquivo jenkins-vaul.pem

$ vault write -format=json ssh/creds/dynamic_key_role ip=54.197.7.243 | jq -r .data.key > jenkins-vault.pem

Passo 57 – Ajustando a permissão do arquivo (jenkins-vault.pem)

$ chmod 400 jenkins-vault.pem

Passo 58 – Logando na instância (jenkins / IP: 54.197.7.243), coma a chave (pem) gerada pelo Vault

ssh -i jenkins-vault.pem ubuntu@54.197.7.243

Passo 59 – Verificando os backends montados

$ vault mounts

Passo 60 – Desmontando o backend ssh

$ vault unmount ssh

Lease, Renew, and Revoke

  • Por segurança o Vault guarda por um determinado período as informações em metadados contendo a duração do tempo, renovabilidade e muito mais de um secret.
  • O Vault precisa garantir que os dados serão válidos durante a duração que foi determinado (TTL).
  • Uma vez que aquele arrendamento do secret expirou, o Vault pode revogar automaticamente os dados, e com isso o consumidor não poderá mais ter certeza que aquela informação do secret seja válida.
  • Após revogados, os consumidores dos secrets precisam fazer o check-in no Vault para renovar o contrato de arrendamento (caso permitido).
  • Isso faz com que os logs de auditoria do Vault sejam mais valiosos e também tornando a chave muto mais fácil.
  • Todos os secrets dinâmicos no Vault são obrigados a terem um contrato de arrendamento.
  • Quando uma locação for revogada, o secret imediatamente será invalidado para evitar novas renovações.
  • Exemplo:
    • Com o backend secret da AWS, as chaves de acesso serão excluídas da AWS no momento em que o secret for revogado.Isso tornará as chaves de acesso inválida a partir desse ponto.
  • OBs: Com o Backend (Generic Backend Storage) com os secret arbitrários não será possível trabalhar com o lease.

Passo 61 – Ajustando o lease do backend AWS.

$ vault write -tls-skip-verify aws/config/lease lease=30s lease_max=5m
Success! Data written to: aws/config/lease

Passo 62 – Verificando as alterações

$ vault read -tls-skip-verify aws/creds/dev
Key            	Value
---            	-----
lease_id       	aws/creds/dev/d9dfa5d0-bc22-3677-0063-55ed1ebd1fa0
lease_duration 	30s
lease_renewable	true
access_key     	AKIAJDAKPDF4ONFRF5FQ
secret_key     	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
security_token

Revogando backends

Passo 63 – Revogando o backend AWS

$ vault revoke -tls-skip-verify -prefix aws/
Success! Revoked the secret with ID 'aws/', if it existed.

Passo 55 – Revogando o backend GitHub

$  vault revoke -tls-skip-verify -prefix github/
Success! Revoked the secret with ID 'github/', if it existed.

Brincando com os scripts python (Using the HTTP APIs)

  • No diretório scripts, contém dois arquivos (get – post) para testes do Vault via requests.
  • Para executá-los, basta alterar as variáveis de ip, value e payload.

Post

$ cd scripts
$ python post-secret_hello.py

Get

$ cd scripts
$ python get-secret_hello.py

Fonte:
https://www.vaultproject.io