Fix panic resulting from passing kubeconfig as object during provider creation

[EvanBoyle]

Fixes #1231

You can successfully create a provider by specifying kubeconfig as an object, even though the SDKs are typed as a string. Any subsequent updates will fail in the DiffConfig path when it tries to parse the existing kubeconfig (it appears that there's no workaround for this at the moment once you've gotten yourself into the situation.

This change adds support for parsing kubeconfig specified as either a map or a string to bypass the panic. Any other types will fail, and malformed kubeconfig maps will continue to fail on this path. I did not update the client SDK types of kubeconfig as the goal of this fix was to get rid of the panic.

How do you get into this situation? EKS specifies kubeconfig as Output<any>, so this is quite an easy mistake to make if the kubeconfig comes back as an object as it does in the following example:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";
import * as eks from "@pulumi/eks";
import * as k8s from "@pulumi/kubernetes";

import * as bcrypt from "bcryptjs";

const vpc = new awsx.ec2.Vpc("lbriggs", {
    subnets: [
        { type: "public", tags: { "kubernetes.io/cluster/lbriggs": "shared", "kubernetes.io/role/elb": "1" } },
        { type: "private", tags: { "kubernetes.io/cluster/lbriggs": "shared", "kubernetes.io/role/internal-elb": "1" }  },
    ]
})

export const vpcId = vpc.id
export const privateSubnets = vpc.privateSubnetIds
export const publicSubnets = vpc.publicSubnetIds

const cluster = new eks.Cluster("lbriggs", {
    name: "lbriggs",
    vpcId: vpcId,
    privateSubnetIds: privateSubnets,
    publicSubnetIds: publicSubnets,
    createOidcProvider: true,
})

export const clusterName = cluster.eksCluster.name
export const kubeconfig = cluster.kubeconfig
export const clusterOidcProvider = cluster.core.oidcProvider?.url
export const clusterOidcProviderArn = cluster.core.oidcProvider?.arn

const provider = new k8s.Provider("k8s", { kubeconfig: kubeconfig });


// TODO: make this a secret and set as a config value
const password = bcrypt.hashSync("changeme", 10)

const argocd = new k8s.helm.v3.Chart("argocd",
    {
        namespace: "default",
        chart: "argo-cd",
        fetchOpts: { repo: "https://argoproj.github.io/argo-helm" },
        values: {
            installCRDs: false,
            configs: {
                secret: {
                    argocdServerAdminPassword: password,
                },
            },
            server: {
                service: {
                    type: 'LoadBalancer',
                },
            }
        },
        // The helm chart is using a deprecated apiVersion,
        // So let's transform it
        // transformations: [
        //     (obj: any) => {
        //         if (obj.apiVersion == "extensions/v1beta1")  {
        //             obj.apiVersion = "networking.k8s.io/v1beta1"
        //         }
        //     },
        // ],
    },
    {provider: provider },
);

export const url = argocd.getResourceProperty("v1/Service", "default/argocd-server", "status").apply(((status: any) => status.loadBalancer.ingress[0].hostname))

On the first update, the code runs fine and resources are created. On subsequent runs, it panics with the error message in the linked issue. The panic is no longer triggered after this change. It is unclear to me if the any typing of eks kubeconfig is intentional or a bug, will follow up on that separately.

[github-actions]

PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting.

Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR

[github-actions]

PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting.

Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR

[lblackstone]

/run-acceptance-tests

[github-actions]

Please view the PR build - https://github.com/pulumi/pulumi-kubernetes/actions/runs/360069551

[github-actions]

PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting.

Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR

[EvanBoyle]

Tests passed https://github.com/pulumi/pulumi-kubernetes/actions/runs/360069551

[EvanBoyle]

@lblackstone Is the acceptance test bot working? Double checking that link, it seems to have built against the wrong PR: https://github.com/pulumi/pulumi-kubernetes/actions/runs/360069551

[lblackstone]

@lblackstone Is the acceptance test bot working? Double checking that link, it seems to have built against the wrong PR: https://github.com/pulumi/pulumi-kubernetes/actions/runs/360069551

Yes, the header is misleading, but the checkout is for the correct SHA: https://github.com/pulumi/pulumi-kubernetes/runs/1391649550?check_suite_focus=true#step:2:478 3b17e52