Retrieve current OAuth access token from google_client_config data source

[dominik-lekse]

This pull request adds the field access_token to the google_client_config data source. The field access_token provides the current OAuth2 token of the client which is used by the provider to authenticate against the Google Cloud API.

I decided to add the field to the google_client_config since this data source refers to the provider client already instead of creating a separate data source. From a hypothetical data source such as google_oauth_token, I would expect that it creates a "fresh" token not used by the provider client and that it allows defining the scope.

Use Case: GKE on GCP with Terraform

A particular use case is to allow the terraform provider to authenticate against a GKE cluster using the credentials already used by the google provider. The following example integrates both, the google and the kubernetes provider in a single Terraform configuration to provision a GKE cluster and create a simple Kubernetes service while purely relying on Google IAM for authentication.

I have added a shorter version of this use case as an example to the documentation of the google_client_config data source.

resource "google_project_service" "container" {
    service = "container.googleapis.com"
    disable_on_destroy = false
}

data "google_client_config" "default" {

}

resource "google_container_cluster" "default" {
    name = "test"
    description = "Test container cluster"

    zone = "us-central1-c"

    min_master_version = "1.9.4-gke.1"
    enable_legacy_abac = false

    master_authorized_networks_config {
        // This configuration is insecure and NOT be used in production
        cidr_blocks {
            display_name = "internet"
            cidr_block = "0.0.0.0/0"
        }
    }

    logging_service = "logging.googleapis.com"
    monitoring_service = "monitoring.googleapis.com"

    node_pool {
        name = "default"
        node_count = "1"

        node_config {
            machine_type = "g1-small"
            image_type = "COS"

            disk_size_gb = 10

            oauth_scopes = [
                "https://www.googleapis.com/auth/compute",
                "https://www.googleapis.com/auth/devstorage.read_only",
                "https://www.googleapis.com/auth/logging.write",
                "https://www.googleapis.com/auth/monitoring",
            ]
        }
    }

    depends_on = [
        "google_project_service.container"
    ]
}

provider "kubernetes" {
    load_config_file = false

    host = "https://${google_container_cluster.default.endpoint}"
    token = "${data.google_client_config.default.access_token}"
    cluster_ca_certificate = "${base64decode(google_container_cluster.default.master_auth.0.cluster_ca_certificate)}"
}

resource "kubernetes_service" "a_service" {
    metadata {
        name = "a-service"
    }

    spec {
        selector {
            app = "a-service"
        }

        type = "ClusterIP"

        port {
            name = "http"
            port = 80
            target_port = 80
        }
    }
}

[rosbo]

provider. The following example integrates both, the google and the terraform provider in a single Terraform configuration

I believe you mean the google and the kubernetes provider correct?

@danawillow Are you aware of other mechanism to authenticate against a GKE cluster?

[dominik-lekse]

@rosbo Indeed, thanks for spotting this. I have updated the description.

[danawillow]

@rosbo I don't have too strong a grasp on k8s authentication, but this seems reasonable as long as it works (I haven't tried it). There's some more info at https://kubernetes.io/docs/admin/authentication.

Also I think this would be useful for other use cases too, like passing credentials as arguments to local-exec scripts (cc @morgante)

[rosbo]

All tests are passing on the CI server. Merging. Thanks @dominik-lekse for your contribution.

[morgante]

Thanks @danawillow, I think this is perfect for our use case.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!