V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
HarryYu
V2EX  ›  程序员

如何统一管理应用中第三方的 APIs?

  •  1
     
  •   HarryYu ·
    yujiangshui · 97 天前 · 1964 次点击
    这是一个创建于 97 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前业务依赖大量的第三方 API,每个 API 都有自己的 authentication 的逻辑和相关 secrets ( client id,secrets 等等)。目前的做法是针对每个需要调用的应用都需要封装一层 API,然后将这些 secrets 用环境变量或者 config 来配置上去。

    目前存在几个问题:

    1. 维护困难,一旦某个 secret 更新,需要挨个修改全部的应用,如果漏掉一个就会挂掉,部分应用需要紧急发布。
    2. 容易泄漏,这些 client secrets 比较重要,需要有权限控制。但是由于放在应用里面,任何一个应用开发者在本地启动的时候,都需要加载这些配置,一旦加载从内存等都是可以找到的。

    目前的解决方案:

    1. 将这些 secrets 和逻辑收敛到一个 Web 应用中,这个应用将读取 secrets 然后支持接收请求,针对不同的第三方 API 进行对应的逻辑,比如获取 access token 然后附加到 request 上面转发给实际接口,然后返回接口的 response 。相当于透传请求,同时附加 access token 等信息。
    2. 这样只需要控制好这个应用的权限即可,维护 secrets 只需要修改一个地方。

    但是这个解决方案的问题:

    1. 可能会形成单点故障,如果挂了的话。不过可以用 K8S 等方案解决。
    2. 请求本身来源的鉴权方式不好实现。由于可以被很多应用使用,这里假设最简单的情况就是没有任何校验,拿到任意请求均可透传。但问题很明显,一旦泄漏就完全没有秘密了。所以这个校验规则要如何实现? IP 白名单?还是再实现一套 OAuth 的校验?

    所以目前的几个问题:

    1. 你的公司是否有类似需求?是如何实现的?
    2. 是否有开源或者 SaaS 服务提供类似的功能?这种技术或者需求是否有一个关键词?
    3. 数据库连接面临同样的需求,即避免将数据库用户密码等存放在各个应用中,数据库如何实现?
    17 条回复    2021-08-23 16:49:45 +08:00
    Sin
        1
    Sin   97 天前
    Secret Manager?
    HarryYu
        2
    HarryYu   97 天前
    @Sin 谢谢回复。目前用的是 Azure key vault,但是还是会比较容易的泄漏,因为启动时应用还是需要拉下来全部的 secrets 。此外,其他应用也需要重复接入 key vault 的 SDK,然后 API wrapper 都要重复实现一遍。
    Sin
        3
    Sin   97 天前
    @HarryYu 一般支持轮换和分角色单独鉴权的吧,感觉对于服务端应用安全性足够了
    Azure 没用过,之前用 AWS 的时候单独写了个共用的配置库,现在用 Google Cloud Run 就直接映射到环境变量了,对应用透明用得还挺开心的
    HarryYu
        4
    HarryYu   97 天前
    lu5je0
        5
    lu5je0   97 天前
    配置中心
    HarryYu
        6
    HarryYu   97 天前
    @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
    sy20030260
        7
    sy20030260   97 天前
    我们的大概思路差不多,所有调用三方接口的收敛到一个服务,对内网服务暴露 RPC 接口。鉴权的话根据业务情况判断是否需要,需要的话用现成的 RPC 鉴权方案,也不复杂
    xwayway
        8
    xwayway   97 天前
    如果出现大量的同一个 api 被不同服务引用的话。还是建议做一个单独的服务,来专门处理外部 api 调用的问题,内部通过 rpc 调用
    Casbin
        9
    Casbin   97 天前
    统一认证鉴权,可以采用我们社区开发的 Casdoor: https://v2ex.com/t/792573

    除了管理 SSO 以及各种第三方 OAuth,Casdoor 其实也管理了所有的 OSS 存储、短信、Email 等的 client id, secret,并暴露出 API 供其他服务端调用,从而隐藏实现细节,例如调用 SendEmail 的 REST API 即可发送邮件
    wujichao
        10
    wujichao   97 天前
    富客户端?
    HarryYu
        11
    HarryYu   97 天前
    @sy20030260 谢谢,看来可行,得自己搞一个了。
    @xwayway 谢谢。
    @Casbin 谢谢自荐,我去研究一下。
    @wujichao 不是富客户端,是多种客户端调用。
    jangit
        12
    jangit   97 天前 via iPhone
    最近有在做个可以来回切换 api 供应商的服务,算是包含楼主说的统一入口功能的,下个月写完丢 github 上
    jeffreystoke
        13
    jeffreystoke   97 天前 via Android
    有同样的需求,我的解决方案是把单个 secret item 通过 fuse 挂载成一个独立文件,应用程序读取文件会触发授权请求,请求带有 uid, pid, 进程名以及进程调用链等,通过自定义 webhook 服务进行授权,成功授权才能读取文件内容。
    Turkestan
        14
    Turkestan   96 天前
    上家也有这种需求,做法是写到 vscode 的配置文件里 (app-root-path/.vscode/secrets.json),至于内部怎么调用,还真没研究过
    dany813
        15
    dany813   96 天前
    dany813
        16
    dany813   96 天前
    @dany813 那这样本地岂不是随便看了
    egfegdfr
        17
    egfegdfr   96 天前
    我们是两个账号、一个测试、一个正式、正式账号配置在配置中心、只有运维的人才能看到
    付钱的第三方服务、都会免费给开测试账号的。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1025 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 20:11 · PVG 04:11 · LAX 12:11 · JFK 15:11
    ♥ Do have faith in what you're doing.