/tags/rbac/ Recent content in rbac on Hugo -- gohugo.io en Thu, 21 May 2026 11:00:00 +0800 /posts/mirrord-vscode-impersonator-ws403/ Thu, 21 May 2026 11:00:00 +0800 /posts/mirrord-vscode-impersonator-ws403/ 我前一篇 《给 mirrord 开发者按 namespace 签发 kubeconfig》 写完之后，第一次用 VS Code 的 mirrord 扩展真接到那套 demo 集群——结果在 agent 起来之后立刻被一个 403 Forbidden 卡住。这篇是那次排查的复盘：从 IDE 报错一路追到 Kubernetes impersonation 鉴权链路上一个我之前不知道的细节，以及最后那条最小修复怎么落到 demo 里。 相关代码都在 meirongdev/mirrord-demo 的 feat/rbac-mirrord-governance 分支上。修复对应的 commit 是 6e44011。 一、出发点：用 VS Code 扩展跑这套 demo 前一篇 demo 用 bash run-mirrord.sh -- java -jar ... 在命令行里直接跑通。但团队里大部分人是从 VS Code / IntelliJ 直接 launch / debug 进程的，所以我得验证一遍：用 mirrord 的 VS Code 扩展，配合 alice 的 scoped kubeconfig，能不能跑出和命令行一样的效果。 流程很简单： 在 VS Code 里装 mirrord 扩展。 /posts/onboarding-developers-to-mirrord/ Wed, 20 May 2026 10:00:00 +0800 /posts/onboarding-developers-to-mirrord/ 我们的服务部署在 K8s 环境里，要调试一个服务，需要改代码、提 GitLab MR、跑 Jenkins 构建、ArgoCD 部署，整个流程非常慢。而且如果多个人要调试同一个服务的不同 feature，环境占用就会是个问题。为了提升调试效率，我们引入了 mirrord OSS——它能绕过整个 CI/CD 链路，直接在本地进程里接入集群服务。但 mirrord OSS 不带权限模型——直接发 cluster-admin 不现实。这篇我从 DevOps 角度走一遍：怎么给一个开发者签发 kubeconfig、按 namespace 给他绑 RoleBinding、验证授权真的生效。 团队层面「几十个人来来去去怎么管」是另一个更通用的 K8s 用户管理问题，不属于 mirrord 特有，我会另起一篇。 这篇文章对应的可运行 demo 放在 GitHub：meirongdev/mirrord-demo，对应 commit 是 6e44011。如果只是想看脚本细节，可以直接看 repo 里的 rbac/ 目录。 配置形态里有一处不直观的地方：除了按 namespace 绑的 RoleBinding，每个开发者还要额外绑一条只含 1 条规则的 cluster-scoped ClusterRoleBinding。这条来自 K8s impersonation 鉴权的硬约束，单独追到的踩坑过程另起一篇 《VS Code 跑 mirrord 撞上 WebSocket 403》。本文直接采用修复后的形态。 一、这次 demo 想解决什么 我自己在团队里推 mirrord 时，技术上没有大问题；卡住的反而是「给开发者发什么 kubeconfig」。mirrord OSS 不会替我们解决这件事，所以真实团队里通常还会多出几个治理问题： 开发者不应该拿 cluster-admin kubeconfig。 新发的 kubeconfig 默认最好没有任何业务 namespace 权限。 授权应该按 namespace 做，而不是一发就能扫整个集群。 撤销访问时，最好只删一条授权关系，不重新签发所有凭据。 管理员需要一套可重复验证的脚本，证明 allow/deny 都按预期工作。 所以这次 demo 的目标不是介绍 mirrord 的所有能力，而是验证一套更窄的接入模型：