如何在GitLab CI中使用托管身份认证将GitLab Registry的Docker镜像推送至Azure App Service？附配置方法、安全风险及替代方案咨询

阿华AIGC实验室

2026-4-28

解答：从GitLab CI推送镜像至Azure App Service的身份认证与流程问题

我来帮你一步步拆解这个问题，每个疑问都给你讲明白：

1. 具体实现推送流程

这里推荐采用「GitLab Registry → Azure容器注册表（ACR）→ Azure App Service」的中转方案（更符合Azure生态的安全最佳实践），结合托管身份（MI）完成认证，具体步骤如下：

步骤1：准备Azure用户分配式托管身份

先创建一个用户分配式MI——GitLab托管的Runner无法使用系统分配式MI（系统分配MI绑定特定Azure资源，Runner不在Azure环境内无法调用其元数据服务）。

步骤2：GitLab CI变量配置

在项目的「CI/CD > 变量」中添加以下变量（全部设为「保护」+「掩码」状态）：

AZURE_CLIENT_ID：用户分配MI的客户端ID
AZURE_TENANT_ID：你的Azure租户ID
AZURE_SUBSCRIPTION_ID：目标Azure订阅ID
AZURE_ACR_NAME：你的ACR实例名称
AZURE_APP_SERVICE_NAME：目标App Service名称
AZURE_RESOURCE_GROUP：App Service所在资源组名称

步骤3：编写gitlab-ci.yml作业

deploy-to-azure:
  image: mcr.microsoft.com/azure-cli:latest
  stage: deploy
  only:
    - main # 按需调整触发分支/标签
  script:
    # 1. 用托管身份登录Azure
    - az login --identity --username $AZURE_CLIENT_ID
    # 2. 设置默认订阅
    - az account set --subscription $AZURE_SUBSCRIPTION_ID
    # 3. 拉取GitLab Registry中的目标镜像
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    # 4. 为镜像打ACR标签并推送
    - docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA $AZURE_ACR_NAME.azurecr.io/your-image:$CI_COMMIT_SHORT_SHA
    - az acr login --name $AZURE_ACR_NAME # 用MI身份自动登录ACR，无需密码
    - docker push $AZURE_ACR_NAME.azurecr.io/your-image:$CI_COMMIT_SHORT_SHA
    # 5. 部署镜像到App Service
    - az webapp config container set --name $AZURE_APP_SERVICE_NAME --resource-group $AZURE_RESOURCE_GROUP --docker-custom-image-name $AZURE_ACR_NAME.azurecr.io/your-image:$CI_COMMIT_SHORT_SHA --docker-registry-server-url https://$AZURE_ACR_NAME.azurecr.io

如果不想用ACR中转，直接让App Service拉取GitLab镜像：需要在App Service容器设置中配置GitLab个人访问令牌（PAT），但这种方式无法用到MI，安全性远不如中转方案。

2. Azure App Service的身份与访问控制配置

核心是给用户分配式MI授予最小权限，避免过度授权：

给MI添加App Service Contributor角色：作用域设为目标App Service所在的资源组（或仅App Service实例），允许MI修改App Service的容器配置。
给MI添加AcrPush角色：作用域设为目标ACR实例，允许MI推送镜像到ACR。
（可选）如果App Service需要从ACR拉取镜像，建议禁用ACR的「管理员用户」，同时给App Service的系统分配MI添加AcrPull角色，实现无密钥拉取。

注意：绝对不要给MI分配订阅级别的Contributor角色，严格遵循最小权限原则。

3. 该方案的安全风险

过度授权风险：如果给MI的权限过大（比如订阅级权限），一旦GitLab CI作业被攻击者接管，就能操作大量Azure资源。
Runner环境风险：如果是自托管Runner，且服务器未做好安全隔离，攻击者可能通过Runner获取MI的临时访问令牌，进而访问Azure资源。
镜像供应链风险：GitLab Registry中的镜像如果被篡改或包含恶意代码，推送部署后会直接影响App Service的安全性。
变量泄露风险：虽然GitLab的掩码变量能防止明文泄露，但如果CI作业日志配置不当，仍可能间接泄露敏感变量。

4. 更安全的替代方案？

az login --service-principal vs MI：服务主体需要存储客户端密钥/证书，一旦密钥泄露，攻击者可以直接用它登录Azure；而MI不需要存储任何密钥，令牌是通过Azure元数据服务临时获取的，安全性更高。所以MI比服务主体更安全，不建议替换。
最优方案：GitLab与Azure联邦身份认证：这是目前最安全的方式，不需要创建MI或服务主体，而是通过GitLab的OIDC身份提供商直接向Azure请求临时令牌，权限可以绑定到特定GitLab分支、项目甚至作业类型，完全避免了密钥管理的风险。配置时只需在Azure中创建「联邦身份凭据」，关联你的GitLab项目即可。
SSH是否可行？：SSH主要用于登录App Service容器实例进行调试，并不适合作为镜像推送/部署的认证方式，没法替代az login的作用，不推荐用在这个流程里。

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