hashicorp/vaultUma ferramenta para gerenciamento de segredos, criptografia como serviço e gerenciamento de acesso privilegiado
Atenção: Levamos a segurança do Vault e a confiança dos nossos usuários muito a sério. Se você acredita ter encontrado um problema de segurança no Vault, por favor, divulgue-o de forma responsável entrando em contato conosco em [email protected].
O Vault é uma ferramenta para acessar segredos com segurança. Um segredo é qualquer coisa para a qual você deseja controlar rigidamente o acesso, como chaves de API, senhas, certificados e muito mais. O Vault fornece uma interface unificada para qualquer segredo, enquanto oferece controle de acesso rigoroso e registra um log de auditoria detalhado.
Um sistema moderno requer acesso a uma infinidade de segredos: credenciais de banco de dados, chaves de API para serviços externos, credenciais para comunicação em arquitetura orientada a serviços, etc. Entender quem está acessando quais segredos já é muito difícil e específico da plataforma. Adicionar rotação de chaves, armazenamento seguro e logs de auditoria detalhados é quase impossível sem uma solução personalizada. É aqui que o Vault entra em cena.
As principais funcionalidades do Vault são:
Armazenamento Seguro de Segredos: O Vault pode armazenar pares arbitrários de chave/valor. O Vault criptografa os dados antes de gravá-los no armazenamento persistente, portanto, obter acesso ao armazenamento bruto não é suficiente para acessar seus segredos. O Vault pode gravar em disco, Consul e muito mais.
Segredos Dinâmicos: O Vault pode gerar segredos sob demanda para alguns sistemas, como AWS ou bancos de dados SQL. Por exemplo, quando uma aplicação precisa acessar um bucket S3, ela solicita credenciais ao Vault, e o Vault gerará um par de chaves AWS com permissões válidas sob demanda. Após criar esses segredos dinâmicos, o Vault também os revogará automaticamente quando o prazo de locação expirar.
Criptografia de Dados: O Vault pode criptografar e descriptografar dados sem armazená-los. Isso permite que as equipes de segurança definam parâmetros de criptografia e que os desenvolvedores armazenem dados criptografados em um local, como um banco de dados SQL, sem precisar projetar seus próprios métodos de criptografia.
Locação e Renovação: O Vault associa uma locação a cada segredo. No final da locação, o Vault revoga automaticamente o segredo. Os clientes podem renovar as locações por meio de APIs de renovação integradas.
Revogação: O Vault possui suporte integrado para revogação de segredos. O Vault pode revogar não apenas segredos individuais, mas uma árvore de segredos, por exemplo, todos os segredos lidos por um usuário específico, ou todos os segredos de um tipo específico. A revogação auxilia na rotação de chaves e também no bloqueio de sistemas em caso de invasão.
A documentação está disponível no site do Vault.
Se você é novo no Vault e deseja começar com automação de segurança, confira nossos guias de primeiros passos na plataforma de aprendizado da HashiCorp. Há também guias adicionais para continuar seu aprendizado.
Para exemplos de como interagir com o Vault a partir de sua aplicação em diferentes linguagens de programação, veja o repositório vault-examples. Também está disponível uma aplicação de exemplo pronta para uso.
Mostre seu conhecimento sobre o Vault ao passar em um exame de certificação. Visite a página de certificação para obter informações sobre os exames e encontre materiais de estudo na plataforma de aprendizado da HashiCorp.
Se você deseja trabalhar no próprio Vault ou em qualquer um de seus sistemas embutidos, primeiro precisará ter o Go instalado em sua máquina.
Para desenvolvimento local, primeiro certifique-se de que o Go está instalado corretamente, incluindo a configuração de um GOPATH e, em seguida, defina a variável GOBIN como $GOPATH/bin. Certifique-se de que $GOPATH/bin esteja no seu PATH, pois algumas distribuições incluem a versão antiga das ferramentas de build.
Em seguida, clone este repositório. O Vault usa Go Modules, portanto, é recomendável clonar o repositório fora do GOPATH. Você pode então baixar as ferramentas de build necessárias inicializando seu ambiente:
$ make bootstrap
...
Para compilar uma versão de desenvolvimento do Vault, execute make ou make dev. Isso colocará o binário do Vault nas pastas bin e $GOPATH/bin:
$ make dev
...
$ bin/vault
...
Para compilar uma versão de desenvolvimento do Vault com a interface do usuário, execute make static-dist dev-ui. Isso colocará o binário do Vault nas pastas bin e $GOPATH/bin:
$ make static-dist dev-ui
...
$ bin/vault
...
Para executar os testes, digite make test. Observação: isso requer que o Docker esteja instalado. Se isso sair com status de saída 0, está tudo funcionando!
$ make test
...
Se você está desenvolvendo um pacote específico, pode executar testes apenas para esse pacote especificando a variável TEST. Por exemplo, abaixo, apenas os testes do pacote vault serão executados.
$ make test TEST=./vault
...
Se você encontrar um erro como could not read Username for 'https://github.com', pode ser necessário ajustar sua configuração do git da seguinte forma:
$ git config --global --add url."[email protected]:".insteadOf "https://github.com/"
Este repositório publica duas bibliotecas que podem ser importadas por outros projetos:
github.com/hashicorp/vault/api e github.com/hashicorp/vault/sdk.
Observe que este repositório também contém o Vault (o produto), e como a maioria dos projetos Go, o Vault usa Go modules para gerenciar suas dependências. O mecanismo para fazer isso é o arquivo go.mod. Por acaso, a presença desse arquivo também torna teoricamente possível importar o Vault como dependência em outros projetos. Alguns outros projetos têm a prática de fazer isso para aproveitar as ferramentas de teste que foram desenvolvidas para testar o próprio Vault. Isso não é, e nunca foi, uma forma suportada de usar o projeto Vault. Provavelmente não corrigiremos bugs relacionados à falha ao importar github.com/hashicorp/vault em seu projeto.
Veja também a seção "Testes baseados em Docker" abaixo.
O Vault possui testes de aceitação abrangentes cobrindo a maioria das funcionalidades dos métodos de segredo e autenticação.
Se você estiver trabalhando em uma funcionalidade de um método de segredo ou autenticação e quiser verificar se está funcionando (e também não quebrou nada), recomendamos executar os testes de aceitação.
Aviso: Os testes de aceitação criam/destroem/modificam recursos reais, o que pode incorrer em custos reais em alguns casos. Na presença de um bug, é tecnicamente possível que backends quebrados deixem dados órfãos. Portanto, execute os testes de aceitação por sua própria conta e risco. No mínimo, recomendamos executá-los em uma conta privada separada para o backend que você está testando.
Para executar os testes de aceitação, invoque make testacc:
$ make testacc TEST=./builtin/logical/consul
...
A variável TEST é obrigatória, e você deve especificar a pasta onde o backend está. A variável TESTARGS é recomendada para filtrar um recurso específico a ser testado, pois testar todos de uma vez pode levar muito tempo.
Os testes de aceitação geralmente exigem que outras variáveis de ambiente sejam definidas para coisas como chaves de acesso. O teste em si deve gerar um erro antecipado e informar o que configurar, por isso não está documentado aqui.
Para mais informações sobre os recursos do Vault Enterprise, visite o site do Vault Enterprise.
Criamos um novo mecanismo de teste experimental inspirado no NewTestCluster. Um exemplo de como usá-lo:
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault", // or "hashicorp/vault-enterprise"
ImageTag: "latest",
}
cluster := docker.NewTestDockerCluster(t, opts)
client := cluster.Nodes()[0].APIClient()
_, err := client.Logical().Read("sys/storage/raft/configuration")
if err != nil {
t.Fatal(err)
}
}
Ou para Enterprise:
import (
"testing"
"github.com/hashicorp/vault/sdk/helper/testcluster/docker"
)
func Test_Something_With_Docker(t *testing.T) {
opts := &docker.DockerClusterOptions{
ImageRepo: "hashicorp/vault-enterprise",
ImageTag: "latest",
VaultLicense: licenseString, // not a path, the actual license bytes
}
cluster := docker.NewTestDockerCluster(t, opts)
}
Aqui está um exemplo mais realista de como usamos na prática. DefaultOptions usa hashicorp/vault:latest como repositório e tag, mas também verifica a variável de ambiente VAULT_BINARY. Se preenchida, ele copiará o arquivo local referenciado por VAULT_BINARY para o container. Isso é útil ao testar alterações locais.
Em vez de definir a opção VaultLicense, você pode definir a variável de ambiente VAULT_LICENSE_CI, que é melhor do que commitar uma licença no controle de versão.
Opcionalmente, você pode definir COMMIT_SHA, que será anexado ao nome da imagem que construímos como uma conveniência de depuração.
func Test_Custom_Build_With_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
cluster := docker.NewTestDockerCluster(t, opts)
}
Existem vários helpers no pacote github.com/hashicorp/vault/sdk/helper/testcluster, por exemplo, os testes abaixo criarão um par de clusters de 3 nós e os vincularão usando replicação PR ou DR respectivamente, e falharão se o estado de replicação não se tornar saudável antes do contexto passado expirar.
Novamente, como escrito, esses dependem de ter um binário do Vault Enterprise localmente e a variável de ambiente VAULT_BINARY definida apontando para ele, além de ter VAULT_LICENSE_CI definida.
func TestStandardPerfReplication_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
r, err := docker.NewReplicationSetDocker(t, opts)
if err != nil {
t.Fatal(err)
}
defer r.Cleanup()
ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
defer cancel()
err = r.StandardPerfReplication(ctx)
if err != nil {
t.Fatal(err)
}
}
func TestStandardDRReplication_Docker(t *testing.T) {
opts := docker.DefaultOptions(t)
r, err := docker.NewReplicationSetDocker(t, opts)
if err != nil {
t.Fatal(err)
}
defer r.Cleanup()
ctx, cancel := context.WithTimeout(context.Background(), time.Minute)
defer cancel()
err = r.StandardDRReplication(ctx)
if err != nil {
t.Fatal(err)
}
}
Finalmente, aqui está um exemplo de execução de um teste docker OSS existente com um binário personalizado:
$ GOOS=linux make dev
$ VAULT_BINARY=$(pwd)/bin/vault go test -run 'TestRaft_Configuration_Docker' ./vault/external_tests/raft/raft_binary
ok github.com/hashicorp/vault/vault/external_tests/raft/raft_binary 20.960s