基于Azure DevOps构建Docker镜像时安全注入.NET配置的最佳实践

针对你提出的「构建阶段安全注入包含密钥的appsettings配置、避免代码库存配置、规避--build-arg安全风险」需求，以下分两种场景给出落地方案，短期优先基于Azure DevOps变量实现，同时支持扩展到Azure Key Vault。

核心思路说明 #

拒绝使用--build-arg传递敏感数据（该参数会留存于镜像构建历史，可通过docker history读取），改为在Azure DevOps Pipeline中直接生成对应环境的appsettings.{env}.json文件，再将文件打包进镜像。敏感数据全程通过Azure DevOps保密变量/Key Vault管控，不会暴露在构建链路的公开环节。

场景1：无Azure Key Vault，基于Azure DevOps保密变量实现 #

1. 修改Dockerfile #

调整镜像构建逻辑，确保对应环境的配置文件能被拷贝到运行时目录：

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build-env
WORKDIR /app
EXPOSE 80
EXPOSE 443

COPY *.csproj ./
RUN dotnet restore

COPY . ./
RUN dotnet publish -c Release -o out

# 构建运行时镜像
FROM mcr.microsoft.com/dotnet/aspnet:8.0
ARG ASPNETCORE_ENVIRONMENT=Production
ENV ASPNETCORE_ENVIRONMENT=${ASPNETCORE_ENVIRONMENT}

WORKDIR /app
# 拷贝编译后的应用程序
COPY --from=build-env /app/out .
# 拷贝对应环境的配置文件
COPY appsettings.${ASPNETCORE_ENVIRONMENT}.json .
ENTRYPOINT ["dotnet", "API.dll"]

2. 调整Azure DevOps Pipeline #

添加配置文件生成步骤，利用Azure DevOps保密变量填充敏感字段：

trigger: none

pool:
  vmImage: 'ubuntu-latest'

variables:
  # 定义构建环境，可根据分支/触发条件动态设置（比如prod分支设为Production）
  - name: target_environment
    value: 'Development'
  # 保密变量需在Azure DevOps项目的「库-变量组」中创建并标记为保密
  # 示例变量：DefaultConnection、ApiKey

steps:
- bash: |
    # 生成对应环境的appsettings文件
    cat > appsettings.$(target_environment).json << EOF
    {
      "ConnectionStrings": {
        "DefaultConnection": "$(DefaultConnection)"
      },
      "ApiSettings": {
        "ApiKey": "$(ApiKey)"
      },
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      }
    }
    EOF
  displayName: '生成环境专属配置文件'
  # 保密变量自动注入，无需额外显式传递

- task: Docker@2
  displayName: '登录镜像仓库'
  inputs:
    containerRegistry: 'docker_registry'
    command: login

- task: Docker@2
  displayName: '构建镜像'
  inputs:
    containerRegistry: 'docker_registry'
    repository: web/api
    command: build
    tags: |
      latest
      $(target_environment)-$(Build.BuildId) # 给不同环境打差异化标签，便于管控
    arguments: '--build-arg ASPNETCORE_ENVIRONMENT=$(target_environment)'

- task: Docker@2
  displayName: '推送镜像'
  inputs:
    containerRegistry: 'docker_registry'
    repository: web/api
    command: push
    tags: |
      latest
      $(target_environment)-$(Build.BuildId)

场景2：集成Azure Key Vault实现密钥管控 #

当密钥数量较多或需要更严格的权限管控时，直接从Azure Key Vault拉取敏感数据生成配置文件：

1. 前置准备 #

• 在Azure DevOps中创建Azure服务连接，关联有权限访问Key Vault的服务主体
• 在Azure Key Vault中创建所需的秘密（比如DefaultConnection、ApiKey）

2. 调整Azure DevOps Pipeline #

添加Key Vault拉取步骤，其余Dockerfile和构建逻辑与场景1一致：

trigger: none

pool:
  vmImage: 'ubuntu-latest'

variables:
  - name: target_environment
    value: 'Production'
  - name: azure_subscription
    value: '你的Azure服务连接名称'
  - name: key_vault_name
    value: '你的Key Vault名称'

steps:
- task: AzureKeyVault@2
  displayName: '从Key Vault拉取密钥'
  inputs:
    azureSubscription: '$(azure_subscription)'
    KeyVaultName: '$(key_vault_name)'
    SecretsFilter: 'DefaultConnection,ApiKey' # 指定需要拉取的秘密名称，用逗号分隔
    RunAsPreJob: false

- bash: |
    cat > appsettings.$(target_environment).json << EOF
    {
      "ConnectionStrings": {
        "DefaultConnection": "$(DefaultConnection)"
      },
      "ApiSettings": {
        "ApiKey": "$(ApiKey)"
      },
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      }
    }
    EOF
  displayName: '基于Key Vault密钥生成配置文件'

# 后续Docker登录、构建、推送步骤与场景1完全一致
- task: Docker@2
  displayName: '登录镜像仓库'
  inputs:
    containerRegistry: 'docker_registry'
    command: login

- task: Docker@2
  displayName: '构建镜像'
  inputs:
    containerRegistry: 'docker_registry'
    repository: web/api
    command: build
    tags: |
      latest
      $(target_environment)-$(Build.BuildId)
    arguments: '--build-arg ASPNETCORE_ENVIRONMENT=$(target_environment)'

- task: Docker@2
  displayName: '推送镜像'
  inputs:
    containerRegistry: 'docker_registry'
    repository: web/api
    command: push
    tags: |
      latest
      $(target_environment)-$(Build.BuildId)

关键优势 #

1. 安全可控：敏感数据全程通过Azure DevOps保密变量/Key Vault管控，不会出现在镜像构建历史或公开参数中
2. 强管控能力：构建阶段完成配置注入，不同环境的镜像打差异化标签，避免部署时配置混用
3. 扩展性强：从Azure DevOps变量切换到Key Vault仅需调整Pipeline步骤，Dockerfile无需修改

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