⚠️ 法律与用途声明：本文讨论私有包仓库的 token 自助签发与权限治理，基于开源工具（Conan 2 / Artifactory CE），属于经验分享。所有企业名、服务内部命名、域名、授权码与具体有效期数值均已脱敏。读者须遵守所在地区法律法规。
一、仓库建好了，钥匙怎么发
上一篇（NO.A5）给团队的包安了个家，文末留了个扣子：家建好了，人怎么进？
最省事的办法听上去也最熟悉：把仓库的 admin 账号密码往团队 wiki 上一贴，谁要用谁自己登。很多团队早期就是这么干的，我见过不止一次。
但这等于给全队发了同一把万能钥匙，而且这把钥匙能开家里所有的门、改所有的东西。这种搞法在小团队、纯内网、互相都信得过的阶段能凑合，可一旦团队大了、有外包了、或者哪天要对外，它就是个定时炸弹。
这一篇就聊怎么把钥匙这件事管起来：别让全队共用一把万能钥匙，改成每人领自己那把限次的、能查的钥匙。
二、万能钥匙的祸
admin 密码共享这套，毛病是系统性的，不是"小心点就行"能解决的：
- 泄露就是全军覆没。admin 密码一旦泄露（离职带走了、截图流出去了、写进了某个被同步出去的笔记），对方能干的事和你能干的一模一样。改密码？全员跟着改一遍配置，鸡飞狗跳。
- 权限太大，误操作没法兜。admin 能删仓库、改权限、动任何包。一个手滑，或者一条没想清楚的命令，损失可能捞不回来。
- 出了事查不到人。十个人用同一个账号登，日志里全是 admin，到底是谁删的那个包、谁上传的错版本，对不上号。审计成了空话。
根子上的问题是：一把钥匙既代表了"身份"（是谁），又代表了"全部权限"（能干啥），还永远不过期。这三件事叠在一起，出事是迟早的。
三、限次钥匙：scoped token
解法是给每个人发的不再是 admin 密码，而是scoped token——一种带权限范围、带有效期的凭证。在我们的场景里，它至少分两类：
- 只读 token：只能拉包、看包，不能改。绝大多数开发者日常用这个就够了——你只是来消费包的，凭什么给你改仓库的权力。
- 上传 token：能往仓库推包，但也不能干别的。这个只发给真正需要发布的人（比如 CI、维护者）。
这就是"最小权限"原则的落地：给每个人恰好够用的权限，不多给一格。日常只读的人，就算 token 泄了，对方也只能看、不能改、不能删，伤害有上限。
token 还有个关键特性是限期。它不是永久有效的，过一段时间自动作废。这意味着就算一把 token 泄露了，它也是个"会过期的风险"，不是"永久敞开的门"。配合定期轮换，泄露窗口被压得很短。
顺便说一句，选 Artifactory CE 的同学要注意一个坑：CE 版对用户组、权限目标的 REST API 是有限制的（这些在 Pro 版才行）。所以 CE 上做精细权限，靠的不是建一堆用户组，而是用 scoped access token 这套机制兜底——给 token 配上合适的 scope，照样能做出"只读归只读、上传归上传"的效果。这是个被官方 API 限制逼出来的工程妥协，但够用。
四、自助钥匙柜：让开发者自己领，别都找管理员
scoped token 好是好，但如果每领一把都要找管理员人工签发，管理员就成了瓶颈——开发者排队等 token，管理员天天干这破活，还容易出错。
所以我们做了一个自助式的中间服务，姑且叫它自助 token 柜。它干的事很简单：
- 开发者打开一个页面，点一下，柜子就吐出一张只读 token。
- token 的有效期、权限范围都是预设好的，开发者不能自己改大权限。
- 背后调的是制品库的 token API，管理员凭据只放在这个柜子内部，对开发者不可见。
这个设计的关键是：把"管理员凭据"和"普通 token 签发"这两件事隔离开。开发者永远碰不到 admin 凭据，他拿到的只是一张柜子代签的、权限受限的 token。管理员的活从"天天给人发 token"变成"维护好这个柜子就行"，开发者也不用等谁，随用随领。
五、内网图方便，公网得收紧
这个自助柜在内网阶段可以做得相当方便：开发者从公司内网访问时，柜子自动帮他填好一个内部授权码，他甚至不用记任何口令，点一下就出 token。这是内网红利——可信网络里，体验可以放宽。
但这条便利是绑定在内网这个前提上的。一旦哪天要把仓库或柜子开到公网，这套"自动填授权码"就必须收回去，换成更严格的身份认证。
这是个容易被忽视的判断：便利性和安全性的策略，要按网络暴露面分级。同一套服务，在内网和外网的策略不该一样。内网阶段图方便没人拦你，但心里得清楚——哪些便利是"内网的红利"，公网一开就得收回。等到真开了公网再临时改，往往改不干净。
六、钥匙柜得有领用记录
最后一块拼图是审计。每签发一张 token，柜子都要记一笔：谁（哪个申请者）在什么时间、从哪个 IP、用什么浏览器领的，领的结果是成功还是失败，token 啥时候过期。
这笔账不是为了好看，是为了出事的时候能查。前面说过 admin 共享的最大毛病是"查不到人"，自助柜反过来——每张 token 都能追到具体申请者，token 干的事能和人对上号。审计闭环了，权限才敢真正放出去让大家自助用。
七、几条攒下来的判断
回头总结这套钥匙治理，值钱的还是几个判断：
万能钥匙省事一时，出事是迟早的。admin 共享是舒适区的陷阱，团队稍大就该换掉。
最小权限 + 限期是 token 治理的底线。只读和上传分开、token 会过期，泄露的伤害才有上限。
自助不等于放任。自助签发要让开发者方便，但权限模板要预设死、管理员凭据要隔离，不能因为"自助"就把口子松开。
策略要跟着网络暴露面走。内网的便利在公网要收回，别等开了公网再补。
没有审计，权限不敢放。自助的前提是每张 token 可追溯，否则自助就成了失控。
这套东西落地之后，最直观的感受是：开发者领 token 像从柜子取东西一样简单，管理员再也不用当人肉发卡机，而一旦有什么不对，日志里一查就清楚。好的权限设计，是让该方便的人方便、让该担心的管理员省心。
下一篇，我们要把视角从"怎么用仓库"转到"仓库里放的东西怎么管"：制品真源与加速层分离——为什么 Artifactory 是源、缓存只是影子。
参考链接：
[1] Conan 2：远程仓库认证与 token https://docs.conan.io/2/reference/commands/remote.html
[2] JFrog Artifactory：Scoped Access Token 机制 https://jfrog.com/help/r/jfrog-rest-apis/access-tokens
[3] Artifactory CE 开源版能力边界（与 Pro 对比） https://jfrog.com/open-source/
[4] 最小权限原则（Principle of Least Privilege） https://en.wikipedia.org/wiki/Principle_of_least_privilege
[5] OAuth 2.0 与 scoped token（通用凭证设计参考） https://oauth.net/2/
[6] Conan 2：上传包与权限 https://docs.conan.io/2/reference/commands/upload.html