Vault架构

vault架构

Vault功能

• 密码的安全存储。Vault把密码以加密的形式存储起来，黑客拿到了密文，也很难解密。这个是最基本的需求。

• 动态密码。一般我们创建一个db，会创建一个新的role和db关联，为此要创建密码。这样的密码越复杂越好，反正不需要人来记。Vault能够帮你动态生成这些密码。更舒服的是，动态密码可以设置生存周期，过期后生成新密码，旧密码失效，进一步在密码泄漏出去后增加了安全性。

• on-the-fly加解密。既然都做了密码相关的事情，Vault顺带着又提供了加解密的API。类似于信用卡资料这种极度敏感的信息都可以使用其加密存储。而使用的时候可以在内存中直接完成解密，用完销毁，尽可能少地暴露敏感信息。

• Audit log。由于集中管理密码，Vault能记录任何访问密码的行为供日后审核。这是个非常重要的功能，否则密码遭到误用滥用或者被黑客使用，你都还蒙在谷里呢。

术语

Eng	说明
Storage Backend	存储后端 负责存储加密后的数据
Barrier	屏障，vault的安全区域的保障
Secret Backend	密码后端，如mysql每次生成mysql新用户
Audit Backend	审计后端，如日管理
Credential Backend	凭证后端，用于验证连接到vault的用户或应用程序
Client Token	客户端令牌
Secret	密文，秘密信息
Server	vault服务
Expiration Mgr	租期管理器，过期管理
Rollback Mgr	回滚管理器 ，用户不可见
Token Store	令牌存储
core	负责处理api请求请求,获取secret backend中密文返回，并加上lease ID ，用户可以调用api续租或销毁密文
policy store	策略存储
System backend	系统后端

架构

安全屏障Barrier内的组件都是安全的，除了Storage Backend和HTTP API之外,所有其他组件都在安全屏障Barrier内。

• Storage backend：顾名思义，存储后段。Vault允许你把密码存储在内存（dev），磁盘，aws等等地方。

• Barrier：这就像一道防火墙，将受信区域和非受信区域隔离开（HTTP API和storage就属于非受信区），过barrier必须先unseal，unseal的概念先放在一边。

• Policy：相当于access list，定义了密码在什么情况下允许什么样的操作。

• Secret backend：application获取密码的时候究竟是怎么获取，一般是把原密码直接返回，用户也可以通过policy设置，每次返回自动生成的密码；或者，使用aws的IAM。

• Authentication/Credential backend：用什么方式来认证application。最基本的是用户名和密码。Vault集成了一些第三方的auth server，比如github。

• Audit backend：处理audit log。audit log可以写到不同的provider里。

• Token：Vault提供给application的，用于访问整个系统的标识。application通过token获取权限，进而能够通过Vault赋予的权限进行读写操作。

Vault中的各种后端的配置都存储在存储库（Storage Backend），因为这些都是敏感数据。只有具有正确权限的用户才能够修改，也就是说他们不会处于屏障之外。由于他们存储在存储库中，对他们的任何更改都被ACL(Access Control List)控制，并被审计记录日志。

客户端首次连接到vault,需要进行身份验证。vault提供了可配置的凭证后端（Credential Backend），拥有灵活的身份验证机制。如对人类友好的用户名/密码认证方式，或使用第三方运营商的认证，如GitHub认证；应用程序可以使用公钥/私钥或令牌验证（token）。身份验证请求流经核心(core)和凭证后端（Credential Backend）,如果请求是有效,则返回其策略列表（Policies ）。

策略由ACL方式定义。例如,“root”策略是内置的,允许访问所有资源。您可以创建任意数量的策略以及路径的细粒度的权限控制。vault操作使用白名单模式,也就是说,除非通过策略显式授予权限，否则任何访问操作都是不允许的。一个用户可能有多个策略,是否可以操作由这些策略决定。策略由内部的策略库（policy store）存储和管理。策略库（policy store）是通过系统后端（System backend）操作的,其始终是安装在sys /下。

身份验证后由凭证后端（credential backend）提供了一组适用的政策,由token store为客户端生成一个新的令牌，并存储和管理起来。此标记发送给客户端,并用于后续请求使用。类似登录网站时用的cookie。客户端标记可能有一个与之相关的租赁凭证,是否有租赁凭证取决于凭证后端（credential backend ）配置。意味着客户端令牌可能需要定期更新,以免失效。

身份验证后,则使用令牌进行请求。令牌用于验证客户端和加载相关策略。策略用于对请求进行授权，然后将请求路由到指定的密文后端（Secret Backend）,请求的处理由后端的类型决定。如果后端返回密文,核心寄存器（core）会管理并附加一个租赁id（lease ID）。租赁id用做更新或销毁密文。如果客户允许租赁id到期,租期管理器（Expiration Mgr）自动销毁这个密文。

vault核心将请求和响应的日志委托给audit broker，将日志记录到审计后端。请求流程以外,核心保持在后台运行。租赁管理是比较重要的,因为它允许客户令牌到期或密文自动撤销。此外,vault使用回滚管理器基于日志记录处理某些失败的用例。这个操作是透明的和用户不可见的。

vault启动后，处于封闭状态，操作vault必须先解封，解封vault需要使用初始化时生成的多个密钥，vault初始化后需要使用加密钥匙（encryption key）访问数据，加密钥匙（encryption key）由主密钥（master key）提供保护；默认情况下,vault使用“ Shamir’s secret sharing algorithm ”算法把主密钥（master key）分割成5股，称为（key shares）,任何3股（key shares）可重建的主密钥（master key）；

注：
Shamir’s secret sharing algorithm : Shamir’s 秘密共享算法
Key Shares : 分割秘钥 任意三个可以构建Master Key
Master Key : 主密钥
Encryption key : 加密秘钥，用于数据的读写

Vault启动时，凑好master key后，会解密storage里的数据，解密出来的内容放在内存里。Vault自己的配置信息，policy等也都被加载。这时，application可以通过http API访问密码信息。

接下来就是application如何访问Vault的问题了：application必须以某种方式来通过authentication backend的验证。这个验证可以是密码（OMG，用密码保护密码，死循环了，不推荐），公钥私钥，通过MAC地址生成的密钥，通过TPM（Trust Platform Module）生成的密钥等等。这个环节是最薄弱的环节，因为通信的两端：application和Vault都要互相取信于对方。Vault作为服务端，是中心节点，可以通过证书来证明自己的身份，application是客户端，可能基数庞大，又是动态建立和消亡，所以麻烦一些。application的认证通过，会获得有时间限制的session token，以此来进行后续访问。

分割秘钥的数量和所需的最小阈值都可以指定。此功能可以被禁用,主密钥可直接访问未密封的vault服务，一旦库获取encryption key,就能够解密存储后端（storage backend）的数据,进入起封状态。启封后,vault加载所有的审计后端（Audit Backend ）、凭证后端（Credential Backend ）和密文后端（Secret Backend）

总结，Vault通过这些手段来尽可能保护application可能用到的密码：

• 任何重要信息，持久化时都以密文存在

• 拆解成N份的master key，只有K份凑齐，才能通过barrier unseal，密码的明文在内存中存在

• application需要认证才能访问

• application的权限由认证后的policy提供（这个policy是管理员配置的，application无权改动）

• 认证后通过session token在TLS信道里读取和写入密码

REF

vault-vault的架构
互联网项目里，如何以正确的姿势保存密码？