I get the idea of convention over configuration regarding the providers (e.g. azure or kubernetes) but somehow falling back to a default like the currently logged in azure account or the active kubeconfig of the terminal looks to me like a bit of a risky thing. Sure, if pulumi is only run on CI and I locally only use test clusters this should not be an issue. But there may be the situation that one is developing some new features of a pulumi program, forgets to explicitly add the provider and pulumi falls back to the default provider which accidentally at this point in time is a current session on the production azure account. Is there an easy way to secure against such a scenario? Can I disable the default provider globally or is there a way to set the default provider to some invalid credentials on a per project (but for all stacks) basis? For the kubeconfig I could imaging setting an according

direnv

. Maybe this also works for Azure ARM env vars. But is there a better concept? If not, are there plans of doing so or are there good reasons for always having a default in place? Thanks for your help!

This is a very good question, and something we’ve discussed quite a lot. There are indeed many benefits to making providers explicit. We will likely add a flag to allow turning off the default provider either per package or globally for all packages. In the meantime, a pattern I have used is to set an invalid value for a stack setting (like

aws:region

) which will ensure all resources that are created with the default provider will fail. This indeed does require a per-stack setting though. https://github.com/pulumi/pulumi/issues/2059 is related and/or the same depending on which approach we take to address this.

Thanks for this clarification! This is definitely something that should be a built-in feature to switch to explicit providers. For Kubernetes (where I definitely want to create the provider based on some

StackReference

output, this already works fine by setting

pulumi config set kubernetes:context invalid-context-disabling-default-provider

that gives a good error message if there is a resource not using an explicit provider. Would you recommend to also use explicit providers for the cloud providers? In the beginning (e.g. working with just one Azure subscription, using explicit providers seems like too much effort as the error will not happen when

clientId

,

clientSecret

,

tenantId

, … are defined for the stack. This only gets problematic as soon as a second, explicit provider (e.g. to control global dns) is introduced, which then would mean to switch everything to explicit configuration. So I’d still like to see some flag at that point in time that allows to disable the default provider to avoid an accidental use of it.