开发容器隔离IDE扩展风险的现实边界

我一度觉得，把开发环境放进容器里，IDE 扩展那点风险就一起被关在门外了。后来才想明白：容器隔离的是工作区和运行时，它管不了“扩展在你的容器里能做什么”。

容器挡住的是文件系统，管不了行为

扩展装进容器以后，依然以你的身份运行在扩展宿主进程里，照样能读工作区、调终端、连外网。Coralogix 那份威胁通告里的行为链就挺典型：解码内嵌私钥、拉起 autossh、关掉 host-key 校验、定时重连。这些动作在容器里一样能跑，只是私钥落在容器内的临时目录。容器真正帮你挡住的是：它碰不到宿主机的其他项目目录，也污染不了本机的依赖环境。这收益是实打实的，但不等于安全。

三个容易漏的边界

第一个是挂载。为了免密拉代码、少配一遍环境，很多人会把宿主机的 SSH 目录、git 凭证，甚至容器运行时的套接字挂进开发容器。挂进去的那一刻，容器就从“沙盒”变成了“有钥匙的房间”。第二个是网络：开发容器本来就要联网装包，扩展想往外连，照样连得通。第三个是 IDE 本身，界面部分和部分扩展仍然跑在宿主机上，工作区扩展和界面扩展的分界比想象中模糊。

隔离之外，还得有准入

版本号这件事容器帮不上忙。版本号是发布者声明的元数据，哈希才是你手上能复核的指纹。团队走内部镜像分发 VSIX，就老老实实记扩展 ID、版本、发布者、SHA-256 和批准日期；直接走市场装的，就得承认无法逐包复核，用允许列表加进程、网络行为监测来补。原文里用 code --install-extension 固定版本也一样，它只保证安装请求指向某个版本，不保证市场返回的包没被替换过。

我自己现在的习惯是：容器照用，但宿主密钥不往里挂，需要拉代码就走转发或者短期凭证；扩展版本固定，装之前先想清楚来源；隔一阵翻一遍容器里的进程和用户级启动项，看看有没有不该出现的 ssh、autossh，或者临时目录里的隐藏私钥文件。容器能缩小爆炸半径，但“我装了什么、它被允许做什么”，这两件事的决定权始终在你自己手里。