Deployment stacks don't carry the Resource Management Private Link origin: App Configuration keyValues writes to a private store fail with Forbidden (plain deployments succeed)

Đang mở
  • Có gì không ổn?
#266 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
azure
Lĩnh vực
cloud

Hướng nghiên cứu

Start by tracing the resource write path for az stack group create and az stack sub create, then compare how it propagates request origin with plain deployment writes. The issue provides Bicep templates and correlation IDs for both failing stack shapes, but no repository files or tests to start from. Done means stack writes preserve the Resource Management Private Link origin so App Configuration key-value writes succeed against a private store.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Describe the bug

App Configuration's ARM dataPlaneProxy.privateLinkDelegation: 'Enabled' lets an ARM deployment write Microsoft.AppConfiguration/configurationStores/keyValues into a store with publicNetworkAccess: 'Disabled', as long as the deployment request reached ARM over a Resource Management Private Link (RMPL).

This works for a plain deployment (az deployment group/sub create). It does not work for a deployment stack (az stack group/sub create) sent from the same client over the same private link. Every key-value write in the stack fails with Forbidden. It looks like the stack's resource writes reach the App Configuration RP as public ARM traffic and do not carry the private-link origin of the request that created the stack.

To Reproduce

Setup:

  • A Resource Management Private Link, its Private Link Association at the tenant root management group, and a private endpoint (groupId: ResourceManagement) with privatelink.azure.com resolving management.azure.com to the endpoint's private IP.
  • A client inside that VNet. We used a VNet-injected GitHub-hosted runner, and the ARM activity log shows the caller IP is the private address.
  • An App Configuration store (Standard) with publicNetworkAccess: 'Disabled', disableLocalAuth: true, and dataPlaneProxy: { authenticationMode: 'Pass-through', privateLinkDelegation: 'Enabled' }. The deploying principal holds App Configuration Data Owner on it.

Template (kv.bicep):

param storeName string
param key string

resource store 'Microsoft.AppConfiguration/configurationStores@2025-06-01-preview' existing = {
  name: storeName
}

resource kv 'Microsoft.AppConfiguration/configurationStores/keyValues@2025-06-01-preview' = {
  parent: store
  name: key
  properties: { value: 'rmpl-probe' }
}

sub.bicep is a subscription-scope wrapper that calls kv.bicep as a module scoped to the store's resource group. nested.bicep is a resource-group template that calls kv.bicep as a module.

We sent five shapes from the same runner, in the same job, against the same store:

# Shape Command Result
1 RG deployment az deployment group create -f kv.bicep ✅ written
2 RG deployment, nested module az deployment group create -f nested.bicep ✅ written
3 Sub deployment → RG module az deployment sub create -f sub.bicep ✅ written
4 RG stack az stack group create -f kv.bicep --action-on-unmanage detachAll --deny-settings-mode none ❌ Forbidden
5 Sub stack → RG module az stack sub create -f sub.bicep --action-on-unmanage detachAll --deny-settings-mode none ❌ Forbidden

Error on the key-value resource in 4 and 5:

"code": "Forbidden",
"message": "Access to the requested resource is forbidden. See https://aka.ms/appconfig/DeploymentTroubleshooting for information on permissions and authentication settings in deployment scenarios."

The template, principal, store and network path are the same for all five. The only difference is deployment vs. deployment stack.

In an earlier run of the real workload, the activity log recorded the stack's own PUT from the runner's private address (10.x), while the store refused the key-value writes from a public Azure address. So the private origin is lost between the stack and the resource writes it fans out.

Expected behavior

A deployment stack created over a Resource Management Private Link writes App Configuration key-values into a private store, just as a plain deployment does from the same client.

Server Debugging Information

Shape Correlation ID Timestamp (UTC)
4: RG stack da31696b-85e9-4078-9600-4f72e5ac0610 2026-11-04 15:32:18
5: Sub stack 00946672-971b-43f1-979c-96f1b139f54b (operation bec23e19-648e-40c7-948a-af4320a22b34) 2026-11-04 15:34:38

Data center: Germany West Central. Tenant and subscription IDs are available privately on request.

Additional context

  • Because of this, any workload that deploys App Configuration key-values through stacks has to switch the store's publicNetworkAccess to Enabled for the length of the deploy, which is the exposure privateLinkDelegation was meant to remove.
  • Related: Azure/AppConfiguration#698 (the ARM private access feature), Azure/AppConfiguration#804.
  • We found no other workaround: @onlyIfNotExists, existingResource() and @retryOn (Bicep v0.48.1) don't change the origin of the request.
Ngôn ngữ chính
Bicep
Star
103
Fork
13
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Azure/deployment-stacks

Tất cả issue của Azure/deployment-stacks

Issue tương tự

Thêm issue về Cloud

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.