“Architecture

Vault é um sistema complexo que tem muitas peças diferentes. Para ajudar tanto usuários quanto desenvolvedores do Vault a construir um modelo mental de como ele funciona, esta página documenta a arquitetura do sistema.

Antes de descrever a arquitetura, fornecemos um glossário de termos para ajudar a esclarecer o que está sendo discutido:

• Storage Backend – Um storage backend é responsável pelo armazenamento durável de dados criptografados. Backends não são confiáveis pela Vault e são esperados apenas pela durabilidade do toprovide. O backend de armazenamento é configurado ao iniciar o Vaultserver.

• Barrier – A barreira é de aço criptográfico e concreto ao redor do Vault. Todos os dados que fluem entre o Vaultserver e o backend de armazenamento passam através da barreira. A barreira garante que apenas os dados criptografados sejam escritos e que os dados sejam verificados e descriptografados no caminho de entrada. Assim como um bankvault, a barreira deve ser “sem selo” antes que qualquer coisa dentro possa ser acessada.

• Secrets Engine – Um motor de segredos é responsável pela gestão de segredos.Motores de segredos simples como o motor de segredos “kv” simplesmente retornam o mesmo segredo quando consultados. Alguns motores de segredos suportam a utilização de políticas que geram um segredo de cada vez que são consultados. Isto permite a utilização de segredos únicos, o que permite à Vault fazer revogações e actualizações de políticas com granulação fina. Como exemplo, um motor de segredos MySQL pode ser configurado com uma política “web”. Quando o segredo “web” é lido, um novo par de usuários/senhas MySQL será gerado com um conjunto limitado de privilégios para o servidor web.

• Audit Device – Um dispositivo de auditoria é responsável por gerenciar os logs de auditoria. Cada pedido ao Vault e resposta do Vault passa pelos dispositivos configuredaudit. Isto fornece uma maneira simples de integrar o Vault com destinos de registro de auditoria múltipla de diferentes tipos.

• Auth Method – Um método auth é usado para autenticar usuários ou aplicativos que estão conectados ao Vault. Uma vez autenticado, o método auth retorna a lista de políticas aplicáveis que devem ser aplicadas. Vault pega o usuário anuthenticated e retorna um token de cliente que pode ser usado para pedidos futuros. Como exemplo, o método userpass auth usa um nome de utilizador e uma palavra-passe para autenticar o utilizador. Alternativamente, o método github auth permite que usuários se autentiquem via GitHub.

• Client Token – Um token cliente (aka “Vault Token”) é conceitualmente semelhante a um cookie de sessão em um web site. Assim que um usuário se autentica, o Vaultret devolve um token cliente que é usado para pedidos futuros. O token é utilizado pela Vault para verificar a identidade do cliente e para fazer cumprir as políticas ACL aplicáveis. Este token é passado através de cabeçalhos HTTP.

• Secret – Um segredo é o termo para qualquer coisa devolvida pelo Vault que contenha material confidencial ou criptográfico. Nem tudo retornado pelo Vault é um segredo, por exemplo, configuração do sistema, informações de status, orpolicies não são consideradas segredos. Os segredos têm sempre um arrendamento associado, o que significa que os clientes não podem assumir que o conteúdo secreto pode ser utilizado de forma indefinida. Vault irá revogar um segredo no final do contrato de locação, e um operador pode intervir para revogar o segredo antes que o contrato de locação termine. Este contrato entre o Vault e seus clientes é crítico, pois permite mudanças nas chaves e políticas sem intervenção manual.

• Servidor – O Vault depende de uma instância de longa duração que opera como servidor. O servidor Vault fornece uma API com a qual os clientes interagem e gerenciam a interação entre todos os mecanismos secretos, aplicação de ACL e revogação de locação secreta. Ter uma arquitetura baseada em servidor desacopla clientes das chaves de segurança e políticas, permite o registro centralizado de auditoria e simplifica a administração para os operadores.

“High-Level Overview

Uma visão geral de alto nível do Vault se parece com isto:

Vamos começar a quebrar esta imagem. Há uma separação clara dos componentes que estão dentro ou fora da barreira de segurança. Somente o storagebackend e a API HTTP estão fora, todos os outros componentes estão dentro da barreira.

O backend de armazenamento não é confiável e é usado para armazenar dados criptografados de forma durável. A API HTTP deve igualmente ser iniciada pelo servidor Vault no início para que os clientes possam interagir com ela.

Após o início, o Vault está em um estado selado. Antes que qualquer operação possa ser beperformada no Vault, ela deve ser des selada. Isto é feito fornecendo as des-vedações. Quando o Vault é inicializado, ele gera uma chave de criptografia que é usada para proteger todos os dados. Essa chave é protegida por uma chave mestra. Por padrão,Vault usa uma técnica conhecida como Shamir’s secret sharingalgorithm para dividir a chave master em 5 ações, qualquer 3 das quais são necessárias para reconstruir a chave master.

O número de ações e o limite mínimo necessário podem ser especificados.A técnica de Shamir pode ser desabilitada, e a chave master usada diretamente para a desvinculação. Uma vez que o Vault recupera a chave de criptografia, ele é capaz de decifrar os dados no backend de armazenamento, e entra no estado não selado. Uma vez não selado, o Vault carrega todos os dispositivos de auditoria configurados, métodos auth e motores secretos.

A configuração desses dispositivos de auditoria, métodos auth e motores secretos deve ser armazenada no Vault, uma vez que eles são sensíveis à segurança. Somente usuários com as permissões corretas devem ser capazes de modificá-las, o que significa que não podem ser especificadas fora da barreira. Ao armazená-las no Vault, quaisquer alterações nelas são protegidas pelo sistema ACL e rastreadas pelos logs de auditoria.

Após o Vault ser desmarcado, as solicitações podem ser processadas da API HTTP para oCore. O núcleo é usado para gerenciar o fluxo de requisições através do sistema, aplicar ACLs e garantir que o registro de auditoria seja feito.

Quando um cliente se conecta ao Vault pela primeira vez, ele precisa autenticar. O Vault fornece métodos auth configuráveis, proporcionando flexibilidade no mecanismo de autenticação utilizado. Mecanismos amigáveis como nome de usuário/senha ou GitHub podem ser usados para operadores, enquanto aplicações podem usar chaves públicas/privadas ou tokens para autenticar. Uma solicitação de autenticação flui através do núcleo e para um authmethod, que determina se a solicitação é válida e retorna uma lista de políticas associadas.

Políticas são apenas uma regra chamada ACL. Por exemplo, a política “root” é incorporada e permite o acesso a todos os recursos. Você pode criar qualquer número de políticas nomeadas com controle fino sobre os caminhos. O Vault opera exclusivamente em um modo whitelistmode, o que significa que, a menos que o acesso seja explicitamente concedido através de uma política, a ação não é permitida. Como um usuário pode ter várias políticas associadas, uma ação é permitida se alguma política o permitir. As políticas são armazenadas e gerenciadas por uma loja de políticas internas. Este armazenamento interno é manipulado através do backend do sistema, que é sempre montado em sys/.

Once autenticação ocorre e um método auth fornece um conjunto de políticas aplicáveis, um novo token cliente é gerado e gerenciado pela loja de token. Este token cliente é enviado de volta para o cliente, e é usado para fazer pedidos futuros. Isto é semelhante a um cookie enviado por um site depois que um usuário faz o login. O clienttoken pode ter um contrato de arrendamento associado a ele, dependendo do método de auto-configuração. Isto significa que o token do cliente pode precisar ser renovado periodicamente para evitar a invalidação.

Até autenticado, as solicitações são feitas fornecendo o token do cliente. O token é utilizado para verificar se o cliente está autorizado e para carregar as políticas relevantes. As políticas são usadas para autorizar a solicitação do cliente. A solicitação é então roteada para o mecanismo de segredos, que é processado dependendo do seu tipo. Se o motor de segredos retorna um segredo, o núcleo o registra com o gerenciador de expiração e vincula um ID de locação. O ID do contrato de arrendamento é utilizado pelos clientes para renovar ou revogar o seu segredo. Se um cliente permite que a locação expire, o gerente de expiração revoga automaticamente o segredo.

O núcleo trata do registro de solicitações e respostas ao corretor de auditoria, o que ventila a solicitação a todos os dispositivos de auditoria configurados. Fora do fluxo de requisições, o núcleo executa certas atividades de fundo. O gerenciamento do leasing é crítico, pois permite que fichas ou segredos de clientes expirados sejam revogados automaticamente. Além disso, o Vault lida com certos casos de falhas parciais, utilizando o registro de write ahead com um gerenciador de rollback. Isto é gerenciado de forma transparente dentro do núcleo e não é visível pelo usuário.

“Getting in Depth

Esta tem sido uma breve visão geral de alto nível da arquitetura do Vault. Há mais detalhes disponíveis para cada um dos subsistemas.

Para outros detalhes, consulte o código, pergunte no IRC ou chegue até a lista de e-mails.