Vault 直接集成或通过微服务
我使用 Hashicorp Vault 在 KV Secrets 引擎中存储多个机密，其中之一是数据库连接字符串 - 用户名、密码、主机 ip 和端口。我有多个微服务，需要使用这个数据库密钥来连接数据库。
请澄清以下哪种集成模式是有效的：
- 与 Vault 直接集成：每个微服务都将与 Vault 直接连接以获取操作所需的机密。所有微服务都将配置保管库令牌（在 K8s 密钥中）用于访问保管库。
- 通过另一个微服务检索机密：是否应该有一个抽象层，即用于 Vault 交互的单独微服务，并且所有其他微服务将调用此 Vault 微服务的 API 来获取它们想要的机密。保管库令牌（在 K8s Secrets 中）将仅由一个微服务访问。
I am using Hashicorp Vault to store multiple secrets in the KV Secrets engine, one of which is the database connection string - username, password, host ip and port. I have multiple microservices, which need to use this db secret to connect with db.
Please clarify which of these integration pattern is valid:
- Direct Integration with Vault: Each of the microservices will have direct connection with Vault to get the secrets needed for the operation. All the microservices will have the vault token configured (in K8s secrets) for accessing the vault.
- Retrieving secrets via another microservice: Should there be an abstract layer i.e. a separate microservice for Vault interaction and all the other microservices will call the APIs of this vault-microservice to get the secrets they want. The vault token (in K8s Secrets) will be accessed by only one microservice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
另一个微服务是抽象层。这是额外的工作，可能允许您将来更改秘密提供者。
除非您能够证明编写和维护该抽象层的合理性（因为您希望在某些部署中使用 Vault，而在其他部署中使用 AWS Secrets Manager），否则就不要费心了。
另一个问题是，虽然 Vault 的 KV 存储很常见，并且还有其他几种实现，但是如果您想使用 传输、PKI 或 SSH CA？这些服务存在于其他地方（例如在 AWS 中），但它们不具有同等功能。您可能不希望陷入支持抽象层中的这些差异的困境。
一种允许您将实现与代码分离的低成本替代方案是在代码中使用简单的 KVSecrets 类来包装 Vault API 类，即 软件设计模式称为外观。但请记住，除非您使用两项服务测试您的课程，否则您不能保证有一天可以迁移到另一项服务。
因此，考虑到这一切，只需直接调用 API 或使用适合您的编程语言的 Vault 库。
The other microservice is an abstraction layer. It is extra work that might allow you to change secrets provider in the future.
Unless you can justify writing and maintaining that abstraction layer (because you want to use Vault in some deployments and AWS Secrets Manager in others), then don't bother.
The other issue is that although Vault's KV store is quite common and there are several other implementation, what if you want to use Transit, PKI or SSH CA? These services exist elsewhere (in AWS for example), but they don't have feature parity. You probably don't want to be on the hook to support those differences in your abstraction layer.
A low(er) cost alternative that allows you decouple the implementation from your code would be to wrap the Vault API class using a simple KVSecrets class in your code, a software design pattern know as the facade. But remember that unless you test your class with two services, you can't garantee it will be possible to migrate to another service one day.
So considering all this, just call the API directly or use the Vault library for your programming language.