Should we allow optional secret provider registrations?

[stijnmoreels]

Is your feature request related to a problem? Please describe.
As proposed here, @fgheysels makes the point that we could include optional registrations for the secret providers in the secret store (like provided in the configuration providers).

Describe the solution you'd like
What needs to be figured out is:

1. Should we provide the option to register all secret providers as optional registrations?
2. If so, should we ignore/log the exceptions when the secret is not found instead of blocking?
3. If so, should we allow invalid/incorrect setup of the secret provider with possible unauthorized exceptions to be ignored when the secret provider was registered as optional?

Additional context
#171 (comment)

[tomkerkhove]

Isn't that how it works today? If it can't find it in the first provider, it will go to the second, then to the third, etc.

Or am I not getting the proposal correctly?

[stijnmoreels]

No, it's more about, if the 'setup' of the provider fails, should we block the secret store or should we ignore it (optional).

[tomkerkhove]

So it would be to not block on configuration issues then, is that correct?

Interesting 🤔

So @fgheysels his initial comment (#171 (comment)) was:

I've changed this, but now this means that if you specify a non-existing directory, the container will fail to start. That is a good example of failing fast but I don't know if you really want that.

What if you have a program which has multiple secret providers configured. In some cases, your program might not be running in a container and needs to retrieve secrets from another location. In that case, you still need to have that directory present.

In this case, wouldn't it be more suitable to make the folder name configurable? I'm just not sure what the exact scenario would be other than this 🤔

[stijnmoreels]

It's I think more about aligning with the configuration provider. Where also mostly have an option to make it optional. Like when adding the app settings and adding an additional app settings file for local development.

[fgheysels]

True.
Or, in this case for a code base which is deployed as a container but that same codebase can also be deployed on an Azure AppService (without a container). When we register a secret provider like the 'Docker Secrets Provider', and the 'secretsFolder' that is passed to that secret provider doesn't exist, an exception is thrown. When we run the same codebase in an Azure App Service, that folder will most like not be there.

[tomkerkhove]

Makes sense, thanks for explaining further! Let's make it so 😎

[stijnmoreels]

We still have to decide on the questions described in the issue here. We should have a clear distinction on what this means for the secret store.

[stijnmoreels]

According to this, both connection issues and configuration issues are ignored by optional. But Azure related uses sometimes different defaults.

optional
This setting is a boolean that specified whether to avoid throwing exceptions when the backing configuration source cannot be found or connected. The default default value is true, though some config builders (such as the Azure-based builders) will use a different default.

https://github.com/aspnet/MicrosoftConfigurationBuilders#optional

[stijnmoreels]

We can wait for #211 to complete.

[tomkerkhove]

@fgheysels would it make sense to have it more on a per-provider level so that the docker secrets can coop with this then in case the file is not there for example?

[stijnmoreels]

Should we include this too in the v1.4.0 milestone? And if not, the next?

[tomkerkhove]

Let's wait until we know what to do

[stijnmoreels]

Closed in favor of #241