[Feature Request] Support setting key-values/feature flags in ARM/Bicep template with data-plane RBAC

[markbeij]

Adding values to an App Configuration Store apperently requires Access Keys to be enabled. Otherwise I get the error message "The operation cannot be performed because it requires local authentication to be enabled".

We don't want to enable this since we prefer to only grant access for AAD identities so we have audit trails.

Deployments of values should be possible without enabling local authentication (access keys) Not sure if this is a bug or a feature request though..

resource configStoreFeatureflag 'Microsoft.AppConfiguration/configurationStores/keyValues@2022-05-01' = [for ff in featureFlags : {
  parent: configStore  
  name: '.appconfig.featureflag~2F${ff.id}'
  properties: {
    value: string(ff)
    contentType: 'application/vnd.microsoft.appconfig.ff+json;charset=utf-8'
  }
}]

[jimmyca15]

This would be a feature request. It's not possible to do this with existing RBAC of Azure App Configuration today. This doc has details.

[libravado]

(Rightly or wrongly) I have been able to workaround this exact issue; to still achieve the level of automation I require... In my github pipeline , (I was already setup to kick off my bicep deployment which involved az login using my scm's service principal). So I just added another step after bicep deployment has completed, to call:

az appconfig kv set -n APPCONFIG_RESOURCE_NAME --key color --value blue --auth-mode login --yes

NB: The service principal is a member of an AD group that has Owner access in app config I'm fairly sure that az appconfig feature ... will work equally well.

Couple of annoying side effects:

• It means I may have to output values from bicep (which is not how I'd ideally like it to work, it unnecessarily exposes values to the pipeline)
• I dont like the idea that this means my scm principal can read App Config too. Ideally there'd by a write-only role :/

[sommkh]

Seems like a workaround that I had to find recently was injecting config app key values through powershell -

Set-AzAppConfigurationKeyValue -Endpoint $endpoint -Key $key -Value $value -Label $label -ContentType $contentType

It works without having to enable the local authentication after the resource is deployed. Works for both key-vale and key-vault reference. Not the cleanest workaround but at least it works. I saved the key value pairs in a config.json and read the values from there and injected into the app config through that command.

the az appconfig kv works as long as it is a key-value pair. If its a key vault reference, it needs to enable the access keys again at least for me.

[zhenlan]

the az appconfig kv works as long as it is a key-value pair. If its a key vault reference, it needs to enable the access keys again at least for me.

This is not expected. Can you please share an example of the az appconfig kv command that doesn't work for you for key vault references? Please make sure you pass --auth-mode login to the command and you are granted the App Configuration Data Owner role on the target App Configuration store.

[AndreasKahlroth]

Any progress on this issue yet?

[dozer75]

This would be a feature request. It's not possible to do this with existing RBAC of Azure App Configuration today. This doc has details.

It's funny that Microsofts employees (or contributors) states that things should be "feature requests" on issues that is caused by using the recommended usage by Microsoft. I quote from the same page:

Of these two types of authentication schemes, Microsoft Entra ID provides superior security and ease of use over access keys, and is recommended by Microsoft.

So this offers "ease of access", but is it "ease of access" when we can't deploy using scripts using RBAC?

This is not the first time Microsoft promotes RBAC, but has lousy support for it in various deployment tools forcing the users to still have access key based authentication active.

Would really like that this "feature request" could be solved soon as it is a quite big dealbreaker using script based deployments in secure environments.

[jimmyca15]

We just released the solution to this issue in a preview version of the Azure App Configuration stores API.

Docs are in the works!

What does it do?

There is now a setting on your configuration store that can be configured to enable data plane RBAC when deploying key-values via ARM templates. Assuming this setting is configured there are a few points to be considered.

• Access keys being disabled will no longer affect the deployment
• The user running the deployment MUST have appropriate data plane roles for the action they are performing (read/write)
  • Reference
  • This is on top of the already existing requirement to be a contributor on the configuration store resource.
• Audit logs will now appropriately contain deploying identity, rather than access key.

How to enable?

This preview API just rolled out so docs + UI + CLI support is still in progress. To enable it at this point in time, the configuration store management API would need to be used directly. The property is documented here. The appropriate configuration to achieve what I discussed here would be

API version: 2023-08-01-preview

{
    "properties": {
        "dataPlaneProxy": {
            "authenticationMode": "Pass-through"
        }
    }
}

API spec example

[vRune4]

The appropriate configuration to achieve what I discussed here would be

I assume "would be" means "soon"? (it didn't work an hour ago when I tested)

[hahahahahaiyiwen]

There is an issue detected on our side that blocks this feature for some customers at the moment. We are working on a fix and the ETA is by end of next week (03/22).

[jimmyca15]

@vrune4 "would be" did mean "now". If the attempt failed due to a server error then you are most likely affected by the issue that @hahahahahaiyiwen mentioned. If it failed due to some client error, such as 'invalid property', then let us know because that would be different.

[dozer75]

I also tried this using Bicep similar to the configuration below (our scripts are more complex, so this is just a boiler template of it after extracting it):

resource appCS 'Microsoft.AppConfiguration/configurationStores@2023-08-01-preview' = {
  name: name
  location: 'westeurope'
  sku: {
    name: 'Standard'
  }
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${managedIdentity.id}': {}
    }
  }
  properties: {
    disableLocalAuth: true
    createMode: 'Default'
    softDeleteRetentionInDays: 7
    publicNetworkAccess: 'Disabled'
    dataPlaneProxy: {
      authenticationMode: 'Pass-through'
      privateLinkDelegation: 'Enabled'
    }
  }
}

resource ownerRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, appCS.name, '<executing user id>', '<App configuration Data owner role id>')
  scope: appCS 
  properties: {
    principalId: '<executing user id>'
    principalType: 'User'
    roleDefinitionId: '<App configuration Data owner role id>'
  }
}

resource kv 'Microsoft.AppConfiguration/configurationStores/keyValues@2023-08-01-preview' = {
  name: 'TEST-Key'
  parent: appCS
  properties: {
    value: 'MOO'
  }
  dependsOn: [
    ownerRoleAssignment 
  ]
}

But it failed with the following error:

{
    "status": "Failed",
    "error": {
        "code": "InternalServerError",
        "message": "Cannot serve the request. Please retry.",
        "additionalInfo": [
            {
                "type": "ActivityId",
                "info": {
                    "activityId": "<GUID>"
                }
            }
        ]
    }
}

Important to note: We're using private endpoint here (That's why I used the privateLinkDelegation: 'Enabled' setting) . The deployer are on the same vnet as the private endpoint and the deployer do have access to the app configuration service using the private endpoint.

[jimmyca15]

@dozer75

That is the issue that Haiyi mentioned here.

[jimmyca15]

@dozer75

Important to note: We're using private endpoint here (That's why I used the privateLinkDelegation: 'Enabled' setting) . The deployer are on the same vnet as the private endpoint and the deployer do have access to the app configuration service using the private endpoint.

If the configuration store is locked down to a private endpoint, then you will need to have ARM private endpoint enabled on the subscription you are deploying to (docs in the works). Do you have this setup set up?

[dozer75]

@jimmyca15

That is the issue that Haiyi mentioned here.

Ok... So it is the same then (it was a bit unclear since you wrote invalid property and I got InternalServerError), but we'll wait and see when the fix is deployed!

If the configuration store is locked down to a private endpoint, then you will need to have [ARM private endpoint] (https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/create-private-link-access-portal) enabled on the subscription you are deploying to (docs in the works). Do you have this setup set up?

No, I didn't know, thanks for notifying me and I'll look at this when the other issue has been solved!

[hahahahahaiyiwen]

@dozer75 @vRune4 The fix has been deployed and the issue should be resolved now. Please give it a try and let us know if you have any questions!

[dozer75]

@hahahahahaiyiwen Sure, will take a look at it.

However, I read through the link you sent two weeks ago around the ARM private endpoint setup. But the problem with that is that it requires that things are done in the root management group which are impossible for me in this assignment to do as the owner denies any change outside of the subscription (which I find totally logic, but unfortunately not those who designed that functionality). I know that this isn't your doing with the private link for managing azure resources limits, but that is a blocker anyway for us to do this so I'll probably look at alternatives to do the configuration additions...

[hahahahahaiyiwen]

@dozer75 I think supporting private endpoint setup at a more granular level is in the roadmap of ARM. You may want to reach out to them to understand more about the timeline.

[dozer75]

@dozer75 I think supporting private endpoint setup at a more granular level is in the roadmap of ARM. You may want to reach out to them to understand more about the timeline.

I suspect that, but have a hard time find where to look :/

[hahahahahaiyiwen]

@dozer75 Unfortunately there is no public documentation about it. I asked internally, and ARM doesn't have an exact timeline. They suggest submitting a feature request in Azure Resource Manager Community.

[hahahahahaiyiwen]

Documentation and Azure portal UI support are now available :partying_face::partying_face:

[dozer75]

@dozer75 Unfortunately there is no public documentation about it. I asked internally, and ARM doesn't have an exact timeline. They suggest submitting a feature request in Azure Resource Manager Community.

A bit delayed due to other assignments, but here is the posted idea.