[Feature request] Per label security

[SirElTomato]

Allow users to edit configs for some labels but not others. e.g. only a certain role can edit config with the 'production' label

[drago-draganov]

@SirElTomato

Thanks for the request. We are very interested and indeed looking at this (and similar category scenarios) going forward. Though, there isn't yet a solid ETA I can provide at the moment.

[SirElTomato]

Thanks @drago-draganov, I'll keep up to date with the new features. In the meantime I will have a separate Azure App Config store for production.

[drago-draganov]

Isolating production config store is always recommended, regardless of authorization. It allows for network level security (aka PrivateLink), low latency (with deployment closest to your services), dedicated quota, etc.

[vermegi]

It would also be nice to have 'read' permissions on a per label basis. Currently I have a customer who has a lot of applications, a lot of config and a lot of environments. They are ok with splitting up app config for their production environment (they have 10 of these where they promote an app 10 times between environments and they have even more non-production environments).
They need apps to not necessarily have access to each others config. If they need to do this with separate stores, this would mean a huge cost impact for them. Separating on a per environment basis makes sense for them, but within an environment, they would like to apply RBAC on labels on a per application basis.

[krukowskid]

Adding per-prefix or even per-entry security would be a game changer. Especially when we're talking about write permissions. This could make Azure App Configuration seriously compete with other 3rd party/in-house solutions, not just as a central configuration tool, but also as a feature flags provider.
@zhenlan Is there a chance that this feature will be moved at least to "planned" this year?

[drago-draganov]

A couple of work items that aim to help with these concerns are already in development. These include scoped access and different pricing tiers. All planned this year.

With that said, total security control is only possible via resource isolation (recommended). Many security features, like private endpoints, network security perimeters, customer managed keys, etc. are only available at resource level.

[rrussell0]

This was one of the most shocking things to discover about app configuration - it's advertised as a 'central store' yet if you want to do that you have to either completely block or open access to developers. Having to swap the application configuration endpoint between environments seems to basically defeat the purpose to me. We don't have any interest in the security features you mentioned other than more finely grained access control.

[DavidPriceNBS]

Very interested in this as well, currently being unable to restrict access per label for me makes the label feature not quite redundant but I guess nothing more than a metadata functionality, we have our AKS setup with AzureAppConfigurationProvider configured to only pull specific labels but from a security perspective in theory the Managed Identity could pull any of the values.

[JasonRodman]

Any news on this? The whole selling point was to have a central place to manage these configurations, but without granular security, it's not a viable option for us. One developer mistake can take down dozens of applications for us, yet there are environments we want them to manage on their own. At least a rough ETA would help us plan for this.

[drago-draganov]

I'm sorry for the late reply.

We are actively working on adding support for Attribute Based Access Control (ABAC) for Azure AppConfiguration Data Plane, in addition to the already existing Role Based Access Control (RBAC). That would enable more granular scope initially for read requests (authorization on specific request filters).
ETA - we are looking at before 6/25.

The concept of centralized configuration is to provide common/related settings, serving different sub-systems or parts of a solution. For fully independent/isolated Apps or for environments with different security requirements (dev, stage, prod, etc.), we recommend resource isolation. It provides the best security control and regionality. Many Azure platform security features are only supported on resource level. Note that resource isolation is also recommended by Azure KeyVault.

A new, value-oriented Dev sku is also coming up early this year.

It's also worth mentioning that AppConfiguration Snapshots can help to mitigate the risk of unexpected config changes in prod.

Thanks for all the feedback! Much appreciated.