No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Your question should be possible - e.g. I export the kubeconfig from an EKS cluster in one stack and import it into another and create the provider.

```cat /workspaces/myproject/.cached/.kube/tmp.kube.config.json | gojq -c | pulumi config --stack=myorgd/dev set kubernetes:kubeconfig --secret```
After this running up/refresh and other commands aren't able to connect to the Kubernetes cluster.
However, doing this

```KUBECONFIG=/workspaces/myproject/.cached/.kube/tmp.kube.config pulumi up```
does work. I want to avoid having to pass the kubeconfig and embed in this stack (or at least try it out to see if makes things easier)

strange, I exclusively use `kubernetes:kubeconfig` (declared as secrets) in a test project.

I see "tmp" in the string here &amp; that you're passing it to `gojq -c` *and* usually kube configs are YAML, though that should be a super-set of json. You're also using `KUBECONFIG` with the ".json" version of the file, is it possible that's just not a valid config?

Can you try consuming it as yaml and/or skipping the `gojq -c` step, e.g.:

```cat /workspaces/myproject/.cached/.kube/tmp.kube.config | pulumi config --stack=myorgd/dev set kubernetes:kubeconfig --secret```
FWIW, you can set multiline strings as secrets no problem.

If the file at `tmp.kube.config.json` is valid, it should _also_ work as a KUBECONFIG env var