Azure
[Feature request] Per label security
Allow users to edit configs for some labels but not others. e.g. only a certain role can edit config with the 'production' label
@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.
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.
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.
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.
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?
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.
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.
