原文来源：Which Azure Cosmos DB Role Does My App Need?
这个 Cosmos DB 指南中最重要的思想不是一个命令、一个角色 ID 或一个 CLI 技巧——而是架构性的：停止将凭据视为应用配置，开始将身份视为运行时状态。
太多团队仍然使用连接字符串发布，因为这样感觉很快。其实不快。这是递延的风险。配置文件中的每个密钥都是一个等待发生的事故——一次匆忙的提交、一个复制的管道变量或一个泄漏的日志。托管身份加上数据平面 RBAC 几乎完全消除了这类故障。
实际的挑战在于对控制平面和数据平面授权的混淆。这是很多本来很强大的团队浪费数天时间的地方。资源上的 Azure RBAC 角色不会自动授予文档访问权限，而 Cosmos 数据平面角色也不授予账户管理权限。如果你的团队没有在你的操作手册中明确记录这种分离，你将不断遇到脆弱的部署和难以调试的 403 错误。
我对生产团队的个人建议
- 读取路径从 Data Reader 开始，只有确实需要写入的地方才使用 Data Contributor。
- 仅在每个账户有单一应用边界时才广泛授权。
- 如果你跨多个服务共享一个账户，尽早将范围缩小到数据库或容器边界，而不是等待审计压力。
这是一类复利式的决策。当你用 DefaultAzureCredential 和仅端点配置来连接你的 .NET 应用时，每个环境都变得更干净：本地、CI、staging 和生产。你也能更快地进行事件响应，因为你可以通过角色分配来推理权限，而不是寻找神秘的密钥。
文章还暗示了一个成熟团队应该接受的理念：权限是迭代式设计，而非一次性设置。你可以从足够宽的范围开始以完成交付，然后通过遥测和访问审查逐步收紧。最小权限不是一个哲学终点，而是一个交付习惯。
如果你只从这篇文章中采纳一件事，那就是这个：先移除密钥，再优化角色。搞反顺序的团队通常会在会议上卡住。先移除密钥的团队通常先交付，再加固。
在 2026 年，无密钥数据访问不是一个高级模式。它是在 Azure 上运行严肃 .NET 系统的最低负责任标准。
