SWR 拉镜像报 403：我按三层对了一遍权限，问题出在第二层

昨天论坛上有人问 SWR 的权限管理怎么配置。帖子里 2 楼已经讲了 CCE 拉镜像排查，模板回答也贴了几句，但没人把 SWR 侧的权限本身讲清楚。我把自己配 SWR 时走的流程写下来：权限要分三层对，多数人只配了一层就以为配完了，结果卡在 403 上来回换账号。

先说一个最常见的错：拿主账号 AK/SK 到处推拉

推镜像、拉镜像、管仓库，我习惯分开建 IAM 用户（或用户组），按最小权限给。主账号只做管理员和应急，日常 CI 推镜像用一个只有推权限的专用账号，线上 CCE 拉镜像用一个只有拉权限的专用账号。这样轮换凭证的时候不会一改就全断，出了问题也好定位是哪一路的凭证出了事。

AK/SK 不要写进代码仓库、镜像层、启动脚本或公开的 CI 日志里。这句看着像废话，但我见过不止一次有人把凭证塞进 Dockerfile 的 ENV 里推上去，镜像一公开等于凭证公开。泄露后第一时间在 IAM 里禁用或删除并重新生成，别只改一处就以为完事。

第一层：IAM 管「谁能做什么」

在 IAM 里建用户组，比如 swr-push、swr-pull，把人加进组，权限挂在组上而不是逐个人挂，后续加人直接进组就行。推镜像的组给 SWR 的上传、建仓类权限；拉镜像的组只给拉取、查看类权限，不要给删除、改公开属性这类写权限。

这里有两个地方我得如实说：SWR 预置策略的具体名称，以及组织授权的入口位置，不同区域、不同版本可能有差异，配置时以控制台里 SWR 对应的策略列表和组织页实际显示为准，不要凭记忆照抄策略名。跨账号、跨项目拉镜像时，先确认目标账号的 IAM 侧是否真的有该区域 SWR 的权限，再查 SWR 侧，别只查一边——我见过有人在 SWR 侧翻了半天，最后发现是 IAM 侧那个账号根本没开这个区域的 SWR 权限。

第二层：SWR 组织和仓库管「能动哪个仓库」

SWR 按组织（Organization）归集仓库。先在 SWR 控制台确认三件事：镜像属于哪个组织、哪个仓库、哪个区域。区域错了，权限对了也拉不到，报错是 manifest unknown 或 not found，而不是 403——报错原文不一样，查的方向完全不同。

私有仓库默认必须登录认证才能拉。如果你希望别人免登录拉取，要确认仓库是否被设成了公开属性。排障时不要为了图省事临时把私有仓库改公开，公开后任何人拿到地址都能拉，事后还容易忘记改回去。

一个仓库只放一类用途的镜像，业务镜像和基础镜像分开组织。权限出问题时影响面小，也方便按组织做审计。这个习惯是吃过亏之后才养成的：以前一个组织里混着业务镜像和底座镜像，改一次公开属性，全组织都受影响。

第三层：拉取侧要把凭证带对地方

CCE 拉私有镜像，要在 Pod 所在命名空间配 imagePullSecrets，凭证就是上面那个只给拉权限的 IAM 用户的 AK/SK，docker login 的用户名格式按 SWR 文档给出的 region@AK 形式，并在 Pod 或 ServiceAccount 上引用。只配了 IAM、没配 imagePullSecrets，kubelet 仍然会报 unauthorized——2 楼讲过这一步，这里不再展开。

本地 docker login 时先确认登录的 SWR Endpoint 和镜像所属区域一致。区域不一致时换 Endpoint，不要反复换账号试，账号没错，错的是 Endpoint。凭证失效、轮换后要同步更新 imagePullSecrets 和 CI 里的凭证，旧凭证留在 Secret 里，会出现「昨天能拉、今天突然 unauthorized」。

出问题时按这个顺序查

1. 先看报错原文
   unauthorized / authentication required → 认证或凭证问题
   403                                  → 有身份但无权限
   manifest unknown                     → 镜像名、tag、区域错了
2. 再看 IAM：这个用户/组到底有没有该区域 SWR 的对应操作权限，策略有没有限定到错误的组织或项目
3. 再看 SWR 侧：组织、仓库名、公开/私有属性有没有错
4. 最后看拉取侧：imagePullSecrets 有没有挂到正确的命名空间和 ServiceAccount，Endpoint、区域有没有写错

排障时不要贴出 AK/SK、完整签名或 Token，只贴脱敏后的错误码、区域、组织/仓库名和操作步骤。

回头看昨天那条帖子，提问者真正缺的不是某一个开关的位置，而是「权限分三层」这个分法。IAM、组织/仓库、拉取侧三处对齐，403 才算真正配好，少一层都是在碰运气。