Hangs when `kubectl`/Kubernetes asks for input: enforce non-interactivity

[sanmai-NL]

What happened?

When, for example, an incorrect kubeconfig is active, pulumi up hangs (see e.g., #640). The logs show that Kubernetes somehow returned Please enter Username:. This suggests Kubernetes expects interaction. But Pulumi does not forward this prompt. In general, even as Pulumi CLI is itself (optionally) interactive, then the backend should be enforced to be non-interactive, since interaction from the backend is unpredictable.

Steps to reproduce

Create a kubeconfig with a wrong username. Run pulumi up on a Kubernetes provider based Pulumi stack.

Expected Behavior

Pulumi CLI fails early and clearly.

Actual Behavior

Pulumi CLI hangs.

Output of pulumi about

CLI          
Version      3.42.0
Go Version   go1.19.1
Go Compiler  gc

Plugins
NAME        VERSION
kubernetes  3.21.4
python      unknown

Host     
OS       darwin
Version  12.6
Arch     x86_64

(...)

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[Frassle]

I'm going to assume kubectl checks stdin to decide if it should have an interactive prompt, so if stdin is disconnected it wouldn't hang. Probably better that rather than fixing this in pulumi-kubernetes, that we just change the engine to start all provider binaries with a disconnected stdin?

[viveklak]

We don't really call into kubectl in any way in the provider. But there might be authentication plugins configured in the kubeconfig that can assume interactive access. Curious if your kubeconfig relies on an auth plugin with interactiveMode set?

[sanmai-NL]

I have a plain kubeconfig, coming with Minikube + created extra context/cluster with it.

Even with (misbehaving) plugins, interactivity should be disabled I think.