BUG | Resource vultr_kubernetes outputs non-readable kube_config value

[gruberdev]

Description

When provisioning Kubernetes resources using Vultr's provider, if you try to output the resulting kube_config file to access the cluster, it returns a huge single unintelligible hash with no information whatsoever.

To Reproduce Steps to reproduce the behavior:

main.tf

```hcl resource "vultr_kubernetes" "k8" { region = var.cluster_region label = var.cluster_name version = var.kubernetes_version node_pools { node_quantity = var.cluster_nodes plan = var.cluster_machine_type label = var.node_labels } } resource "local_file" "kubeconfig" { content = vultr_kubernetes.k8.kube_config filename = "${path.module}/config.txt" } output "kubernetes_kubeconfig" { value = vultr_kubernetes.k8.kube_config } ```

variables.tf

```hcl variable "node_count" { description = "Number of controller plane instances. Currently only 1 is supported." type = number default = 3 } variable "cluster_region" { description = "Cluster deployment region." type = string default = "ewr" } variable "cluster_name" { description = "A human readable cluster name, used as part of instance hostnames and labels." type = string default = "main" } variable "vultr_token" { description = "A human readable cluster name, used as part of instance hostnames and labels." type = string } variable "cluster_machine_type" { description = "Vultr Plan to use for worker instances." type = string default = "vhf-1c-2gb" } variable "node_labels" { description = "Kubernetes Pod Network CIDR. Cannot overlap Cluster Private Network IP's(default: 10.240.0.0/24) or Cluster Service IPs(10.96.0.0/12)." type = string default = "test" } variable "kubernetes_version" { description = "Vultr API Key to be used by the Vultr CCM and Vultr CSI. This may be the same API key as your Terraform Vultr API Key, however it is recommended you use a separate key." default = "v1.20.11+2" type = string sensitive = true } variable "cluster_nodes" { description = "Subnetmask for the clusters Vultr Private Network." type = number default = 3 } ```

versions.tf

```hcl terraform { required_providers { vultr = { source = "vultr/vultr" version = "2.5.0" } } required_version = ">= 0.0.1" } provider "vultr" { api_key = var.vultr_token rate_limit = 650 retry_limit = 5 } ```

• Running these files with the required non-default variables provided, it'll reproduce the bug at the current version of the provider.

• I suspect this might be related to this snippet, which leads to this function as well and finally here. I'm not sure how deep it goes before I can understand what is wrong, but the way it is formatted now requires documentation to be understood.

Example of the first function calling the file:

    d.Set("date_created", vke.DateCreated)
    d.Set("cluster_subnet", vke.ClusterSubnet)
    d.Set("service_subnet", vke.ServiceSubnet)
    d.Set("ip", vke.IP)
    d.Set("endpoint", vke.Endpoint)
    d.Set("status", vke.Status)

    config, err := client.Kubernetes.GetKubeConfig(ctx, d.Id())
    if err != nil {
        return diag.Errorf("could not get kubeconfig : %v", err)
    }

    d.Set("kube_config", config.KubeConfig)

• And I wouldn't expect the tests to detect it, as they do not seem to analyze the file structure of kubeconfig

Expected behavior A clean kubeconfig file ready to be used, similar to this implementation.

[ddymko]

@gruberdev

The kube_config value is actually the admin kubeconfig base64 encoded. If you base64 decode it you will have the full config.

Looks like we missed adding this bit of info to the Terraform docs. We'll get that patched up.

[voxxit]

@ddymko One suggested addition: an example of exactly how one might use base64decode or similar to decode then use it, say, in the helm provider after initial cluster creation. I'd like to be able to build/test/teardown in a single terraform run, and that would be an awesome addition to get me started quickly!