前言：

程序侧的接入对于Vault来说也是一种Accessor的接入，而AppRole绝对不是Vault首推的程序侧接入方式，但它是最方便的接入方式。

AppRole的本质是由Vault为程序单独引入一套由Vault托管的鉴权方式，对于安全平台来说没引入一套新的鉴权方式就意味着多一种暴漏的风险，这就是AppRole并不推荐的主要原因。但往往我们却没有办法绕过AppRole，是跟我们实际应用场景有关的。设想下如果你的产品运行在一套由AWS、阿里云、腾讯云、华为云、容器云组成的多云平台下，你必须用Vault对接所有这些云平台的Accessor，而且你的程序也需要知道自己运行在哪家云平台，这样虽然绕开了AppRole的安全问题，但却增加了太多的工作量，所以对接跨平台是我们选择AppRole的主要原因，而且Vault提供的Agent也对AppRole支持的很好。

AppRole的核心参数：

鉴权三元素：role_id、secret_id和token，先用role_id和secret_id换取token，然后用token做为请求vault敏感信息的凭证。
其中role_id在Vault中不认为是敏感部分，可以直接明文交给相关运维管理，而secret_id认为是敏感信息，需要通过特殊通道进行传递，而vault提供的特殊通道就是Cubbyhole。

 

A warp一个secret内容，会做两件事，1：把内容放在cubbyhole中，2：生成一个一次性短周期的token可以获取cubbyhole中的内容。
 A把这个token给B，B可以根据这个token来获取cubbyhole。 

核心属性：

secret_id_ttl：secret_id的生命周期长度，生命周期内可用来换取token，过期后会被vault自动销毁。
token_ttl：token的生命周期长度，生命周期内可用来向Vault索取敏感信息，过期后需要续约，否则会被销毁。
token_max_ttl：token可被续约的最大时长，过期后会被vault自动销毁。

所以在使用Vault的AppRole时secret_id_ttl、token_ttl、token_max_ttl这三个值的设置是有讲究的。