/tags/authorization/ Recent content in authorization on Hugo -- gohugo.io en Fri, 29 May 2026 09:30:00 +0800 /posts/mirrord-gitops-per-user-rbac/ Fri, 29 May 2026 09:30:00 +0800 /posts/mirrord-gitops-per-user-rbac/ 💡 这篇我整理一下按用户维护 RBAC 清单的方式。按组（group-based）或其他高级授权模式将在后续文章讨论。 背景：mirrord 的 RBAC 现状 mirrord 是开发者本地调试工具，让开发者的本地进程可以通过集群中的 agent pod 访问 in-cluster 的网络资源（mirrord 是什么、完整 demo 见 《用 mirrord 把本地进程接入 K8s 集群》）。作为集群管理员，如果你想要： ✅ 开发者能在指定 namespace 运行 mirrord ✅ 开发者不能访问其他 namespace ✅ 开发者不能删除应用或改动配置 ✅ 权限变化可以审计和回滚 那么你需要给每个开发者颁发 identity（身份凭证） 和 授权清单（RoleBinding）。 mirrord 的两层 RBAC 模型 mirrord 的权限拆分挺有意思，分成两部分： 层级 资源 作用域 目的 命名空间权限 RoleBinding → ClusterRole/mirrord-developer 某个 namespace 赋予开发者在该 namespace 内 create/delete jobs、port-forward 等能力 cluster-scoped 权限 ClusterRoleBinding → ClusterRole/mirrord-impersonator 集群范围 赋予开发者 impersonate ServiceAccount 的能力（WebSocket 隧道认证必需） 这么分的原因是：impersonate serviceaccounts 是 cluster-scoped 虚拟资源，namespace-scoped 的 RoleBinding 无法满足（这条 cluster-scoped 约束的完整原委，见 《VS Code 跑 mirrord 撞上 WebSocket 403》）。