部分密钥管理应交给 HTTP 代理

# 有些机密管理就该交给 HTTP 代理 - exe.dev 博客 原文：https://blog.exe.dev/http-proxy-secrets 管理机密真让人头疼。 大型组织会把所有机密集中到一个服务里。如果做得好，这些服务能解决大量机密问题，代价是带来一堆运维负担（所以只有大厂才玩得起）和工程复杂度。小团队过去只能忍着，但现在有了智能体（agent），痛苦指数直线飙升。 智能体很挑剔：你直接把 API 密钥塞给它，它往往能用；如果你用一张可快速吊销的临时密钥，风险也能控制。可有些模型（你懂的）一看见密钥就“精神崩溃”，死活不肯继续干活；不那么神经质的模型会把密钥写进跨会话记忆，下次聊天时把已吊销的密钥翻出来，白白浪费宝贵的上下文窗口。而这一切的前提还是你得勤快地去批量生成密钥。 和很多最近被热议的问题一样，表面看是智能体制造了新麻烦，其实问题一直存在。API 密钥方便却权限过大：拿到密钥不仅能自己调接口，还能把密钥转手给别人。我跑在生产环境的软件，只是读个 `/etc/defaults` 里的环境变量，根本没必要拥有这种“二次授权”能力。过去我们靠“写代码时小心点”来防止密钥外泄，但永远不够小心——一旦出漏洞，攻击者就能卷走密钥，随便在哪台机器上作恶，直到我们手动轮换。 自动轮换密钥的尝试成败参半。行业里确实在某些场景用了 OAuth，有时也配了自动轮换。但服务商还是爱发 API 密钥，因为用户省事。（OAuth 理论上简单，实际用起来永远复杂到哭。）有些平台更是集大成地糟糕，比如 GitHub 推荐个人访问令牌 90 天过期——时间刚好长到你会忘记，等你度假回来发现内部服务神秘爆炸。 如今流行的“服务器间 OAuth”也救不了智能体，因为签发流程通常故意设计成要人类在浏览器里点一点，很难自动化。我从没见过哪家服务能通过 API 直接发一个 `OAUTH_CLIENT_SECRET`。所以对传统服务还能凑合（复杂且痛苦），智能体根本玩不转。 那当下到底能怎么办？ 用会“插 Header”的 HTTP 代理。 ## 很多机密就是 HTTP 头 大多数 API 走 HTTP，认证靠 HTTP 头，要么是 Basic Auth，要么是自定义头。以 Stripe 为例： ```bash curl https://api.stripe.com/v1/customers \ -u "sk_test_BQokikJOvBiI2HlWgH4olfQ2:" \ -d "name=Jenny Rosen" \ --data-urlencode "[email protected]" ``` 与其把 `sk_test` 密钥写进 `/etc/defaults`，不如让 HTTP 代理托管机密，调用改成： ```bash curl https://stripe.int.exe.xyz/v1/customers \ -d "name=Jenny Rosen" \ --data-urlencode "[email protected]" ``` URL 指向的是你自建的内部代理服务，密钥彻底消失。你的服务器、智能体能否调用成功，只取决于它们能否连上这个“机密 HTTP 代理”。 机密 HTTP 代理拓扑令人惊喜的是，这一招几乎能覆盖所有机密。 这种代理其实是大型机密管理产品里的一环，但它算最容易实现的部分，却能带来极大价值。 ## exe.dev 的 *Integrations* 最后一问：凭啥要自己写、自己运维这个 HTTP 代理？云厂商应该代劳。于是我们在 exe.dev 里做了 Integrations：给虚拟机打个标签，再把集成绑定到标签，完事。克隆虚拟机也能自动带上集成，智能体想怎么玩都行。 exe.dev 里配置 HTTP 集成的截图针对 GitHub，我们特别做了个 GitHub App，自动帮你走完 OAuth，再也不用手动轮换密钥。更多集成已在路上。