Vault系统中的主要零件。官网给出的架构图如下：
Vault系统中把机密信息统称为Secret，不同类型的Secret被认为type不同，需要使用不同的Secret Engine来操作。最常见的Secret Engine有ssh，key-value，database等，此外还有如aws，azure，alicloud，gcp等云平台。到这里已经可以看出Vault并不只是一个类似安全数据库的纯粹储存设施，Vault的每一种Secret Engine都会根据其特点和限制来制定安全地生成secret。简单理解就是，当用户需要一个可以用来access某种Secret时，它会向Vault去索取，然后Vault根据Secret的type调用相应的engine来生成一个并返回给用户，这也是一个非常general的流程。
细心的用户可能注意到了，上文并没有提到Secret Engine在哪里储存Secret，因为engine被认为是一个用于计算的零件而非储存，就像汽车的引擎，负责烧油提供动力，但并不则储存燃料。Vault中将储存机制和其位置称为Storage Backend，支持本地储存（in-memory, local filesystem），云平台原生储存（s3, azure），也可使用自运维的存储实例（etcd, mysql, zookeeper）。这是一种很常见的计算-储存间的解耦，十分灵活，应该也支持让用户自定义。
那么Vault支持这么多种多样的storage和engine的话，会不会对用户来说很麻烦呢？这里Vault借用了类似Virtual Filesystem的展现方式，即只对用户展示抽象后的接口，比如read，write，list，而不会暴露任何具体的storage特异性。这个概念似乎并不是只有VM在用，那为什么要用VM举例呢？因为Vault使用了文件系统中的路径（Path）的概念来规划Secret的存储，每个路径的跟会被绑定其Secret的type，这样在read或write一个路径时，Vault可以根据type来判断如何生成Secret或获取Storage中数据。
有了类似文件系统的路径后，对路径上的Secret的访问控制就变得很直白了。Vault中使用了策略（Policy）来规划对Secret的访问权限，没有policy会针对一个路径（支持wildcard）指明capabilities如create, update和delete。那么设计好了policy改用到哪里呢？Vault中的policy只能用来绑定给某个授权token，表明一旦该token出现，它的capabilities即是那些它绑定的policy中定义的capabilities的总和。上一张提到的“Root Token”就绑定了一个自带的root policy拥有了对于几乎所有path的所有capabilities。
在现代的安全系统中，一个token的存在可以被认为是一次授权行为的完成。这里还要强调一下认证（authentication）和授权（authorization）的区别，认证即证明身份，授权意为给予某个受体以某些权限，这两个步骤经常先后发生，但是不应该有任何耦合，身份认证的信息和身份对应的权限也应该是分开的。Vault里的token应该是被认为是授权的结果而不是认证的结果，虽然但所受的权限是通过认证后的身份来查询的，那么授权的对象是什么呢？可以理解为是要和Vault进行交流的人或者程序。Vault提供了多种认证方式，从传统的用户名口令到第三方身份提供商都广泛支持。但是Vault并没有一个专门的明确的用户数据库，它有的是对于具体认证方式的可能性，直白点说就是不会吧用户的信息存起来，而是根据某种开启了的（enabled）验证方式（Auth Method）来会验证，并在成功时返回一个token。之后Vault会根据使用者提供的token来判断其权限范围，但是究竟是不是本人在使用，Vault并不在意。