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)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- azure
- Ambito
- cloud
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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) withprivatelink.azure.comresolvingmanagement.azure.comto 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, anddataPlaneProxy: { authenticationMode: 'Pass-through', privateLinkDelegation: 'Enabled' }. The deploying principal holdsApp Configuration Data Owneron 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
publicNetworkAccesstoEnabledfor the length of the deploy, which is the exposureprivateLinkDelegationwas 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.
- Lingua principale
- Bicep
- Stelle
- 103
- Fork
- 13
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Azure/deployment-stacks
-
Let customers ignore specific properties in stack what-if (similar to Terraform's ignore_changes)Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Azure/deployment-stacks#268 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Azure/deployment-stacks#267 ·
-
Stack what-if reports read-only alias fields on Microsoft.Network/dnsZones/A as Modify after the baselineForse già presa @dantedallag l’ha presa 6 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
Azure/deployment-stacks#265 · 1 commento · 1 assegnatario ·
-
deleteAll picks an unsupported deletion api-version per resource type (recurrence of #182/#198) - now Microsoft.Cdn ruleSets/rules rejects 2026-10-01Forse già presa @snarkywolverine l’ha presa 9 giorni fa. Apertadelete
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
Azure/deployment-stacks#264 · 8 commenti · 1 assegnatario ·
-
noise-reduction what-if
Difficoltà 4/5 3-5 giorni Idoneità per principianti 22/100
Azure/deployment-stacks#263 · 3 commenti ·
Tutte le issue di Azure/deployment-stacks
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
aws/aws-emulator#345 ·
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
bug dependencies python
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
awslabs/social-messaging-agent-runtime-toolkit#188 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
aws-powertools/powertools-lambda-python#8801 ·
I maintainer di solito rispondono entro 1 giorno