Rancher 如何将 Active Directory principalID 从 GUID 反向迁移回 DN【免费下载链接】rancherComplete container management platform项目地址: https://gitcode.com/GitHub_Trending/ra/rancherRancher 2.7.5 曾把 Active DirectoryAD用户的 principalID 从 DNdistinguished name迁移为基于 GUID 的形式这导致部分用户在 2.7.5 中出现了重复账号、GUID 映射到多个 Rancher 用户、重复用户登录失败等问题。如果你需要把这些 GUID 形式的 principalID 反向迁回 DN 形式Rancher 仓库自带一个反向迁移工具cleanup/ad-guid-unmigration.sh它通过 Rancher Agent 以 Job 形式在集群内执行。本文基于仓库中的 ad-guid-README.md 与 ad-guid-unmigration.sh 说明这条操作路径。适用前提来自文档 Requirements 一节环境中已配置 Active Directory 作为认证提供方。如果 AD 不是当前认证提供方工具不会做任何操作并直接退出AD 服务账号service account必须有权限读取 Rancher 中已知的所有用户文档建议该脚本在 Rancher v2.7.6 上使用在 v2.7.5 上运行可能产生性能问题且脚本自身会额外提示若在 v2.7.5 上运行后 Rancher 重启会撤销该工具的效果。工具会做什么运行后工具会遍历所有 Rancher 用户用已配置的 AD 服务账号查询每个用户的 DN再在 Rancher 内部查出该用户的 Tokens、ClusterRoleTemplateBindingsCRTB、ProjectRoleTemplateBindingsPRTB和 GlobalRoleBindingsGRB。凡是引用了 GUID 形式 principalID 的对象包括用户对象本身都会被更新为 DN 形式的 principalID。它还会处理两类残留问题原始迁移到 GUID 过程中被重复创建的用户工具会把相关 token 和绑定映射回原用户再删除误建的较新用户绑定类对象CRTB/PRTB/GRB必须以删除再创建的方式迁移不能原地更新。这意味着这些绑定会得到新名字新对象上会带有ad-guid-previous-name标签值是被删除对象的旧名字README 将其描述为 annotation脚本横幅与源码 adunmigration 实现 实现为 label。如果你使用 Terraform 这类依赖对象名字的外部状态工具这一点可能造成影响。执行前的准备先做备份。README 明确建议在运行该工具前对 Rancher 打快照take a snapshot以便需要时恢复。确认版本。脚本在非 dry-run 模式下会执行kubectl get settings server-version --template{{.value}}检查 Rancher 版本若为 v2.7.5会打印红色警告并要求交互确认后才继续。准备 kubectl 权限。脚本通过 kubectl 在cattle-system命名空间创建 ServiceAccount、ClusterRole、ClusterRoleBinding 和 Job并读取 Job Pod 日志因此运行脚本的机器必须配置好能访问该 Rancher 集群的 kubeconfig。理解脚本的交互确认。脚本执行前会打印横幅说明它会删除并重建 CRTB/PRTB/GRB、建议先做 Rancher 备份并要求回答Do you want to continue? (y/n)v2.7.5 环境下还会有一次额外确认。执行反向迁移脚本用法来自 README Usage via Rancher Agent 一节./ad-guid-unmigration.sh AGENT IMAGE [--dry-run] [--delete-missing]其中AGENT IMAGE需要替换为 Rancher Agent 镜像文档给出的地址是docker.io/rancher/rancher-agent:v2.7.6。两个可选标志的含义--dry-run只运行迁移逻辑不修改任何 Rancher 数据预期变更会以日志信息的形式输出。设置了该标志时--delete-missing不会生效用户不会被删除--delete-missing删除在 Active Directory 中查不到的 Rancher 用户按 GUID 查询不到。这是不可逆的用户删除操作除非确认环境中存在这类残留用户否则不建议加上。建议的操作顺序是先跑一次 dry-run在日志里核对将要变更的对象再不带--dry-run正式执行# 第一步预演不改数据日志中列出将被变更的对象 ./ad-guid-unmigration.sh docker.io/rancher/rancher-agent:v2.7.6 --dry-run # 第二步确认日志内容无误后正式执行 ./ad-guid-unmigration.sh docker.io/rancher/rancher-agent:v2.7.6脚本内部的行为把上述资源清单cattle-cleanup-sa、cattle-cleanup-binding、cattle-cleanup-role、cattle-cleanup-job均带rancher-cleanup: true标签通过kubectl apply提交Job 容器以agent命令运行环境变量AD_GUID_CLEANUPtrue--dry-run会追加DRY_RUNtrue--delete-missing会追加AD_DELETE_MISSING_GUID_USERStrue对应入口逻辑见 cmd/agent/main.go 中对AD_GUID_CLEANUP、DRY_RUN、AD_DELETE_MISSING_GUID_USERS三个环境变量的处理。提交后脚本轮询找到 Job Pod 并kubectl logs -f跟踪输出Job 成功结束后脚本会自动kubectl delete掉自己创建的资源。需要说明的是正式执行期间 AD 登录会被临时禁用认证代码在迁移状态为 Running 时对登录返回 login is disabled while migration is running见 activedirectory_provider.go。迁移完成后恢复。验证结果工具会把状态写入cattle-system命名空间中名为ad-guid-migration的 ConfigMapkubectl -n cattle-system get configmap ad-guid-migration -o yaml判断依据README Additional notes 一节数据键ad-guid-migration-status的值为Running表示工具正在运行值为Finished表示已完成如果运行中断在结束之前状态会停留在Running之后再次运行脚本会立即退出。想让它重新运行要么编辑该 ConfigMap 删掉这个键要么整个删除这个 ConfigMap然后重新执行脚本。源码中还定义了其余状态值FinishedWithMissing、FinishedWithSkipped、Failed以及percentDone、skippedUsers、missingUsers等结果字段见 migrate.go。状态为FinishedWithMissing或FinishedWithSkipped时说明存在 AD 中查不到或连接失败被跳过的用户此时可以在 Rancher 已重启的前提下再手动运行工具尝试处理Failed表示执行过程中出错应回看 Job Pod 日志定位。超时与手动清理脚本对日志跟踪设置了约 5 分钟的启动超时每 0.5 秒计一次超过 600 次即超时。超时后脚本会打印手动清理命令可按原样执行用于删除本次工具创建的对象kubectl --namespacecattle-system delete serviceaccount,job -l rancher-cleanuptrue kubectl delete clusterrole,clusterrolebinding -l rancher-cleanuptrue这两条命令只删除带rancher-cleanuptrue标签的对象即本次工具注入的 ServiceAccount、Job、ClusterRole、ClusterRoleBinding不影响 Rancher 自身资源。若 Job 失败需要排查可用kubectl --namespacecattle-system get jobs查看状态。限制与边界绑定对象迁移后名字会变删除再创建依赖绑定名字的外部工具可能受影响旧名字保存在新对象的ad-guid-previous-name标签中对非 AD 认证环境工具不做任何事并退出文档建议目标版本为 v2.7.6Agent 镜像也应对应使用v2.7.6标签在 v2.7.5 上运行存在性能问题和重启后效果被撤销的风险脚本会阻止式地提示这一点。【免费下载链接】rancherComplete container management platform项目地址: https://gitcode.com/GitHub_Trending/ra/rancher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考