为客户提供访问Azure容器注册表的方法

33次阅读

问题描述

正在使用Azure容器注册表存储私有Docker镜像，并希望让约500个客户能够拉取这些镜像，并使用Docker V2 HTTP API读取元数据。用户考虑使用Service Principal来实现这个需求。他的计划是创建一个单独的Service Principal，并为每个客户创建一个具有时限的密码凭证。客户的操作流程大致如下：
1. 使用Service Principal客户端密钥进行身份验证，获取Azure AD访问令牌。
2. 访问Azure容器注册表OAuth令牌端点，将AAD访问令牌交换为ACR访问令牌和刷新令牌。
3. 使用ACR刷新令牌作为密码，使用docker login进行登录。
4. 使用ACR令牌访问ACR的HTTP API。

这些步骤不是手动进行的，而是通过运行在客户服务器上的自动脚本来完成。尽管经过深入研究（微软的文档在这方面不太明确），这种方法似乎按预期运行，用户仍然想知道是否使用Service Principal是”惯常”方法，以及为每个客户创建一个单独的Service Principal是否有好处。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

使用单一Service Principal和多个密码

在Azure中，使用单一Service Principal和为每个客户创建多个密码凭证是实现此目标的一种方式。这种方法的优势在于配置相对简单，不需要为每个客户单独创建Service Principal。以下是基本步骤：

创建一个Service Principal：在Azure门户中创建一个Service Principal，并为其分配适当的权限（如AcrPull角色）。
为每个客户创建密码凭证：为每个客户生成一个短暂的密码凭证，并将其分发给客户。
编写自动化脚本：编写脚本，使客户能够自动进行上述步骤，包括获取Azure AD访问令牌、交换为ACR访问令牌和刷新令牌，以及使用docker login进行登录。

但是，这种方法也有一些劣势。Azure的资源日志无法提供关于谁拉取了镜像的详细信息，因为所有客户共用一个Service Principal。这可能在某些监管和法规情况下引发问题。此外，如果Microsoft对Service Principal的每秒验证次数或密码数量有限制，可能会出现限制性问题。

为每个客户创建独立的Service Principal

另一种方法是为每个客户创建独立的Service Principal。这样做的优势在于能够更好地追踪每个客户的操作，因为Azure的资源日志会显示谁拉取了哪些镜像。这种方法更具可审计性，如果某个客户的机器遭受入侵并导致镜像泄漏，可以追踪到具体责任人。以下是基本步骤：

为每个客户创建Service Principal：为每个客户创建一个独立的Service Principal，并为其分配适当的权限（如AcrPull角色）。
编写自动化脚本：编写脚本，使客户能够自动进行上述步骤，包括获取Azure AD访问令牌、交换为ACR访问令牌和刷新令牌，以及使用docker login进行登录。还需要编写脚本来管理Service Principal的创建和维护，以便随着客户的加入和离开进行相应的操作。

然而，这种方法也会增加管理复杂性，需要确保自动化脚本能够正确地创建和维护每个客户的Service Principal，以及及时清理不再需要的凭证。