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
