Configurando política de controle de acesso no Hashicorp Vault utilizando Terraform

Este artigo é a continuação de outro chamado Criação e configuração de um servidor Vault utilizando Terraform. Nele vimos como criar a infraestrutura necessária para rodar um servidor Vault utilizando Docker e recursos da AWS como ECS (com EC2 e não Fargate), S3 e KMS, e sempre através do Terraform.

Neste artigo iremos entender, agora com o servidor criado e pronto pra ser usado, como podemos configurá-lo para uso dentro de uma organização, com múltiplos projetos e equipes onde dentro de cada equipe há mais de um nível de acesso já que nem todo mundo pode ter o mesmo nível de controle sob todas as senhas.

Recomendo que você leia o outro artigo, já que este vai retomar de onde o último parou, mas caso você já tenha noção de como levantar um servidor Vault e está interessado apenas na parte de controle de acesso, aqui vai um resumo de como tudo foi feito:

• O armazenamento das informações está sendo feito em um bucket da S3
• O Vault foi configurado para realizar Auto Unseal utilizando uma chave KMS
• A imagem oficial do Vault está sendo gerenciada pela ECS
• Uma solicitação de frota spot da EC2 está levantando as máquinas usadas como instância do cluster da ECS
• Tudo isso foi feito dentro de um módulo Terraform

TLDR: Caso você não esteja interessado em ler o artigo e quer apenas saber como fica a solução final o código resultante está neste repositório.

Porém, se você apenas aplicar o código do repositório não vai funcionar. A ordem de execução de alguns passos é importante então use o repositório como referência e leia o artigo para entender como atingir o mesmo resultado.

Configuração inicial

Agora que aplicamos a infraestrutura vamos conferir se o container está rodando como esperado. Faça isso com o seguinte comando:

aws ecs list-tasks --cluster Vault

A resposta do comando tem que ser algo do tipo:

{    "taskArns": [      "arn:aws:ecs:us-east-1:123456789012:task/Vault/example"    ]}

Isso significa que há uma task (ou seja, um container) em execução. Vamos acessar a instância do Vault para realizar a configuração inicial.

Acessando a máquina do servidor via SSH

Gerando a chave usando outputs

Para acessarmos via SSH o servidor criado é necessário primeiro que se tenha a chave de acesso .pem.

Quando criamos uma instância na AWS pelo painel baixamos essa chave no momento da criação, como estamos gerenciando tudo via Terraform precisamos recuperar a chave utilizando outputs.

Outputs são valores retornados pelos recursos do Terraform para serem usados como variáveis para outros recursos ou alguma outra finalidade fora do Terraform. Nosso exemplo cai no segundo caso já que o valor em questão é uma chave necessária para conexão SSH com o servidor.

Para começar crie um arquivo no módulo do servidor chamado outputs.tf

touch modules/server/outputs.tf

Defina um output para a chave e extraia seu valor do recurso tls_private_key através do atributo private_key_pem.

output "pem" {  value       = tls_private_key.vault.private_key_pem  sensitive   = true  description = "Key pair private key pem for Vault's server"}

Agora sempre que o módulo do servidor for usado será possível recuperar a chave .pem. Neste projeto o módulo está sendo utilizado na raiz, então para termos acesso é necessário repetir os passos também na raiz do projeto:

touch ./outputs.tf

Porém dessa vez extraia o valor do módulo em si:

output "server_pem" {  value       = module.vault.pem  sensitive   = true  description = "Key pair private key pem for Vault's server"}

Aplique novamente a configuração:

terraform apply

Como não houve nenhuma mudança na infraestrutura em si o Terraform irá aplicar a configuração, mas note a mensagem que vem junto da resposta do comando:

Changes to Outputs:  + server_pem = (sensitive value)You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.

Você pode recuperar o valor de qualquer output da raiz do projeto com o comando terraform output <nome-do-output>. Recupere o valor da chave e coloque dentro de um arquivo .pem:

terraform output -raw server_pem > vault.pem

A opção -raw serve para dizer ao Terraform retornar o valor do output sem quebra de linha ou espaços a mais (OBS.: só funciona pra string).

O conteúdo desse arquivo é sensível, então gerencie ele com atenção e tome cuidado para não dar git add nele. Além disso, modifique as permissões do arquivo para serem mais restritivas:

chmod 400 vault.pem

Recuperando o IP do servidor com data sources

A última coisa que falta pra conseguirmos conectar no servidor é o seu IP. O ideal seria extrair esse valor do recurso em questão, porém o módulo Terraform do servidor não cria a máquina do diretamente. Ao invés disso é criada uma solicitação de frota spot da EC2 e a solicitação em si cria a máquina.

OBS.: Ao recriar ou destruir a solicitação spot o Terraform não destroi a máquina criada pela solicitação, então tome cuidado para que isso não gere um custo adicional na sua infraestrutura.

Então como podemos fazer para recuperar essa informação através do Terraform? Nós podemos utilizar outra funcionalidade da ferramenta chamada data source.

Data sources são uma maneira do Terraform recuperar informações sobre a infraestrutura criada fora da configuração definida pelos arquivos .tf do projeto. No nosso caso criamos um recurso (solicitação spot) que criou outro recurso (servidor da EC2) ao qual não temos acesso direto.

Para recuperar as informações da instância, utilize a seguinte configuração de data source no main.tf:

data "aws_instance" "server" {  instance_tags {    Name = "Vault"  }}

Note que para garantir que o Terraform busque o servidor certo estamos fazendo um filtro pelo valor da tag Name.

Utilize o data source para gerar um output:

output "server_ip" {  value       = data.aws_instance.server.public_ip  description = "Public IP of the EC2 instance acting as ECS custer"}

Aplique a configuração com terraform apply. Como o valor desse output não foi definido como sendo sensível (igual o valor da chave .pem) ele irá aparecer no fim da resposta do comando:

Outputs:server_ip = "12.345.678.90"server_pem = <sensitive>

Validando acesso via SSH

Acesse a instância usando as informações adiquiridas. A AMI da máquina é um Amazon Linux, então o usuário neste caso é o ec2-user. O comando completo fica:

ssh -i ./vault.pem ec2-user@12.345.678.90

Substituindo 12.345.678.90 pelo IP presente na resposta do último terraform apply.

Execute o comando para acessar a instância e verifique que o container do Vault está rodando com docker ps

The authenticity of host '12.345.678.90 (12.345.678.90)' can't be established.ECDSA key fingerprint is SHA256:36A9E7F1C95B82FFB99743E0C5C4CE95D83C9A430AA.Are you sure you want to continue connecting (yes/no/[fingerprint])? yesWarning: Permanently added '12.345.678.90' (ECDSA) to the list of known hosts.   __|  __|  __|   _|  (   \__ \   Amazon ECS-Optimized Amazon Linux AMI 2018.03.20210712 ____|\___|____/For documentation, visit http://aws.amazon.com/documentation/ecs[ec2-user@ip-172-31-0-173 ~]$ docker psCONTAINER ID        IMAGE                            COMMAND                  CREATED             STATUS                       PORTS                    NAMESe24ee608dc99        vault:latest                     "docker-entrypoint.s…"   About an hour ago   Up About an hour             0.0.0.0:8200->8200/tcp   ecs-vault-1-vault-ec8cc6bcf6a591c8b001ae2134529ac6        amazon/amazon-ecs-agent:latest   "/agent"                 About an hour ago   Up About an hour (healthy)                            ecs-agent[ec2-user@ip-172-31-0-173 ~]$

Inicializando o Vault

A inicialização de um servidor Vault é o processo de configuração inicial, onde são geradas as chaves de criptografia, que serão usadas para armazenar as informações do Vault de forma segura, e o token de acesso root, que será usado para gerar as primeiras políticas de acesso/usuários.

Uma vez dentro da instância, acesse o container em execução do Vault:

docker exec -it <id> ash

Substituindo <id> pelos 3 primeiro dígitos do valor da coluna CONTAINER ID exibido pelo comando docker ps. No nosso exemplo ficaria:

docker exec -it e24 ash

Uma vez dentro do container, inicialize o Vault com o comando vault operator init:

/ # vault operator initRecovery Key 1: k1Recovery Key 2: k2Recovery Key 3: k3Recovery Key 4: k4Recovery Key 5: k5Initial Root Token: rtSuccess! Vault is initializedRecovery key initialized with 5 key shares and a key threshold of 3. 

Please securely distribute the key shares printed above

Por motivos de segurança essa é a única vez que você vai ver esses dados, tenha certeza que eles estão armazenados em um local seguro. A recomendação da própria Hashicorp é que você salve uma cópia dessas informações em um cofre físico.

Abra uma nova aba no seu navegador e acesse o IP da máquina na porta 8200 para acessar a UI do Vault.

Note que o status do servidor está marcado como Unsealed, o que é um indicador de sucesso do processo feito até então.

Aviso: Note também o ícone de cadeado cortado na barra de endereços do navegador indica que o site não possui proteção TLS. Isso é uma prática insegura, porém é um problema que não vamos resolver nesse artigo pois não faz parte do escopo. Não use nada em ambiente de produção sem TLS.

Caso queira acessar o painel basta utilizar o token de acesso root nesse primeiro momento.

Configurando provider do Vault

Para criar recursos do Vault através do Terraform iremos utilizar o provider oficial da Hashicorp que por sua vez irá realizar chamadas para a API HTTP do Vault.

É preciso configurar o provider com a rota para a API e também com um token para autenticação.

provider "vault" {  address = ""  token   = ""}

A API do Vault está disponível na porta 8200 da máquina EC2 que está funcionando, como endereço podemos usar o próprio IP da máquina usada para fazer o SSH.

provider "vault" {  address = "http://${data.aws_instance.server.public_ip}:8200"  token   = ""}

Como token basta usar o root token gerado durante a configuração incial, porém é um valor muito sensível para ficar direto no código então vamos criar uma variável em um arquivo na raiz variables.tf que vai receber o token.

variable "vault_token" {  type        = string  description = "Token for Vault provider authentication"}

Crie um arquivo para armazenar variáveis chamado vault.tfvars e ponha nele a variável vault_token passando o valor do root token. Não faça commit desse arquivo.

vault_token = "rt"

Na configuração agora basta incluir a variável:

provider "vault" {  address = "http://${data.aws_instance.server.public_ip}:8200"  token   = var.vault_token}

Rode o novamente o comando de init para que o Terraform faça download do provider. A partir de agora para realizar os comando de plan ou apply é necessário passar o arquivo vault.tfvars como valor do argumento -var-file:

terraform initterraform plan -var-file=vault.tfvarsterraform apply -var-file=vault.tfvars

Definindo as políticas

Agora que nosso servidor Vault já foi inicializado é hora de definir como vão funcionar as políticas de acesso às credenciais que serão armazenadas. Para isso precisamos levar algumas coisas em consideração:

1. As credenciais devem estar dividas por projeto;
2. Para cada projeto há 2 tipos de credencial:

• Serviços: Contas de site de um modo geral, SaaS, PaaS, etc.
• Infraestrutura: Credenciais utilizadas no desenvolvimento do projeto, senhas de banco, chaves de API, etc.

1. O membro de um projeto não pode ver as credenciais de outros que ele não participa.
2. Há 4 tipos de usuário com diferentes níveis de acesso:

• Administrador: Tem acesso total a tudo existente no Vault, não está ligado a nenhum projeto específico;
• Moderador: Tem controle total sobre as credenciais do(s) projeto(s) que faz parte;
• Membro: Tem permissão para visualizar todas as credencias do(s) projeto(s) que faz parte e também criar novas;
• Visitante: Tem permissão para apenas visualizar todas as credencias do(s) projeto(s) que faz parte;

A imagem abaixo ilustra estas definições.

Escrevendo as políticas

Agora que definimos como as políticas irão funcionar é hora de escrever cada uma.

As políticas dentro do Vault são escritas em .hcl (formato de arquivo próprio da Hashicorp) e são baseadas em paths (ou caminhos).

Além disso elas seguem uma linha de raciocínio de negação por padrão, ou seja, a falta de uma definição explícita de permissão indica que você não tem permissão.

Criação dinâmica de políticas

Apesar de possuir wildcards em sua sintaxe e ter suporte para substituição de algumas variáveis as políticas escritas em .hcl possuem suas limitações no que é possível ser definido em nível de acesso.

É necessário criar uma política de acesso para cada projeto porque o nome do projeto precisa ser usado para definir o caminho onde será dado a permissão. Por exemplo:

path "secrets/<nome-do-projeto>/*" {  capabilities = ["read", "list"]}

Além disso, é preciso criar uma política para cada nível de acesso já que cada uma vai definir permissões diferentes. Então para cada projeto precisaremos ter ao menos 3 políticas, dependendo do número de projetos isso pode se tornar difícil de gerenciar até mesmo via Terraform.

Tendo isso em mente, vamos criar um módulo para definir todas as configurações de política de acesso de um projeto. Crie uma pasta chamada project dentro de modules e crie os arquivos main.tf e variables.tf:

mkdir modules/projecttouch modules/project/main.tftouch modules/project/variables.tf

Defina um variável chamada name:

variable "name" {  type        = string  description = "Project's name"}

Agora dentro do main.tf do módulo vamos começar definindo uma política para o moderador. O moderador deverá ter acesso total às senhas dentro de secrets/<nome-do-projeto>, sua política então fica:

data "vault_policy_document" "maintainer" {  rule {    path         = "sys/mount"    capabilities = ["read"]    description  = "Allow read secrets engine"  }  rule {    path         = "${var.name}/data/*"    capabilities = ["create", "read", "update", "delete", "list", "sudo"]    description  = "Manage ${var.name} secrets"  }  rule {    path         = "${var.name}/metadata/*"    capabilities = ["list", "read", "delete"]    description  = "List ${var.name} secret keys and manage keys metadata"  }  rule {    path         = "${var.name}/delete/*"    capabilities = ["update"]    description  = "Allow deleting any key version on ${var.name} secret engine"  }  rule {    path         = "${var.name}/undelete/*"    capabilities = ["update"]    description  = "Allow deleting any key version on ${var.name} secret engine"  }  rule {    path         = "${var.name}/destroy/*"    capabilities = ["update"]    description  = "Allow destroying key versions on ${var.name} secret engine"  }}

OBS.: Note que aqui estamos utilizando um data source. Estamos fazendo isso pois as políticas do Vault precisam ser escritas diretamente em arquivos .hcl ou em strings que sigam o mesmo formato. Este data source permite a escrita de políticas Vault numa sintaxe mais amigável dentro do Terraform.

Agora vamos definir uma política para o membro do projeto. O membro deve ser capaz de visualizar todas as senhas presentes em secrets/<nome-do-projeto> e criar senhas novas dentro do mesmo path, a política resultante fica:

data "vault_policy_document" "member" {  rule {    path         = "sys/mount"    capabilities = ["read"]    description  = "Allow read secrets engine"  }  rule {    path         = "${var.name}/data/*"    capabilities = ["create", "read", "list"]    description  = "View and create ${var.name} secrets"  }  rule {    path         = "${var.name}/metadata/*"    capabilities = ["list"]    description  = "List ${var.name} secret keys"  }}

Por fim para a política de visitante, deve ter apenas permissão de visualização dentro de secrets/<nome-do-projeto>:

data "vault_policy_document" "visitor" {  rule {    path         = "sys/mount"    capabilities = ["read"]    description  = "Allow read secrets engine"  }  rule {    path         = "${var.name}/data/*"    capabilities = ["read", "list"]    description  = "View ${var.name} secrets"  }  rule {    path         = "${var.name}/metadata/*"    capabilities = ["list"]    description  = "List ${var.name} secret keys"  }}

Todos esses data sources representam os arquivos de política, para cada um deles é necessário criar a política em si:

resource "vault_policy" "maintainer" {  name   = "${var.name}_maintainer"  policy = data.vault_policy_document.maintainer.hcl}resource "vault_policy" "member" {  name   = "${var.name}_member"  policy = data.vault_policy_document.member.hcl}resource "vault_policy" "visitor" {  name   = "${var.name}_visitor"  policy = data.vault_policy_document.visitor.hcl}

OBS.: As políticas serão adicionadas diretamente aos usuários, porém também seria possível adicionar as políticas a grupos e então fazer o controle dos usuários através dos grupos.

Para finalizar o módulo, vamos habilitar um mecanismo de chave valor que terá como caminho o nome do projeto:

resource "vault_mount" "project" {  path        = var.name  type        = "kv-v2"  description = "This is ${var.name} KV Version 2 secret engine mount"}

Agora precisamos utilizar o módulo em main.tf. Primeiramente vamos armazenar o nome dos projetos em uma variável só para ficar mais fácil controlar todos. Para isso vamos usar um bloco do Terraform chamado locals.

Locals é um bloco de configuração que determina variáveis locais para serem usadas dentro do contexto de um módulo, no caso aqui vamos definir no módulo root (também conhecido como a raiz do projeto).

Defina uma variável chamada projects dentro de um bloco locals, passando como valor um set com o nome dos três projetos que iremos criar:

locals {  projects = toset([    "project-x",    "project-y",    "project-z",  ])}

Agora vamos usar o valor variável local projects para criar os projetos com suas respectivas políticas. Para isso é preciso utilizar o módulo project passando uma configuração de for_each .

O for_each no Terraform vai receber um array ou um map de strings e irá criar um recurso para cada item correspondente. Os valores presentes no array podem ser utilizados para configurar a infraestrutura.

No nosso caso vamos passar o valor de cada string para a variável name do módulo:

module "projects" {  for_each = local.projects  source   = "./modules/project"  name = each.key}

Use o comando de init para que o Terraform instale o módulo local e em seguida aplique a configuração

terraform initterraform apply -var-file=vault.tfvars

Política de administrador

O administrador é quem irá gerenciar o sistema e por conta disso sua política precisa ter permissão para fazer tudo no Vault, a vantagem disso é que fica fácil escrever a política de admin.

Para isso, adicione ao main.tf:

data "vault_policy_document" "admin" {  rule {    path         = "*"    description  = "Allow all on everything"    capabilities = ["create", "read", "update", "delete", "list", "sudo"]  }}resource "vault_policy" "admin" {  name   = "admin"  policy = data.vault_policy_document.admin.hcl}

Aplique as configurações para criar a política de admin no Vault

terraform apply -var-file=vault.tfvars

Criando os usuários

Criando módulo de usuário

O último recurso para ser gerenciado são os usuários, para isso vamos criar um último módulo só que dessa vez chamado user. Crie uma pasta de mesmo nome, um arquivo main.tf e um variables.tf:

mkdir modules/usertouch modules/user/main.tftouch modules/user/variables.tf

Existem 4 informações que são necessárias para podermos criar um usuário:

• username: Nome que identifica o usuário. Os caracteres aceitos aqui são letras, números, “-”, “_” e “.”
• password: Senha de acesso do usuário. Usada apenas para criação, a ideia é que os usuários troquem a senha após o primeiro acesso.
• accessor: ID do método de acesso. Ainda vamos configurar no main.tf um método de acesso baseado em username e senha.
• policies: Lista com todas as policies do usuario.

Crie essas variáveis no arquivo modules/user/varibles.tf:

variable "username" {  type        = string  description = "The username for the user. Accepted characters: alphanumeric plus '_', '-', '.' (underscore, hyphen and period); username cannot begin with hyphen or period."}variable "password" {  type        = string  description = "Password used only for creation. Advise users to change this on first access."  default     = "mudar123"}variable "accessor" {  type        = string  description = "Accessor of the mount (from auth method) to which the alias should belong to."}variable "policies" {  type        = list(string)  description = "List of policies names to attach to user"  default     = []}

É preciso passar o nome exato das polices para que as permissões sejam passadas para o usuário no momento do login.

Para evitar erro humano vamos voltar no bloco de locals do main.tf na raiz e criar uma variável com o número de todas as policies agrupas por projeto. Para fazer isso vamos utilizar a expressão for do Terraform.

locals {  projects = toset([    ...  ])  policies = {    for project in local.projects : project => {      maintainer = "${project}_maintainer"      member     = "${project}_member"      visitor    = "${project}_visitor"    }  }}

Dessa forma é possível garantir que o nome das policies utilizadas estão sendo criadas dentro de um padrão.

Vamos criar também o método de acesso para os usuários:

resource "vault_auth_backend" "userpass" {  type = "userpass"}

Vamos agora definir tudo que precisamos para o usuário em modules/user/main.tf. Primeiro vamos criar uma entity passando o username e o array de policies:

resource "vault_identity_entity" "user" {  name     = var.username  policies = var.policies}

Agora vamos criar um entity alias. Esse recurso é o que irá associar uma entity a um usuário que pertence a um método de acesso específico, neste caso username e senha.

resource "vault_identity_entity_alias" "user" {  name           = var.username  mount_accessor = var.accessor  canonical_id   = vault_identity_entity.user.id}

Por fim, vamos criar um usuário utilizando o recurso vault_generic_endpoint. Este recurso realiza um método PUT em qualquer rota da API do Vault, precisamos usa-lo porque não há um recurso específico para criar um usuário do tipo que estamos criando.

resource "vault_generic_endpoint" "user" {  depends_on           = [vault_identity_entity_alias.user]  path                 = "auth/userpass/users/${var.username}"  ignore_absent_fields = true  data_json = jsonencode({    "password" = var.password  })  lifecycle {    ignore_changes = [data_json]  }}

Note o bloco de lifecycle que esta dizendo para o terraform ignorar quaisquer mudanças no campo de data_json que é o corpo da requisição.

Ele está sendo utilizado para garantir que a variável de senha será usada apenas na criação, já que é o único parâmetro passado no corpo da requisição e qualquer mudança em seu valor é irrelevante, já que a responsabilidade de gerenciar a senha é do usuário e não do Terraform.

Com isso terminamos o módulo de usuário, que é o último que precisamos para configurar o Vault.

Criando usuários dinamicamente

De volta ao main.tf na raiz, vamos criar uma variável local para criar os usuários dinâmicamente assim como fizemos com as policies:

locals {  projects = toset([    ...  ])  policies = { 		...  }  users = {    "pessoa.b" = [      local.policies["project-x"]["maintainer"],      local.policies["project-y"]["maintainer"],    ]    "pessoa.c" = [      local.policies["project-y"]["member"],      local.policies["project-z"]["member"],    ]    "pessoa.d" = [      local.policies["project-z"]["visitor"],    ]  }}

Note que as policies pra cada usuário está de acordo com o exemplo definido. Agora basta usar o módulo criado:

module "users" {  for_each = local.users  source   = "./modules/user"  username = each.key  accessor = vault_auth_backend.userpass.accessor  policies = each.value}

Criando admins

Vamos criar uma variável local para criar usuários administradores dinâmicamente, porém, como todos os usuários vão possuir a mesma policy de admin, não é necessário utilizar maps como para os demais usuários, podemos usar apenas strings:

locals {  projects = toset([    ...  ])  policies = {    ...  }  users = {    ...  }  admins = toset(["pessoa.a"])}

Vamos criar os admins utilizando o mesmo módulo de usuário mas passando a policy de admin:

module "admins" {  for_each = local.admins  source   = "./modules/user"  username = each.key  accessor = vault_auth_backend.userpass.accessor  policies = ["admin"]}

Use o comando de init para que o Terraform instale os módulos novos e em seguida aplique a configuração

terraform initterraform apply -var-file=vault.tfvars

Validando configuração via UI

Variáveis de teste

Vamos criar alguns segredos seguindo o modelo proposto apenas para fins de validação, adicione isso ao main.tf:

resource "vault_generic_secret" "infraestructure_secrets" {  for_each = local.projects  path = "${each.key}/infraestrutcture/foo"  data_json = jsonencode({    "bar" = "baz"  })}resource "vault_generic_secret" "service_secrets" {  for_each = local.projects  path = "${each.key}/service/foo"  data_json = jsonencode({    "bar" = "baz"  })}

Use o comando de init para que o Terraform instale o módulo de segredo e em seguida aplique a configuração

terraform initterraform apply -var-file=vault.tfvars

Validando acesso de admin

Começando pela policy de admin, acesse o Vault no endereço http://<server_ip>:8200 onde serer_ip é o valor do output de mesmo nome.

Selecione como método de autenticação Username e faça login com as credenciais:

• Username: pessoa.a
• Senha: mudar123

Como esperado, conseguimos ver todos os projetos:

OBS.: O cubbyhole é um mecanismo de armazenar chave/valor, a diferença dele para os que criamos pra cada projeto é que o cubbyhole é de uso individual. Nenhum usuário pode ver o cubbyhole de outro usuário.

É possível ver também todos os segredos de teste criados:

Como admin é possível gerenciar também todas as configurações de acesso e também todas as políticas de acesso:

Clique no ícone de usuário no canto superior direito e em seguida em Sign out para sair e continuar as validações:

Validando acesso de moderador

Faça login com as credenciais:

• Username: pessoa.b
• Senha: mudar123

O usuário Pessoa B é moderador dos projetos X e Y, então ele só tem permissão para ver os dois:

Ele tem acesso total aos segredos dos dois projetos, então consegue não só ver os segredos como edita-los e criar novos:

Porém, como não é admin, não tem acesso as configurações de acesso:

Faça logout para continuar os testes:

Validando acesso de membro

Faça login com as credenciais:

• Username: pessoa.c
• Senha: mudar123

O usuário Pessoa C é membro dos projetos Y e Z, então ele só tem permissão para ver os dois:

Assim como o moderador ele tem permissão para criar segredos novos:

Porém quando se trata de segredos já existentes, ele consegue apenas ver e não editar:

Faça logout para continuar os testes:

Validando acesso de visitante

Faça login com as credenciais:

• Username: pessoa.d
• Senha: mudar123

O usuário Pessoa D é membro do projeto Z, então ele tem permissão para ver apenas ele:

Tem permissão para ver todos os segredos do projeto mas não para editar:

Apesar de conseguir acessar a tela de criar um segredo, não tem permissão pra finalizar a ação:

Faça logout e com isso acabaram as validações!

Considerações finais

O Vault é uma ferramenta que se usada corretamente irá com certeza aumentar a segurança dos seus projetos, e seu conjunto de funcionalidades abrange uma infinidade de casos de uso, mas a tarefa de configurar um servidor Vault pode ser complexa levando em conta tudo que pode e precisa ser criado de uma forma em que tudo se converse.

O Terraform é uma das ferramentas mais populares de Infrastructure as Code e esse é o tipo de situação em que ele se propõe a ser útil, tornando a configuração não só mais dinâmica mais também muito mais visível.

Caso queira ver como ficou o código depois disso tudo basta acessar este repositório. Obrigado a você que leu até aqui, deixe seu feedback e considere contratar a ZRP para o seu próximo projeto de software.

Agradecimentos

Conheça as pessoas que colaboraram na construção desse artigo:

• Ana Mai Arasaki (cover image)
• Renata Celli (fluxos e definição das políticas de acesso)
• Pedro Gryzinsky e Nikolas Serafini (revisores)