OpenBao: Gestão de Segredos Código Aberto após o Vault

Em Agosto de 2023, a HashiCorp anunciou a mudança do Vault (e outros produtos) da licença MPL para a Business Source License (BSL), restringindo o uso em ambientes de produção competitivos. A comunidade código aberto reagiu e a Linux Foundation criou o OpenBao — um fork sustentado, governado de forma independente, que mantém o espírito do Vault original sob uma licença verdadeiramente código aberto.

Este artigo explora o que é o OpenBao, como instalá-lo via Docker, configurar secrets engines, definir políticas de acesso e como se compara ao Vault original e a alternativas como SOPS+Age.

Neste artigo

• 1. Introdução
• 2. O que é o OpenBao
• 3. Instalação via Docker
• 4. Configurar Secrets Engine
• 5. Políticas e ACLs
• 6. Comparação OpenBao vs Vault vs SOPS
• 7. Boas Práticas

1. Introdução

A gestão de segredos é um pilar fundamental da segurança em infraestruturas modernas. Senhas, tokens de API, chaves de encriptação e certificados não podem viver em ficheiros de texto ou variáveis de ambiente — precisam de um sistema centralizado que garanta armazenamento encriptado, rotação automática e auditoria granular.

O HashiCorp Vault foi durante anos a referência código aberto nesta área. No entanto, em Agosto de 2023, a HashiCorp mudou a licença do Vault para a Business Source License (BSL) 1.1, que restringe o uso competitivo durante quatro anos antes de reverter para uma licença código aberto. Esta mudança levantou preocupações na comunidade sobre vendor lock-in e liberdade de uso.

A resposta da comunidade foi o OpenBao, anunciado em Dezembro de 2023 e adoptado pela Linux Foundation com governação independente. O OpenBao parte da última versão do Vault sob MPL (v1.14.x) e evolui como um projecto verdadeiramente código aberto sob a licença MPL 2.0.

2. O que é o OpenBao

O OpenBao é um sistema de gestão de segredos que proporciona armazenamento encriptado, controlo de acesso baseado em políticas, auditoria detalhada e rotação de credenciais. Funciona como um cofre centralizado onde aplicações e operadores podem armazenar, aceder e gerir segredos de forma segura.

As funcionalidades principais incluem:

• Secrets Engines: módulos plugáveis que armazenam, geram e encriptam segredos (KV, Transit, PKI, Database, Identity)
• Auth Methods: mecanismos de autenticação para clientes (Token, AppRole, Kubernetes, LDAP, OIDC)
• Políticas (ACLs): controlo granular de acesso a caminhos específicos do cofre
• Auditoria: registos detalhados de todas as operações realizadas
• Encriptação Transit: encriptação como serviço sem armazenar os dados
• Leasing e Renewal: segredos com TTL configurável e renovação automática

A arquitectura do OpenBao segue o mesmo modelo do Vault: um servidor (ou cluster em modo HA) que comunica com clientes via API REST. O armazenamento pode ser filesystem, Consul, Raft integrado ou vários backends suportados. O modo Raft Integrated Storage é o recomendado para produção, eliminando a dependência de Consul.

3. Instalação via Docker

A forma mais rápida de testar o OpenBao é através de Docker. O projecto mantém imagens oficiais no registro do GitHub Registry de Contentores. O exemplo abaixo cria um servidor de desenvolvimento em memória — ideal para testes, mas nunca para produção.

Criar um ficheiro docker-compose.yml:

version: "3.8"

services:
  openbao:
    image: openbao/openbao:latest
    container_name: openbao
    ports:
      - "8200:8200"
    environment:
      - BAO_ADDR=http://0.0.0.0:8200
    cap_add:
      - IPC_LOCK
    volumes:
      - openbao-data:/openbao/data
    command: server -dev

volumes:
  openbao-data:

Iniciar o serviço com:

docker compose up -d

# Verificar se o container está a correr
docker ps | grep openbao

# Verificar a API
curl -s http://localhost:8200/v1/sys/health | python3 -m json.tool

Em modo -dev, o OpenBao gera um token de root automaticamente e apresenta-o nos registos do contentor. Para o obter:

docker logs openbao 2>&1 | grep "Root Token"

Para um ambiente de produção, o modo dev não é adequado. É necessário configurar armazenamento persistente (Raft), TLS e inicializar o cofre formalmente. O ficheiro de configuração openbao.hcl para produção seria:

ui = true
disable_mlock = true

storage "raft" {
  path    = "/openbao/data"
  node_id = "node1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/openbao/tls/cert.pem"
  tls_key_file  = "/openbao/tls/key.pem"
}

api_addr = "https://0.0.0.0:8200"
cluster_addr = "https://0.0.0.0:8201"

Inicializar o cofre em modo produção:

# Inicializar com 5 key shares e threshold 3
bao operator init -key-shares=5 -key-threshold=3

# Unseal com as keys geradas
bao operator unseal 
bao operator unseal 
bao operator unseal 

# Autenticar com root token
bao login 

4. Configurar Secrets Engine

As secrets engines são o coração do OpenBao — cada uma gerencia um tipo específico de segredo. A mais comum é a Key-Value (KV), que armazena pares chave-valor arbitrários. Existem duas versões: KV v1 (sem versionamento) e KV v2 (com versionamento e soft-delete).

Activar a secrets engine KV v2 no caminho secret/:

# Ativar KV v2
bao secrets enable -path=secret -version=2 kv

# Verificar engines ativas
bao secrets list

# Escrever um segredo
bao kv put secret/myapp/database   username="dbuser"   password="S3cr3tP@ss"   host="db.internal.local"   port="5432"

# Ler um segredo
bao kv get secret/myapp/database

# Ler campo específico
bao kv get -field=password secret/myapp/database

O KV v2 suporta versionamento, permitindo ver histórico de alterações e reverter para versões anteriores:

# Listar versões de um segredo
bao kv metadata get secret/myapp/database

# Reverter para versão 1
bao kv rollback -version=1 secret/myapp/database

# Apagar versões específicas (soft delete)
bao kv delete -versions=2 secret/myapp/database

# Apagar definitivamente (destroy)
bao kv destroy -versions=2 secret/myapp/database

Além do KV, a secrets engine Transit merece destaque — fornece encriptação como serviço. As aplicações enviam dados em texto claro e recebem-nos encriptados, sem que o OpenBao armazene os dados:

# Ativar Transit
bao secrets enable transit

# Criar chave de encriptação
bao write -f transit/keys/myapp-key

# Encriptar dados (plaintext em base64)
echo -n "dados secretos" | base64 | bao write transit/encrypt/myapp-key plaintext=-

# Desencriptar
bao write transit/decrypt/myapp-key ciphertext="bao:v1:..."

5. Políticas e ACLs

As políticas do OpenBao definem quem pode aceder ao quê. Sem uma política que conceda acesso, nenhum token consegue ler ou escrever segredos. O princípio é deny by default — tudo é proibido excepto o que for explicitamente permitido.

Criar uma política para uma aplicação que só precisa de ler segredos do seu caminho:

# Criar ficheiro de política
cat > myapp-policy.hcl << 'EOF'
path "secret/data/myapp/*" {
  capabilities = ["read"]
}

path "secret/metadata/myapp/*" {
  capabilities = ["list", "read"]
}

path "transit/decrypt/myapp-key" {
  capabilities = ["update"]
}
EOF

# Aplicar a política
bao policy write myapp-readonly myapp-policy.hcl

# Verificar
bao policy read myapp-readonly

As capabilities disponíveis são:

• create — criar novos segredos (falha se já existir)
• read — ler segredos
• update — modificar segredos existentes
• delete — apagar segredos
• list — listar chaves num caminho
• sudo — operações privilegiadas (root-only)

Para que uma aplicação use esta política, é necessário criar um token via AppRole — o método de autenticação mais comum para serviços:

# Ativar AppRole
bao auth enable approle

# Criar role com a política
bao write auth/approle/role/myapp   token_policies="myapp-readonly"   token_ttl=1h   token_max_ttl=4h   secret_id_ttl=0   secret_id_num_uses=0

# Obter role_id e secret_id
bao read auth/approle/role/myapp/role-id
bao write -f auth/approle/role/myapp/secret-id

# Autenticar via AppRole
bao write auth/approle/login   role_id="xxxx-xxxx-xxxx"   secret_id="yyyy-yyyy-yyyy"

6. Comparação OpenBao vs Vault vs SOPS

Existem várias abordagens à gestão de segredos. O OpenBao compete directamente com o HashiCorp Vault (sob BSL) e indirecção com soluções mais leves como SOPS+Age. A tabela seguinte compara as três abordagens:

Quando escolher OpenBao: quando se precisa de um cofre centralizado com segredos dinâmicos, leasing, auditoria e controlo de acesso granular, sem vendor lock-in. É a escolha natural para quem já usa Vault e quer migrar para uma alternativa código aberto.

Quando escolher SOPS+Age: quando os segredos vivem em ficheiros YAML/JSON versionados em Git (ex: manifests Kubernetes, configs Terraform) e não se precisa de um servidor sempre disponível. SOPS encripta apenas os valores, deixando as chaves em texto claro — ideal para revisão de code review. Com age como backend de encriptação, não há dependência de PGP.

7. Boas Práticas

Implementar gestão de segredos vai muito além de instalar o software. As práticas operacionais determinam o nível real de segurança. Seguem-se as recomendações mais importantes:

Princípio do menor privilégio

Cada aplicação deve ter uma política que concede apenas o mínimo necessário. Se uma app só precisa de ler um caminho, a política não deve incluir update ou delete. Rever políticas regularmente com:

# Listar todas as políticas
bao policy list

# Auditar uma política específica
bao policy read myapp-readonly

Rotação de segredos

Segredos estáticos devem ser rotados periodicamente. O OpenBao suporta rotação automática através do database secrets engine, que gera credenciais temporáis com TTL configurável:

# Ativar database secrets engine
bao secrets enable database

# Configurar conexão PostgreSQL
bao write database/config/myapp-pg   plugin_name=postgresql-database-plugin   connection_url="postgresql://{{username}}:{{password}}@db:5432/myapp?sslmode=disable"   allowed_roles="myapp-role"   username="admin"   password="admin-password"

# Criar role com credenciais temporárias
bao write database/roles/myapp-role   db_name=myapp-pg   creation_statements="CREATE ROLE "{{name}}" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';"   default_ttl=1h   max_ttl=24h

Auditoria e monitorização

Activar logs de auditoria é obrigatório em produção. O OpenBao regista todas as operações, mas os valores dos segredos são hashados (não aparece o valor em claro):

# Ativar log de auditoria para ficheiro
bao audit enable file file_path=/openbao/audit/audit.log

# Ativar log de auditoria para syslog
bao audit enable syslog tag="openbao"

# Verificar dispositivos de auditoria ativos
bao audit list

Cópia de segurança e recuperação

O snapshot do Raft integrated storage permite recuperar o estado completo do cofre:

# Criar snapshot
bao operator raft snapshot save backup.snap

# Restaurar snapshot
bao operator raft snapshot restore backup.snap

O OpenBao representa a continuidade do espírito código aberto que fez do Vault a ferramenta de referência. Com o apoio da Linux Foundation, governação independente e compatibilidade de API, é a escolha natural para equipas que precisam de gestão de segredos robusta sem comprometer a liberdade tecnológica. Para casos de uso mais simples — como encriptar configs em Git — SOPS+Age permanece uma alternativa válida e complementar.