目前业务依赖大量的第三方 API,每个 API 都有自己的 authentication 的逻辑和相关 secrets ( client id,secrets 等等)。目前的做法是针对每个需要调用的应用都需要封装一层 API,然后将这些 secrets 用环境变量或者 config 来配置上去。
目前存在几个问题:
目前的解决方案:
但是这个解决方案的问题:
所以目前的几个问题:
1
Sin 2021-08-22 13:01:39 +08:00
Secret Manager?
|
2
HarryYu OP @Sin 谢谢回复。目前用的是 Azure key vault,但是还是会比较容易的泄漏,因为启动时应用还是需要拉下来全部的 secrets 。此外,其他应用也需要重复接入 key vault 的 SDK,然后 API wrapper 都要重复实现一遍。
|
3
Sin 2021-08-22 13:47:20 +08:00
@HarryYu 一般支持轮换和分角色单独鉴权的吧,感觉对于服务端应用安全性足够了
Azure 没用过,之前用 AWS 的时候单独写了个共用的配置库,现在用 Google Cloud Run 就直接映射到环境变量了,对应用透明用得还挺开心的 |
4
HarryYu OP |
5
lu5je0 2021-08-22 13:56:26 +08:00
配置中心
|
6
HarryYu OP @Sin 感谢补充。这里的问题其实不单单是配置如何管理自动映射,还有不暴露,而且要跨平台。比如我们的 use cases:
1. 使用 Postman 发请求查询第三方接口,绕开我们自己的逻辑进行测试。 2. 使用 serverless 的 function 做一些 jobs 和 checks 3. 一些 Web apps 在 K8S 里面 目前的 secrets 需要分别在三个地方设置使用。如果用 secret manager,由于 serverless 和 K8S 都是一家云服务提供商,可以通过接入 SDK 或者平台自动集成的方式映射。但是 Postman 没法接入,仍然需要获取所有 secrets 配置上去。 其次是安全问题,在开发中需要支持本地就可以跑起来,因此在本地也需要可以用 SDK 拉下来 secrets,然后每个开发者都会知道。 --- 目前看了一圈,估计是要实现一个 internal 的 token 校验服务到这个 proxy server,然后一旦通过即可发送请求到第三方。大概架构图如下: ![]( https://blog.approov.io/hs-fs/hubfs/Using%20a%20Reverse%20Proxy%20to%20Protect%20Third%20Party%20APIs-2.png?width=1200&name=Using%20a%20Reverse%20Proxy%20to%20Protect%20Third%20Party%20APIs-2.png) https://blog.approov.io/using-a-reverse-proxy-to-protect-third-party-apis |
7
sy20030260 2021-08-22 14:36:13 +08:00
我们的大概思路差不多,所有调用三方接口的收敛到一个服务,对内网服务暴露 RPC 接口。鉴权的话根据业务情况判断是否需要,需要的话用现成的 RPC 鉴权方案,也不复杂
|
8
xwayway 2021-08-22 16:19:48 +08:00
如果出现大量的同一个 api 被不同服务引用的话。还是建议做一个单独的服务,来专门处理外部 api 调用的问题,内部通过 rpc 调用
|
9
Casbin 2021-08-22 16:24:04 +08:00
统一认证鉴权,可以采用我们社区开发的 Casdoor: https://v2ex.com/t/792573
除了管理 SSO 以及各种第三方 OAuth,Casdoor 其实也管理了所有的 OSS 存储、短信、Email 等的 client id, secret,并暴露出 API 供其他服务端调用,从而隐藏实现细节,例如调用 SendEmail 的 REST API 即可发送邮件 |
10
CDuXZMAPgHp1q9ew 2021-08-22 17:58:51 +08:00
富客户端?
|
11
HarryYu OP |
12
jangit 2021-08-22 19:12:02 +08:00 via iPhone
最近有在做个可以来回切换 api 供应商的服务,算是包含楼主说的统一入口功能的,下个月写完丢 github 上
|
13
jeffreystoke 2021-08-22 20:54:34 +08:00 via Android
有同样的需求,我的解决方案是把单个 secret item 通过 fuse 挂载成一个独立文件,应用程序读取文件会触发授权请求,请求带有 uid, pid, 进程名以及进程调用链等,通过自定义 webhook 服务进行授权,成功授权才能读取文件内容。
|
14
Turkestan 2021-08-23 13:53:26 +08:00
上家也有这种需求,做法是写到 vscode 的配置文件里 (app-root-path/.vscode/secrets.json),至于内部怎么调用,还真没研究过
|
17
egfegdfr 2021-08-23 16:49:45 +08:00
我们是两个账号、一个测试、一个正式、正式账号配置在配置中心、只有运维的人才能看到
付钱的第三方服务、都会免费给开测试账号的。 |