Azure-docs: 托管服务身份

@tvperez76感谢您的反馈！ 我们目前正在调查中，会尽快为您更新。

基于以下 Microsoft Doc Service Fabric 的@tvperez76未列为受支持：

https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/overview

@srrengar你能确认一下吗？

我相信是这样，但我正在添加@dkkapur以确保

此外，Service Fabric 在 VMSS 上运行，您应该能够根据此https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/qs将 MSI 添加到现有的 VMSS

很确定@srrengar是对的！

感谢@srrengar和@dkkapur！ 很好的一点是，由于 Service Fabric 在 VMSS 上运行，因此它应该可以正常工作。

@tvperez76您应该能够在服务结构上使用 MSI。 建议按照此处的步骤启用它。

我将关闭它，但如果您觉得需要更多讨论，请告诉我，我们可以重新打开并继续。

伟大的。 然而，这只回答了我的一半问题。 是否可以让 MSI 在 Service Fabric 上托管的容器上工作？ 如果是这样，激活此功能的必要步骤是什么？ 文档将真正帮助早期采用者。 谢谢你。

@tvperez76是的，使其工作背后的逻辑与 VMSS 中使用的相同。 因此，该文档是我们能够提供的参考。 目前，我们没有任何专门针对服务结构的特定文档。

因此，在创建 SF 集群后，您需要做的就是导航到门户中的虚拟机规模集，选择创建 SF 时创建的规模集，在配置下，您将看到可以启用 MSI：

@tvperez76啊，是的 - 抱歉，我错过了原始问题的那部分。 让我们就在 Windows Containers 中启用此功能与您联系！

我的预感是它应该是可能的，因为如果容器映像中的操作系统/其他进程支持 MSI（我认为是这种情况），我们作为 Service Fabric 应该不知道它并且它应该可以工作。

标记@srrengar和@RajeetN以在此处跟进。

谢谢@dkkapur。 我已将@srrengar和@RajeetN与我一起分配到此问题，以便他们可以轻松跟踪它。

你好，

我想知道这个问题是否有任何跟进，因为我也在尝试解决同样的问题。

感谢您联系@jeeshnair我正在离线工作以解决这个问题。 很快就会更新你。

@jeeshnair普遍的共识是，如果 MSI 在 Windows 容器上工作，那么它应该在 Service Fabric 中工作。 至于在 Windows 容器上安装 MSI，我认为它与正常安装没有什么不同。 访问容器并安装包。

@MicahMcKittrick-MSFT，感谢您的迅速回应。 我的团队成员中很少有人注意到无法从容器访问 VM 扩展或 IMDS 端点。 他们已经实施了一个 MSIAccess 代理来解决。 您的意思是 MSI 应该可以正常从容器访问，不需要什么特别的。 正确的？

只是要清楚 MSI = 托管服务标识

@jeeshnair根据我的知识，我不知道有任何额外的设置。 但是，我没有找到任何有关在容器中运行 MSI 的实际文档，因此需要进行一些测试才能 100% 确认

您多久可以提供测试结果？ 我也在做一些并行测试，可以向您更新我的发现。

@jeeshnair 老实说，我对 MSI 并不太熟悉，所以我不确定我是否是全面测试场景的最佳人选。 实际上，我建议您联系 Stack Overflow 上的开发人员社区，看看是否有其他人在 Service Fabric 上完成了这项工作。 这有点超出了我们的文档注释的范围。

我们已经抄送了 @srrengar和@dkkapur ，因此他们知道围绕此问题的询问和内容。 然而，目前还没有大量要求将 MSI 与服务结构一起使用，因此就起草内容而言，它不会很快出现。

如果您愿意，可以在 Stack Overflow 上发布此问题并在此处分享链接。 这样我们就可以跟踪它并在我们可以帮助的地方提供帮助。 就本文档的具体操作而言，没有实际问题，我们目前不会将 MSI 信息添加到此特定文档中。 因此，我将关闭此问题，因为此时不需要对文档进行任何操作。

谢谢@MicahMcKittrick-MSFT。 与引入 MSI 的原因相同，具有服务结构的 MSI 是一个关键场景。 所以我很惊讶你觉得这不是一个很大的要求。 如果容器必须在不存储机密的情况下访问密钥库，那么 MSI 是唯一的出路。

顺便说一下，我测试过，似乎调用 IMDS 端点因超时而失败。 很明显，这里有一些东西是缺失的。 我只想知道是否支持 MSI，如果不支持，我们什么时候可以得到全面支持。
[“发送请求时出错。操作超时\n\n发送请求时出错。”]

@jeeshnair ，澄清@MicahMcKittrick-MSFT 意味着这不是 Service Fabric 本身的问题。 IMDS 端点地址是否添加到容器内的路由，以便地址可路由？

感谢您澄清@RajeetN。

我做了一些额外的研究，似乎有可能：

https://stackoverflow.com/questions/40345712/install-an-msi-into-azure-service-fabric-node
https://social.msdn.microsoft.com/Forums/en-US/8a6d9437-4fd1-410f-9b43-46741c85142b/possible-to-install-msi-packages-in-service-fabric

所以是的，它应该可以工作，但不确定此时它是否被认为是“可支持的”。

对于完整的产品集成，我还建议将其添加到
用户语音

@RajeetN可以确认这一点，我们当然可以重新打开，Rajeet 可以将其添加到积压中

堆栈溢出线程谈论 MSI 安装程序不是托管服务
身份 。 完全不同的东西，毫无关联。

在星期四，2018年6月7日在下午6时22米卡[email protected]写道：

感谢您澄清@RajeetN https://github.com/RajeetN 。

我做了一些额外的研究，似乎有可能：

https://stackoverflow.com/questions/40345712/install-an-msi-into-azure-service-fabric-node

https://social.msdn.microsoft.com/Forums/en-US/8a6d9437-4fd1-410f-9b43-46741c85142b/possible-to-install-msi-packages-in-service-fabric

所以是的，它应该可以工作，但不确定它是否被认为是“可支持的”
时间点。

对于完整的产品集成，我还建议将其添加到
UserVoice https://feedback.azure.com/forums/34192--general-feedback

@RajeetN https://github.com/RajeetN可以确认这一点，我们
课程可以重新打开，Rajeet 可以将其添加到积压中

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/MicrosoftDocs/azure-docs/issues/6500#issuecomment-395616001 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AkbrcCy8PmIY9kydT40kXmDobISN_k-_ks5t6dHfgaJpZM4TBMMa
.

@RajeetN ，我该如何做下面的事情，有什么说明/文档可以指给我看吗？
“IMDS 端点地址是否添加到容器内的路由，以便地址可路由？”

什么是 IMDS 端点地址？

我的印象是 69.254.169.254 应该可以从容器中调用。

干得好。 这是 VM 上的不可路由 ip，我可以确认我可以到达此端点并从 VM 获取访问令牌。 不是来自容器
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

没错，这就是我的意思。 169.* 不可路由。 在容器内执行“route add 169.254.169.0/24 172.22.160.1”以使地址可路由。

我可以尝试向您更新我的发现

谢谢@jeeshnair。 作为仅供参考，我正在与 Service Fabric 团队和容器团队一起离线工作，看看我们是否能搞定这一切。 从那里我想获得一些围绕该主题创建的文档。 可能需要几天时间才能完全解决，但想让您知道我正在积极调查它:)

@jeeshnair我与 Windows Containers 团队和 MSI 团队离线合作，并确认可以从 Windows Container 中运行 MSI。 @RajeetN的最后一个建议似乎是正确的，你需要做什么才能让它工作。

此外，容器团队现在正在努力创建用于在容器中运行 MSI 的内容。 看到传入的请求数量，他们提高了创建时间的优先级。 我没有关于何时可用的确切预计到达时间，但知道他们现在正在处理该内容，我们确实计划将其公开。

让我知道是否还有其他需要帮助的地方。

谢谢弥迦。 我仍在尝试添加路由。 我会
本周报告我的发现，我们可以在此之前保持问题开放吗？
谢谢

在Sun，2018年6月10日在上午08时57分弥[email protected]写道：

@jeeshnair https://github.com/jeeshnair我使用 Windows
Containers 团队和 MSI 团队下线并确认可以
从 Windows 容器中运行 MSI。 @RajeetN 的最后一个建议
https://github.com/RajeetN在您需要做的事情上似乎是正确的
为了让它工作。

此外，容器团队现在正在努力为以下内容创建内容
在容器中运行 MSI。 看到他们有的数量请求
提高了创建时间的优先级。 我没有确切的预计到达时间
可用，但确实知道他们现在正在处理该内容，我们
确实计划将其公开。

让我知道是否还有其他需要帮助的地方。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/MicrosoftDocs/azure-docs/issues/6500#issuecomment-396060045 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AkbrcPT_rVUxJ9mKOFpd5oVuhgw6Vytwks5t7UIBgaJpZM4TBMMa
.

可以做 ：）

哎呀不小心关闭了。 对不起 ：）

我希望您创建的文档也适用于非 Azure 托管的本地 Service Fabric 群集。

谢谢@BuddhaBuddy1我会转发这些信息。

@jeeshnair有更新吗？

@MicahMcKittrick-MSFT ，路由添加有效。 但是，开箱即用的 AzureServiceProviderClass 在容器中不起作用，并且会因以下异常而失败。 我也很想知道当地的开发箱故事。

“参数：连接字符串：[未指定连接字符串]，资源： https : https ://login.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47 https://vault.azure.net ，管理局： https：//开头登录。 windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47。异常消息：尝试使用托管服务标识获取令牌。无法连接到托管服务标识 (MSI) 端点。请检查您是否在 Azure 资源上运行有 MSI 设置。\r\n参数：连接字符串：[未指定连接字符串]，资源： https ://vault.azure.net，权限： https ://login.windows.net/72f988bf-86f1-41af-91ab- https://vault.azure.net ，管理局： https：//开头登录。 windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47。 异常消息：尝试使用 Azure CLI 获取令牌。 无法获取访问令牌。 'az' 未被识别为内部或外部命令、\r\n可运行的程序或批处理文件。\r\n\r\n \n\n无法在 Microsoft.Azure.Services.AppAuthentication 检索证书\n\n .AzureServiceTokenProvider。d__14.MoveNext()\r\n--- 堆栈跟踪结束

我认为 Azureserviceprovider 需要设置一些环境变量，这些变量在 VM 中而不是在容器中提供。

感谢@jeeshnair 的更新。 我看看我这边是否有人有任何建议。

要使其无缝工作，还有一个问题需要解决。 似乎 AzureServiceProvider 类使用 MSI_ENDPOINT 和 MSI_SECRET 环境变量来获取 MSI 令牌。 我可以设置 MSI_ENDPOINT ，什么秘密？ 现在 Azureserviceprovider 无法获取 MSI 令牌。 我可以通过发出 http 请求来明确获取它。

Microsoft.Azure.KeyVault.KeyVaultClient
参数：的connectionString：无连接字符串指定]来源： https://vault.azure.net ，管理局： https：//开头LO
gin.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47。 异常消息：尝试了以下 3 种方法来获取访问权限
令牌，但它们都不起作用。
参数：的connectionString：无连接字符串指定]来源： https://vault.azure.net ，管理局： https：//开头LO
gin.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47。 异常消息：尝试使用托管服务标识获取令牌
泰。 无法连接到托管服务标识 (MSI) 端点。 请检查您是否在 Azure 资源库上运行
具有 MSI 设置的源。
参数：的connectionString：无连接字符串指定]来源： https://vault.azure.net ，管理局： https：//开头LO
gin.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47。 异常消息：尝试使用 Visual Studio 获取令牌。 使用权
无法获取令牌。 在“C:\Users\ContainerAdministrator\AppData\Loc”中找不到 Visual Studio 令牌提供程序文件
al.IdentityService\AzureServiceAuth\tokenprovider.json"
参数：的connectionString：无连接字符串指定]来源： https://vault.azure.net ，管理局： https：//开头LO
gin.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47。 异常消息：尝试使用 Azure CLI 获取令牌。 访问令牌
n 无法获得。 'az' 不被识别为内部或外部命令，
可运行的程序或批处理文件。

谢谢@jeeshnair。 我在内部转发了此信息，正在查看是否可以为您提供建议。

@tvperez76我听到的几件事：

如果您在本地机器上使用 SF，那么 MSI 将不会工作。 它仅适用于运行 Azure 的资源。 我不确定这是否适用于您的情况，但这是我得到的一些反馈。

AzureServiceProvidor 类从何而来？ 我在网上找不到太多参考这个。 假定这个类不起作用，因为它正在集群本身内寻找项目。

您可以在此处找到有关 AzureServiceTokenProvider 的文档。 此类位于Microsoft.Azure.Services.AppAuthentication Nuget 中。

这是在 MSI 不可用的本地机器上使用 AzureServiceTokenProvider 的方法：
https://stackoverflow.com/questions/49859477/access-key-vault-from-local-service-fabric-cluster-with-msi

使用 IMDS，请确保您使用的是Microsoft.Azure.Services.AppAuthentication Nuget 的最新版本 1.0.3。 该版本使用 IMDS。 使用 VM 扩展的早期版本。

@jeeshnair 对此有任何更新吗？

@jeeshnair
我将暂时关闭它。 如果您需要其他帮助，请告诉我，我们可以重新打开并继续。

@MicahMcKittrick-MSFT

我正在尝试类似的东西......我能够从 python 应用程序中执行一些 CRUD 操作，该应用程序使用 MSI 从 azure 存储中请求文件（效果很好！）。 我需要证明相同但在 docker 容器中拥有该 python 应用程序。 我为 IP 路由尝试了@RajeetN方法，但没有运气。 我总是收到关于尝试连接到 169.254.169.254 的错误。 我们丢失了需要与 azure storage / keyvalut / azure sql 通信的组件。 我们很想使用 MSI，但其中大部分组件都是容器化的 (docker)。

对此的任何帮助将不胜感激 =)

我昨天再次与产品组接触，因为route add对我不起作用。

为什么这个问题关闭？ 它显然不起作用。

@rhummelmose - 许多构建 VM 的时间都为我们带来了这些信息：检查我的 StackOverflow How To post
我猜关键是容器内部网关地址的动态确定。

对于基于 .NET 核心的图像（例如 microsoft/dotnet:2.1-aspnetcore-runtime），由于权限不足，路由添加解决方法不起作用（路由添加产生“请求的操作需要提升。”）。 也许我遗漏了一些东西 - 有没有人有幸通过 .NET 核心映像到达 169.254 端点？ 我一直在使用 Docker 版本 18.09.0，构建 33a45cd0a2 进行测试。

我想通了，并能够使用以下内容在我的 Dockerfile 中添加一个永久路由：
USER ContainerAdministrator RUN route -p add 169.254.169.0 mask 255.255.255.0 0.0.0.0 USER ContainerUser ENTRYPOINT ["dotnet", "myapp.dll"]

使用您的方法，我还可以添加路由，但对元数据端点的请求不起作用。
我想通了， USER ContainerAdministrator权前的CMD将帮助入门脚本运行升高。

文件

# escape=`

# --------------------------------------------------------------------------------
# PowerShell
FROM mcr.microsoft.com/powershell:nanoserver as ps

# --------------------------------------------------------------------------------
# Runtime image
FROM microsoft/dotnet:2.1.6-aspnetcore-runtime-nanoserver-1803

COPY --from=ps ["C:\\Program Files\\PowerShell", "C:\\PowerShell"]

ADD entry.PS1 C:\\entry.PS1

USER ContainerAdministrator
CMD ["C:\\PowerShell\\pwsh.exe","C:\\entry.PS1"]

入口.PS1

Write-Host "adding route for Managed Service Identity"
$gateway = (route print | ?{$_ -like "*0.0.0.0*0.0.0.0*"} | %{$_ -split " "} | ?{$_.trim() -ne "" } | ?{$_ -ne "0.0.0.0" })[0]
$arguments = 'add','169.254.169.0','mask','255.255.255.0',$gateway
&'route' $arguments

$response = Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net%2F' -Method GET -Headers @{Metadata="true"} -UseBasicParsing
Write-Host "MSI StatusCode :" $response.StatusCode

感谢您试用。 你对我的路线不起作用是正确的。 事实证明，这是我所做的另一个改变，导致事情发生。 当我在容器内添加一个持久路由时，该持久路由出人意料地添加到主机路由表中，然后可供现有和随后创建的容器使用，以便它们突然能够到达 IMDS 端点。
见20190104-demo-sanitized.txt

刚遇到这个问题……有什么解决方法？ 还是还没有解决？

@TheReaLee您尝试了上述哪种方法（@chanes-cds 或我），问题在您的最终表现如何？

我试过@chanes-cds 建议：

用户容器管理员
运行路由 -p 添加 169.254.169.0 掩码 255.255.255.0 0.0.0.0
用户容器用户
入口点 ["dotnet", "myapp.dll"]```

@TheReaLee我成功地运行了我的方法（参见上面 1 月 4 日的帖子）数月。 恕我直言，路由需要放在容器启动/进入而不是容器构建上。