安装
为了便于生产环境使用,我这里是采用了docker安装。
version: "3" //文件:docker-compose.yml
services:
vault:
image: vault
复制代码
概念
- 后端存储
负责持久化加密数据,这个仓库并不安全,所以Vault只用来存数据,并不信任他。开启服务的时候需要配置这个仓库。
- 屏障
在Vault和存储后端之间流动的所有数据都会通过这个屏障。屏障确保只写出加密数据,并在途中验证和解密数据。就像银行金库一样,在进入任何内部之前,屏障必须“开封”。
- 密码引擎
密码引擎负责管理密码。“kv”这样的引擎在查询时只是简单的返回密码。还有一些引擎支持策略,动态生成密码,这样的密码唯一性很高,并且可以策略升级和废除之前的密码。 举个例子:好比mysql密码引擎可以配置“web”策略,当“web”密码被读取时,会生成一个新的用户密码并给予相应的权限。
- 审查设施
审查设施负责管理审查日志。每个请求和响应都会通过配置的审查设备。这样可以把不同的审查设备集成进来。
- 验证方法
验证方法用来验证链接进来的用户和应用。一旦授权成功,就会返回相应的策略列表。Vault会返回Token用于以后的请求。 举例:
userpass
认证方法会使用用户名和密码来验证。github
会允许用户通过github来授权。 - 客户端令牌
这个跟我们平时使用的请求头的token一样。并且会使用这个token来辨别用户和强制执行适用的ACL策略。
- 密码
密码是Vault返回的一种术语,包含了机密信息或者加密技术。并非返回的都是秘密,还包括系统配置,状态信息和非机密的策略。密码都是有期限的,并不是永久有效的。Vault会在失效前清除密码,操作者也可以主动清除密码。Vault和用户之间的合约很重要,因为他允许更改密钥和策略而无需人工干预。
- 服务
Vault依赖于一个一直运行的服务。服务会提供一些api,用于跟用户交互,管理密码引擎之间的交互,ACL执行和密码失效与撤销。服务为基础的架构可以解耦分离用户和密钥策略之间的关系。实现集中审查日志记录并简化操作员的管理。
架构
这些审查设备,身份验证方法和机密引擎的配置必须存储在Vault中,因为它们对安全性敏感。只有具有正确权限的用户才能修改它们,这意味着无法在屏障之外设置它们。通过将它们存储在Vault中,对它们的任何更改都受ACL系统保护并由审计日志跟踪。
在启封Vault之后,可以将请求从API处理到核心模块。核心用于管理通过系统的请求流,强制执行ACL,并确保完成审计日志记录。
当用户链接到Vault后,会验证用户。Vault提供可配置的auth方法,为所使用的身份验证机制提供灵活性。人机友好机制(如用户名/密码或GitHub)可能会用于用户,而应用程序可能会使用公钥/私钥或令牌进行身份验证。身份验证请求通过核心模块流入auth方法,该方法确定请求是否有效并返回关联策略列表。
策略只是一个命名的ACL规则。例如,“root”策略是内置的,允许访问所有资源。您可以创建任意数量的命名策略,并对路径进行细粒度控制。Vault仅以白名单模式运行,这意味着除非通过策略明确授予访问权限,否则不允许执行此操作。用户可能有多个策略,只要满足其中任意一个就可以执行。策略由内部策略存储库存储和管理。这个内部存储通过系统后端进行操作,安装在sys/
目录。
一旦进行身份验证,auth方法就会提供一组适用的策略,由令牌存储生成并管理新的客户端令牌。需要定期更新客户端令牌以避免失效。
经过身份验证后,将提供请求以提供客户端令牌。令牌用于验证客户端是否已获得授权并加载相关策略。策略用于授权客户端请求。然后将请求路由到秘密引擎,该引擎根据其类型进行处理。客户使用租约ID来续订或撤销其密码。如果客户端允许租约到期,则到期管理器会自动撤销该密码。
该核心处理对审计代理的请求和响应的日志记录,该请求将请求传播到所有已配置的审计设备。
这些概念讲的有点繁琐,不过大体讲清了基本的业务架构。
借鉴文章: vault官方文档