开发者本地桌面如何通过托管标识访问Kusto

托管标识（Managed Identity）是Azure为平台托管计算资源设计的无密钥认证能力，仅能在Azure托管资源环境内使用：

• 你部署在VMSS上的服务能通过WithAadSystemManagedIdentity()正常访问Kusto，是因为VMSS作为Azure原生托管资源，底层自动暴露了Azure Instance Metadata Service（IMDS）令牌端点，SDK可以自动从该端点获取托管标识对应的访问令牌。
• 本地桌面环境不属于Azure托管计算资源，不存在IMDS端点，因此无论调用系统托管标识还是用户托管标识的认证接口，都无法获取有效令牌，授权失败和个人账号的角色分配没有关系。

你已经将个人用户主体添加到Kusto集群权限列表、且应用密钥方式可正常连通的前提下，不需要额外配置任何角色分配，直接替换本地环境的认证初始化逻辑即可，完全可以达到和托管标识一致的无硬编码密钥效果：

• 方案1：复用Azure CLI登录态
  本地安装Azure CLI后执行az login，登录已被授予Kusto访问权限的账号，SDK直接调用WithAzCli()方法初始化连接即可，示例代码：

  var kcsb = new KustoConnectionStringBuilder("你的Kusto集群连接地址")
      .WithAzCli();
  using var queryProvider = KustoClientFactory.CreateCslQueryProvider(kcsb);
  

• 方案2：复用IDE内置登录态
  如果你使用Visual Studio/VS Code/Rider开发，且已经在IDE内置的Azure服务登录入口完成账号登录，可直接调用WithVisualStudio()/WithVisualStudioCode()对应方法，SDK会自动复用IDE的登录凭据完成认证，无需额外操作。
• 方案3：交互式登录认证
  直接调用WithAadUserPromptAuthentication()方法，程序启动时会弹出微软登录窗口，完成账号授权后即可访问，适合没有安装Azure CLI、也没有配置IDE Azure登录的场景。

不要尝试在本地环境强行使用托管标识接口，所有本地模拟托管标识的方案本质都是通过环境变量注入服务主体凭据，和你当前使用的应用密钥认证逻辑没有区别，没有额外价值。
托管标识的权限分配只需要在Kusto集群侧给对应托管标识的服务主体授予对应权限即可，和个人用户账号的权限体系完全独立，不需要给个人账号绑定任何托管标识相关的角色。

内容的提问来源于stack exchange，提问作者Christine Han