Pulumi: Provide opt-in setting to disable default providers

[lukehoban]

Default providers (configured using pulumi config, and used whenever an explicit provider is not passed either directly or indirectly) are very useful for getting started, but for robust deployments, it is often desirable to ensure that providers must be passed and configured explicitly.

While it is possible to do so today, it is still very easy to accidentally allow a resource to pick up the ambient/default provider.

We have taken to encouraging configuring the default provider with invalid configration as a workaround to ensure the default provider cannot accidentally be used - but this only works if you remember to do it for every affected provider (and is an awkward workaround).

We should instead offer an opt-in setting (either an env var or a pulumi:something configuration variable) that turns off default providers, making it an error to attempt to register a resource using one.

This is related to a handful of other issues around default providers - where we may want to go even further - but this specific option is a good "lock things down" opt-in we can easily offer today in advance of larger change.

Related:

• https://github.com/pulumi/pulumi/issues/2059 (allow setting the default provider programmatically)
• https://github.com/pulumi/pulumi/issues/2246 (expose the default provider instance to programs)
• https://github.com/pulumi/pulumi/issues/2917 (adapt API shape to more clearly encourage parenting

[lukehoban]

We have taken to encouraging configuring the default provider with invalid configration as a workaround to ensure the default provider cannot accidentally be used - but this only works if you remember to do it for every affected provider (and is an awkward workaround).

Note that this technique can be used for any of the clouds - for example:

• pulumi config set kubernetes:kubeconfig invalid
• pulumi config set aws:region invalid
• pulumi config set azure:environment invalid
• pulumi config set gcp:project invalid

Not ideal - but should work in practice to avoid accidentally picking up ambient credentials.

[mazamats]

+1 This would be a great addition, ideally it should be per provider and not across all providers.

Our use case: We've started distributing an abstracted API for deploying onto k8s clusters but in some cases developers have been deploying to whatever their KUBECONFIG env var is set to.

[Dominik-K]

I suggest another iteration: an opt-in to implicit provider configs should be the default. Best as an explicit flag for the CLI, e.g. pulumi --implicit-provider-config (and an abbreviation, for sure).

Best as part of the next major release as this would be a breaking change.

[mitchellmaler]

Just ran into this issue. My shell sets a KUBECONFIG for me to connect to clusters and I almost modified the wrong cluster because I missed setting the provider on a single resource. I would like to have the kubernetes config have to be specified in the config or first-class and not automatically pulled from my shell or local file.