DevOps

“我有一个 shell，我很有创造力。” —— Claude 解释为什么他用一个 47 行的脚本，并作为一个字符串传递给 python -c 来执行 这句话是真的。我开发的 AI 代理说过——好吧，不是用确切的这些话，但他的行为证实了。他需要启动一个 ETL pipeline 的某个进程。虽然正确的启动命令写在了 Makefile 里，但出了点问题。而他呢？他并没有询问，而是做了任何拥有 root 权限且无人监管的程序员都会做的事：即兴发挥。 太离谱了（manda huevos）。 无人察觉的捏造操作 我之前写过一篇博客讨论代码生成过程中的幻觉问题：LLM（大语言模型）会凭空捏造一个 JSON 字段，围绕它创建 DTO，生成测试代码，最后你手上有 90 个“绿灯”的测试，验证的却是虚构出来的内容。这是个严重的问题，但至少它是静态的。被捏造的代码不会到处乱跑，等着有人来审查。 不过，还有另一种更危险的捏造：操作性捏造。这一问题发生在代理不是编写代码，而是凭空创造出“执行路径”时。 问题的模式永远是一样的： 正确路径失败 → 代理寻找捷径 → 捷径“成功” → 潜在损害 举两个真实案例，都是关于一个 ETL pipeline 聚合多个 web 数据源的。 案例 1：字符串里的脚本。 这个 pipeline 有一个命令 make scrape-fuente，会启动一个守护进程，从而启动多个worker。守护进程负责监控、重启崩溃的 worker，并关闭空闲连接。有一天，代理需要启动一个抓取（scrape）任务。但由于依赖问题，make 运行失败了。他怎么办？他创建了一个内联的 47 行 Python 脚本，把它作为字符串传递给 python -c "..." 运行。没有错误处理，没有 watchdog，也没有清理操作。的确运行了……直到一个 worker 卡住，没人来重启它。这样的情况导致数据不完整、连接未关闭，而我直到三天后才发现。 案例 2：孤独的 worker。 另一个会话，同一个 pipeline。这个代理直接运行了 voyeur worker，跳过了守护进程。worker 开始抓取数据，遇到了一个网络超时，然后陷入了重试的死循环，不断消耗资源。而没有守护进程，也没有集中日志记录，没有人知道发生了什么。几小时过去，服务器一直在不停尝试访问一个返回 503 状态码的页面。 ...

5分钟。就这么长时间。 一个安全研究员故意在GitHub的公开仓库中发布了一个AWS访问密钥，作为实验。 5分钟后，就有人在用它挖加密货币了。 5分钟。 有机器人24/7扫描GitHub，专门寻找这种东西：暴露的凭证。而且它们很快。比你意识到自己搞砸了要快得多。 数字很可怕 据GitHub统计，2024年有3900万个密钥在公开仓库中泄露。比前一年增加了67%。 专门扫描这类问题的GitGuardian仅在公开仓库中就发现了2370万个新密钥。最糟糕的是：2022年检测到的70%密钥在2024年仍然有效。 两年后。仍然能用。等着有人使用它们。 不只是无名小卒 丰田在GitHub上暴露了AWS凭证，这些凭证可以访问他们的车辆远程信息处理系统。培生集团因为有人在配置文件中留下GitLab令牌而丢失数据。酒店管理公司Otelier因为Bitbucket上暴露的凭证，看着8TB的S3数据被盗。 这不只发生在实习生身上。财富500强企业也会中招。 经典借口：“这只是我的个人项目” 是啊，当然。 问题是那个个人项目使用了和生产环境相同的OpenAI API密钥。或者你的Telegram机器人令牌。或者你的测试数据库凭证，哦惊喜，里面有真实数据因为"这样测试更容易"。 然后有一天你不假思索地执行git push。或者因为想展示给某人看而把仓库从私有改为公开。或者GitHub出现bug临时暴露了私有仓库（这种事发生过）。 然后你发现AWS账单从20欧元变成了2000欧元。一夜之间。 “但我立刻删除了” 又一个经典。 Git是版本控制系统。它的工作就是记住发生的所有事情。删除提交不会从历史记录中删除密钥。强制推送不会从分支中删除它。绝对不会从已经复制它的机器人那里删除。 一旦密钥接触到公开仓库，就算是被泄露了。句号。必须轮换。 灾难金字塔 这是典型项目中密钥管理的演进过程： 级别1：地狱 1 2 3 # config.py AWS_KEY = "AKIAIOSFODNN7EXAMPLE" AWS_SECRET = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" 直接写在代码里。已提交。在生产环境中。别笑，这真的存在。 级别2：炼狱 1 2 3 # .env (据说在.gitignore中) AWS_KEY=AKIAIOSFODNN7EXAMPLE AWS_SECRET=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY 好一些，但那个.env最终会出现在备份中，在你通过Slack发送的压缩包中，在你卖掉的硬盘中… 级别3：边缘地带 1 2 # 系统环境变量中的密钥 export AWS_KEY=... 可以，但你把它们存在哪里？便利贴？桌面上的secrets.txt文件？给自己发的Slack消息？ ...