Azure-role-selector：让 AI 替你在几百个 Azure 角色里找到刚好够用的那个

在 Azure 上给一个身份分配角色这件事，表面上看是点几下鼠标或者写一行 CLI 的事。实际情况是，你面对的是一个塞了 200 多个内置角色的列表，每个角色背后的权限矩阵细到令人窒息。多数人的应对策略简单粗暴：先甩一个 Contributor，不行就上 Owner。

这当然省事。但也当然不安全。

azure-role-selector 做的事情听起来很朴素：你描述需要的权限，它告诉你该用哪个角色。说人话就是，把下面这四件事打包成一个自然语言对话：

• 翻文档：在 200 多个内置角色里找匹配项
• 对比权限：确认角色的 actions 和 notActions 刚好覆盖需求
• 写 CLI：生成 az role assignment create 命令
• 写 Bicep：输出符合最佳实践的 IaC 代码片段

它背后挂的是 Azure MCP 的工具链，能直接查官方文档、生成角色定义、输出可执行的 CLI 命令和 Bicep 代码片段。

这篇文章会带你走一遍这个 Skill 的完整用法：从安装配置到实际操作，从设计决策到边界场景。读完你会发现，最小权限原则在 AI 的加持下，终于可以从口号变成肌肉记忆。

环境准备

azure-role-selector 本身不要求你装任何额外的运行环境。它是一个纯声明式的 Skill 文件，遵循 Agent Skills 开放标准，核心只有一段 SKILL.md。把它丢到 AI 助手的 skills 目录下，助手就能识别并加载。

真正的前置条件在 Azure 侧。你需要一个可用的 Azure 订阅，以及能连接 Azure MCP 的客户端环境。Azure MCP 是这个 Skill 的”数据源”，没有它，Skill 就只是一段不会说话的 prompt。具体来说，你需要配置好 Azure CLI 并通过 az login 完成身份认证，然后确保 MCP 服务端的 documentation、bicepschema、extension_cli_generate 和 get_bestpractices 这四个工具都已接通。

目前这个 Skill 兼容 26 个主流 AI 编程助手，Claude Code、Cursor、Copilot、CodeBuddy 都在支持范围。安装方式就是下载 SKILL.md 文件，放进对应助手的 skills 目录。以 Claude Code 为例，目标路径是 ~/.claude/skills/。WorkBuddy 则是 ~/.workbuddy/skills-marketplace/skills/。

安装完成后，在助手里直接描述一个 Azure 权限需求，Skill 就会自动触发。你可以试试说一句”我想给一个服务主体分配只能读取某个资源组里 VM 的权限”，看看它返回什么。

操作流程

这个 Skill 的工作流不复杂，但每一步都做得比你想的细。整个流程分三个阶段：匹配、生成、输出。

第一阶段是角色匹配。当你描述”我需要一个能读取存储账户密钥但没法创建新存储账户的角色”时，Skill 会调用 Azure MCP 的 documentation 工具，在 Azure 的内置角色库里做语义检索。它不是在角色名称上做关键词匹配，而是钻到每个角色的 actions、notActions、dataActions 字段里去找。这种粒度意味着它不会把”能读存储账户属性”和”能读存储账户密钥”搞混。

第二阶段是兜底生成。如果内置角色库找不到恰好匹配的，Skill 不会降级推荐一个”差不多够用但权限溢出了”的角色。它会调 extension_cli_generate，按照你描述的权限清单生成一个自定义角色定义，JSON 格式，精确到每一个 Microsoft.Storage/storageAccounts/listKeys/action 级别的操作。这不是模板填充，每一次生成都是基于你当次输入动态构建的。

第三阶段是代码输出。不管走匹配还是自定义路径，Skill 最终都会给你三样东西：推荐的角色名（或自定义角色 JSON）、一条 Azure CLI 的 az role assignment create 命令、以及一段符合 Azure 最佳实践的 Bicep 代码。CLI 命令拿来直接跑，Bicep 片段塞进你的 IaC 模板。整个过程从输入需求到拿到可用代码，不超过三轮对话。

这里有个容易踩的坑：Azure MCP 的 documentation 工具返回的角色权限描述是英文原文，自定义角色生成的 JSON 也是英文。如果你习惯用中文描述需求，Skill 本身能处理，但输出里的角色权限说明可能需要你做好对照查阅的心理准备。

关键设计

这个 Skill 最值得聊的设计，不是它做了什么，而是它没做什么。

SKILL.md 的内容只有一段话，连 100 个单词都不到。没有角色选择逻辑，没有权限比对算法，没有硬编码的角色清单。所有的”智能”来自它声明的那四个 Azure MCP 工具：documentation 负责检索，bicepschema 负责模板规范，extension_cli_generate 负责角色和命令生成，get_bestpractices 负责合规校验。Skill 本身只是一个路由层。

这个设计选择非常聪明。Azure 的内置角色库是动态变化的，每个月都有新角色上线、旧角色废弃。如果把角色选择逻辑写死在 Skill 里，维护成本会随着 Azure 的更新节奏线性增长。把逻辑外包给 MCP 工具，意味着 Skill 永远不需要更新，因为工具背后的数据源是 Azure 的实时文档。

另一个让人舒服的细节是最小权限原则的内置化。Skill 的描述里没有出现”如果需要更多权限就往上加”的逻辑分支。它的指令是”找到满足需求的最小权限角色”，不行就”创建一个刚好够用的自定义角色”。换句话说，它默认你是对的，Azure 的默认角色粒度才是问题。

这种”窄路径”设计在安全类工具里是正确做法。宽路径会让用户产生”反正 Skill 推荐的应该没问题”的错觉，而实际上多出来的那点权限可能正好是攻击者的突破口。窄路径的代价是内置角色匹配成功率可能只有 70% 到 80%，剩下的会走自定义角色分支。但这个代价值得付。

不过我也保留一个疑问：当用户描述得不够精确时，Skill 没有任何追问机制。比如你说”需要管理 VM 的权限”，它不会反问”是需要创建删除，还是只需要开机重启”。它直接按字面去匹配，结果可能偏差。这个短板目前靠使用者的描述精度来弥补，不算优雅。

使用场景

这个 Skill 的典型使用场景并不花哨，但足够高频。

第一个场景是给新服务主体分配角色。假设你在部署一个新的 Function App，需要一个托管标识来读取 Key Vault 中的密钥。直接在 AI 助手里说”给我的 Function App 托管标识分配读取 Key Vault 密钥的权限，用最小权限角色”，Skill 会查到 Key Vault Secrets User 这个内置角色，顺手把 CLI 命令和 Bicep 片段都给你。

第二个场景是权限审计后的精细化收紧。你的安全团队扫出来一个服务账号挂了 Contributor，实际上它只操作过某个资源组的网络配置。你把需求描述给 Skill，它会告诉你 Network Contributor 就够了，权限范围从整个订阅收窄到网络相关操作，攻击面缩了不止一个数量级。

第三个场景是跨团队协作时的权限沟通。A 团队的开发说我需要你给我的服务主体开某个权限，但他说不清楚具体是哪个角色。你把他的需求原文丢给 Skill，30 秒内拿到角色名和分配命令，直接回给他。不用自己在 Azure Portal 的角色列表里翻十分钟。

这三个场景覆盖了角色分配的大部分日常摩擦：新建、收紧、沟通。最后一个场景尤其实用，因为现实中很多权限问题不是技术问题，是沟通成本问题。

洞察与反思

用了几轮后的直观感受是：这个 Skill 把一件”我知道应该做但懒得做”的事，变成了”做起来比不做还省事”的事。

Azure 的 RBAC 体系设计本身没有问题，但它的可用性一直是个劝退项。200 多个内置角色，每个角色的权限矩阵散落在文档的各个角落。你想查一个角色到底能不能做某件事，典型路径是这样的：

1. 打开 Azure 文档，在角色列表里翻到目标角色
2. 展开 JSON 权限定义，在一堆 actions 里找对应操作
3. 对照需求清单逐条比对，看覆盖了哪些、漏了哪些、多了哪些

最后出来两个结果：权限漏了一项，或者多了三四个不该有的操作。这个流程本身就在惩罚”想做得正确”的人。

azure-role-selector 的价值不在技术上多惊艳，它用的是现成的 Azure MCP 工具链，没什么自研能力。真正的价值在于它把”查文档、写命令、写模板”这三件琐事压缩到了一句话里，消除了最小权限实践的摩擦成本。同样的需求，手动操作平均 10 到 15 分钟，用 Skill 不到 30 秒。

和直接问 Copilot 或者 ChatGPT 相比，它的优势在于数据源的可信度。Azure MCP 的 documentation 工具对接的是 Azure 官方文档，不是训练数据里某篇 2023 年的博客。这意味着角色名称、权限定义、CLI 语法都跟当前 Azure 版本对齐，不会给你一个已经废弃的角色或者过时的命令格式。

但它的局限也很明显：只覆盖角色分配这一个环节，跟后续的权限审计、异常检测、合规报告没有打通。它是一个点工具，做的是一件事，也只做一件事。如果你的场景是”帮我建立一套完整的 Azure 权限治理体系”，这个 Skill 只是拼图里的一块，你还得自己搭剩下的部分。

资源地址

总结

azure-role-selector 解决的是一个具体到几乎无聊的问题：在 Azure 里给身份分配最小权限角色。但正是因为它足够聚焦，才做得足够好。

它的核心武器不是自己有多聪明，而是知道自己不聪明，把重活全甩给了 Azure MCP 的实时文档和代码生成能力。这种”薄 Skill + 厚 MCP”的架构思路，比那些把几百行业务逻辑塞进 SKILL.md 的做法高明得多。

如果你已经在用支持 Agent Skills 的 AI 助手，花两分钟把这个 Skill 装上去。下次再有人问你”这个服务账号需要什么权限”，让 Skill 替你回答。你的时间比翻文档值钱，你的安全基线比省那两分钟重要。