Allow remaining configuration to load when a key-vault reference fails to resolve

[abhilasharora]

[Creating this issue on behalf of @b10-dslappendel as reported in issue #136]

I see that the latest version 4.0 ignores exceptions thrown from keyvault. However, I think I may have misunderstood the use case here. From what I can see, right now the whole configuration is seen as optional, meaning that if at least one keyvault exception is thrown, no configuration values are loaded.

I had hoped that this would cover our use case, which is ignoring only configuration values from keyvault that are inaccessible (e.g. due to no access permissions), instead of ignoring all configuration values if one can't be loaded from keyvault.

Basically, we have hooked up multiple keyvaults in one app configuration, but not all apps have access to all keyvaults that are referenced there. So right now we can't load any configuration if we don't allow access to all keyvaults from all our apps.

In preview version 2, I could still create a custom keyvault delegating handler that ignores 401, 403 and 404 errors and return an empty string, but I also can't seem to find this option anymore in version 4.

Is there any way to support this use case?

[abhilasharora]

@b10-dslappendel Thanks for your feedback. I'm looking into ways to support the use case you shared. The recommended approach is to allow each application to only Select configuration settings that are needed for that application. The configuration provider will only attempt to load settings defined by the criteria defined by the Select clause(s).

In your scenario, is there a reason the application is selecting key-vault references that correspond to key-vaults that it isn't expected to have access to?

[ghost]

@abhilasharora Thanks for moving it in a new issue.
In our scenario, we have a bunch of apps that make use of the same app configuration instance. We have multiple key vaults, but for some higher privileged key vaults, most apps and users shouldn't have access to those unless it's really necessary to pass audits. However, since they are still referenced in app configuration, and they are still selected (because we currently use KeyFilter.All), they fail to be retrieved.

I'm currently discussing with my team to see if we can improve this on our end. Currently we notice that our startup times are getting longer and longer the more settings we add to app configuration and/or key vault.
Using KeyFilter.All isn't the best way to load configurations if 80% of those settings isn't used in one particular app. Currently we aren't using namespaces because we might have been too enthusiastic during preview last year. Namespaces do allow us to select them in a more granular way, but the transition to this is going to be very painful because some settings are used across apps without anything that binds them together in a category.
In the end, we should move to using namespaces, but on short term is not possible. If a next version will allow us to ignore unauthorized secrets, it would definitely help us ease the transition to a newer app configuration version.

[avanigupta]

Hi @b10-dslappendel, please see the proposed solution in #209 and let us know if that works for you.