1. 概述
该部分会通过vault的功能、架构和安全特性去介绍vault的内部结构和技术细节。
注意：如果你只是为了使用Vault或对它的内部结构不感兴趣，那可跳过该部分。如果要对Vault进行管理，建议阅读一下该部分。
2. 架构
vault是一个由许多部分组成的复杂系统。该页面帮助用户和开发者通过概念模型去了解它的运作方式。
高级主题：该页面会介绍vault的技术细节。就算你不理解这些知识，也能高效地使用vault。该部分文档只是通过一种无需阅读源代码的方式去帮助那些想了解该知识点的同学而建立。如果你需要对vault进行管理，因vault在环境中的重要性我们建议你去学习一下该部分知识。
2.1 词汇表
在对架构进行介绍之前，我们会提供一份词汇表去帮助你们理清将要被介绍的内容：
- 存储后端（Storage Backend） - 存储后端能够持久化地存储加密数据。后端不会被vault信任，只是为了提供持久化保存的功能。启动vault服务的时候该存储后端会被加载。
- 屏障（Barrier）- 这个屏障就相当于vault的保护壳。流经vault和存储后端的所有数据都会经过这个屏障。它会确保只有加密的数据会被写出，并在传输的过程中对数据进行验证和解密。就像银行金库一样，要取出里面的东西先得解锁。
- 密钥引擎（Secrets Engine）- 密钥引擎负责管理密钥。像“kv”这类简单密钥引擎在查询的时候会简单地返回相同的密钥。部分密钥引擎支持通过策略去在你每次查询的时候动态生成密钥。这能让vault对每一个独立的密约都能进行细粒度的撤权与策略的更新。例如：可配置一个“web”策略到MySQL密钥引擎中。当“web”的密钥被读取，一对拥有有限权限的新的MySQL用户名/密码将会为web服务器而生成。
- 审计设备（Audit Device）- 审计设备负责管理审计记录信息。流入和流出vault的数据都会经过它。它提供了一种简单的方式去让vault与多个审计系统进行集成。
- 认证方法（Auth Method）- 它用来对正在连接到vault的用户或应用进行认证。一旦认证成功，它会返回将要被使用的应用策略列表信息。vault接受经过身份验证的用户并返回可用于将来请求的客户端令牌。例如：
userpass认证方法会使用用户名和密码去对用户进行认证。而github认证方法则通过GitHub去进行认证。 - 客户端令牌（Client Token）- 客户端令牌（又叫“Vault令牌”）相当于网站里面的一个会话cookie。一旦一个用户认证之后，Vault会返回一个将来请求需要使用的客户端令牌。Vault会通过该令牌去识别身份并执行可用的ACL（访问控制列表）策略。该token放在HTTP的头部中。
- 密钥（Secret）- 密钥是Vault能返回包含机密或加密数据的关键因素。但并不是Vault返回的所有数据都是加密的，像系统配置，状态信息或者策略是不会被加密的。密钥总是有一个租期。这意味着一个密钥不能无限期地使用。Vault会在租期结束的时候撤回对应的密钥，管理人员也可以人工干预密钥的租期结束时间。这份Vault与客户端之间的合同是至关重要的，因为它允许在没有人工干预的情况下更改密钥和策略。
- 服务（Server）- Vault需要一台可长时间运行的服务器。该Vault服务器提供一个能提供客户端与之进行通信、管理全部密钥引擎的相互通信、ACL执行、密钥租期收回功能的API。使基于服务器的体系结构将客户端与安全密钥和策略分离，实现集中审计日志记录并简化操作员的管理。
2.2 体系结构
从体系结构看，Vault看起来像下面这张图：
我们来对这张图片进行分解。安全屏障内部或外部的组件明显分离。只有存储后端和HTTP API在外面，其他的全部组件都在屏障的里面。
存储后端是不被信任的，只是用作将加密的数据进行持久化处理。当Vault服务启动时，必须要提供一个存储后端给Vault，这样之前保存的数据才能在重启后仍能访问到。同样地，HTTP API也要提供这样客户端才能与它进行交流。
一旦启动完毕，Vault时处理一个密封的状态。要对它进行开封才能进行其他操作。可通过提供开封钥匙来完成开封。当Vault初始化完毕后，它会生成一把能用来保护数据的加密钥匙。该钥匙会被一把主钥匙保护着。默认情况下，Vault会使用一种被称为Shamir的秘密共享算法去将主钥匙分成5把小钥匙，要重建主钥匙必须要使用其中的3把去完成。
钥匙拆分的数量和最小组成主钥匙数量都可进行自定义。可通过禁用来不使用Shamir的算法进行处理，这样就可直接使用主钥匙来进行开封。一旦Vault获取到加密钥匙，就能够对存储在后端存储的数据进行解密，然后会进入到开封状态。一旦开封后，Vault会读取全部的审计设备、加密方法和密钥引擎。
这些审计设备、加密方法和密钥引擎的配置必须要存储到Vault中因为它们是极为重要的。只有携带正确权限的用户才能去修改它们，这意味着它们不能被分配到屏障之外。通过Vault去存储它们，使得对它们的任何更改都受到ACL系统的保护并被审计日志进行记录。
Vault被开封之后，HTTP API到内核的数据可被正确请求。内核用来管理流经系统的请求，执行ACL并确保审计记录的完成。
当一个客户端首次连接到Vault，它需要进行认证。Vault提供配置好的认证方法，为所使用的身份验证机制提供灵活性。操作者可使用人性化的认证机制，如用户名/密码或GitHub认证方式。与此同时，应用也可使用公钥/私钥或令牌去进行认证。一个流经内核的认证请求，会进入认证方法，该方法会判断该请求是否合法并返回与之相关的策略列表。
策略只是一个已命名好的ACL规则。例如，“root”策略是内建的，它允许访问全部资源。你可以为每一个路径创建指定名字的细粒度控制策略。Vault仅以白名单模式运行，这表明除策略允许外的操作都不允许执行。因为一个用户可拥有多个策略与之关联，那么只要策略中的其中一个允许执行那么该操作就是可行的。策略被一个内部策略存储容器保存和管理着。这个内部存储容器会通过系统后端进行操作，它总是被挂载在sys/目录下。
一旦认证完成并且一个认证方法提供了一个适用的策略集合，一个新的客户端令牌会生成，然后它会受令牌存储管理。该客户端令牌会发回给客户端，然后会被用作未来的请求。这就类似于一个用户登陆网站之后所收到的cookie。该客户端令牌可以根据认证方法配置过期时间。这意味着你需要去周期性地更新它避免令牌失活。
一旦认证过后，生成的请求会提供客户端令牌。这个令牌会用来验证客户端已被授权和用来读取相关的策略。这些策略会用来授权客户端请求。授权完毕后，请求会被路由到密钥引擎，这些请求会根据密钥引擎的类型去进行相应处理。如果密钥引擎返回了一个密钥，该内核会用使用一个租约管理器去注册这个密钥，并分配给密钥一个租约ID。该租约ID可被客户端用来刷新和收回密钥。如果客户端允许租约过期，那么租约管理器会自动收回该密钥。
内核会把请求和响应的日志传输到审计中间件，该中间件会将请求传递给所有已配置的审计设备。除了请求流之外，Vault内核也会进行其他的一些后台活动。租约管理是关键点，因为它允许使得过期的客户端令牌或密钥能被自动回收。此外，Vault通过使用回滚管理器进行预写日志记录来处理某些部分故障情况。这会在内核中透明地管理，用户对此是不可见的。
2.3 深入了解
这是对Vault体系结构的简要概述。接下来会对每个子系统进行更为详细的介绍。
有关其他详细信息，请查阅代码，在IRC中询问或联系邮件列表。
待续。。。