Vault 与 Kubernetes 的集成 - 1 - Agent Sidecar Injector
本博客所有文章采用的授权方式为 自由转载-非商用-非衍生-保持署名 ，转载请务必注明出处，谢谢。
声明：
本博客欢迎转发，但请保留原作者信息!
新浪微博：@Lingxian_kong
博客地址：孔令贤的博客
微信公众号：飞翔的尘埃
知识星球：飞翔的尘埃
内容系本人学习、研究和总结，如有雷同，实属荣幸！
相信很多人或多或少都听说过 Vault，有些人已经在生产环境中部署 Vault 作为统一的密钥管理工具。企业使用 Vault 就像我们个人使用密码管理工具（比如1Password，LastPass）一样，但不同的是，企业有更严格的监管和合规要求。Vault 的介绍不是本文重点，感兴趣的朋友可以自行 Google。需要特别说明的是，Vault 是开源的，如果你在 IT 行业，还没听说过 Vault，强烈建议恶补一下，因为 Vault 基本上是上了一定规模的公司里 IT 基础设施的标配。
Vault 本身其实跟 Kubernetes 并没有直接的关系，但因为 Kubernetes 的流行，有越来越多的应用部署在 Kubernetes 集群中，这些应用自然也有密码访问相关的需求。Kubernetes 自身提供的 Secret 只是保存密钥，负责密钥在 Kubernetes 集群内的加密存储，但并不负责密钥的管理比如密钥的生成、过期、续租、访问审计等等。Vault 的开源属性天然就对 Kubernetes 友好，所以将 Vault 部署在 Kubernetes 集群中提供密钥管理服务也是很自然的事情。
应用访问 Vault 获取密钥最原始的方式就是直接使用 Vault API 获取 token，进而通过 token 获取 Secret。应用的代码中要包含与 Vault 通信的部分，这对于简单的应用问题不大，但对于比较复杂的应用，维护与 Vault 的集成无疑给开发者增加了工作量，更别提为了集成 Vault 而对现有应用进行改造升级的难度了。
为了解决这个问题，Vault 社区提供 Vault Agent 服务，该服务可以与应用独立部署，负责与 Vault 的交互，比如获取 token，缓存并维护 token，更高级一点还能直接获取 secret 按照预定义的模板生成目标文件供应用使用。应用本身不再感知 Vault，而是直接读取由 Vault Agent 服务生成的结果文件。
在 Kubernetes 环境下，Vault 社区进一步提供了 Agent Sidecar Injector，负责在 Pod 创建的时候自动给 Pod 注入 sidecar 容器跑 Vault Agent 服务。Pod 中的应用使用跟之前相同的方式访问 secret。有了 Agent Sidecar Injector，安装 Vault Agent 的步骤也省了。
因为涉及不同组件之间的交互，所以要提前做一些权限的配置。Vault 中支持使用 Kubernetes 进行认证，需要访问者提供一个 Kubernetes Service Account 作为身份标识。同时，Vault 中要创建 Vault role (注意与 Kubernetes role 区分) 将 Service Account 关联到一个 Vault policy，目的是限制这个 Service Account 被允许的操作。
此时 Kubernetes 跟 Vault 的关系稍有些复杂。总之，Kubernetes 作为 Vault 认证后端，而 Vault 作为 Kubernetes 中负载的秘钥提供者。
