Vault中的数据都是默认加密的,即使底层storage的访问权被非法破解,攻击方也不会得到明文数据,甚至storage可选则仅存在内存里,不会被persist,那么剩下的问题就集中在如何管理访问权。Vault也采用了比较流行的Role-Based Access Control(RBAC),即访问权限被划为多个policy然后绑定到某个role上,任何个体若能提供此role的身份凭证,机会被授予其所绑定的policy。这个概念没什么新鲜的,人类从古至今都在用这种方式来管理“访问权限”。比如说,情报人员接头时会对暗号,暗号对了才有可能是正确的人,然后才会传递情报。
Vault中的身份认证(AuthN)和授权(AuthZ)是完全分开的。Vault用户或者app可以使用某一个启用了的认证方式来进行AuthN,但不管通过什么方式验证了身份之后,最终都会获得一个Token,其实就是一个string。这个Token会对应一个个体已经验证了的事实,所以可以凭Token根据其绑定的policy来代替用户访问资源。比如说一个TokenA有且仅有对“csubc/cpsc/100”的read权限,那么出示了TokenA的任何个体都可以执行vault read csubc/cpsc/100
并在这个值存在的情况下获得结果,然如果执行了vault read csubc/cpsc/100
则会提示无法访问。
Vault内部会保存一个认证数据(Authentication Data)和policy的对应表,即保存某个用户在某个认证方式下有什么policy可用。这里用户的概念就被模糊了,没有一个明确的数据库来保存用户的profile,比如生日,姓名,地址,电话等信息,Vault系统中也并不在乎是否真的有人类用户。
默认情况下,Token是没有任何关于用户的权限的,一定要绑定了policy才有可能有权限。那么上面几个章节为什么没有出现这个policy和token有关的错误呢?因为Vault启动后会生成一个名为Root Token来执行操作,而dev server会默认使用这个Root Token来尽行操作。这个root Token绑定着一个root policy,就像root用户一样,有着对任何路径的任何权限,所以没有出现过关于访问权的问题。在生产环境中,要谨慎对待任何带有root policy的Token,就像Linux对待root一样谨慎。