Google Cloud Platform: Workload Identity service account binding

[tisc0]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

Hi,
Actually, Terraform propose already (thanks #3790 I guess) :

• to switch on "workload identity" for cluster

workload_identity_config {
    identity_namespace = "${var.google_project}.svc.id.goog"

• to switch on "workload identity" for node pool
  https://www.terraform.io/docs/providers/google/r/container_cluster.html#workload_identity_config

    workload_metadata_config {
      node_metadata = "GKE_METADATA_SERVER"

What's missing is bilateral binding between Kube's Service Accounts and GCP IAM Service Accounts.

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]" \
  [GSA_NAME]@[PROJECT_ID].iam.gserviceaccount.com

https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

This would give a complete and industrialized use of Workload Identity, which provides a secure and elegant implementation for Service Accounts to:

• access Google's APIs from Kubernetes
• delegating the full management (API keys rotation + access rights) to Google
• avoid the need of extract the JSON keys (cancelling by this way, the automated rotation)
• eliminating one more insecure Kube's secret

In other words, Terraform's module could permit [in a single block ?] to:

• create Kubes Service Account (KSA) [if non existent]
• create GCP IAM Service Account (GSA) [if non existent]
• define the metadata necessary to "cross-bind" the Service Accounts (Project ID, K8s Namespace)

New or Affected Resource(s)

Could be:

• google_iam_policy
• kubernetes_service_account_binding ?
• workload_sa_binding ?

Potential Terraform Configuration

resource "kubernetes_service_account_binding" "MicroService_1" {
  metadata {
    ksa_name = "$KSA_MS_1"
    gsa_name = "$GSA_MS_1"
    project_id = "$project_id"
    k8s_namespace = "$prod_namespace"
  }

References

• Support for GKE Workload Identity #3790

Thanks !

[washin0]

Hello,

Here is a suggestion for the binding :

resource "kubernetes_service_account" "resource_name" {
  metadata {
    name = "kubernetes_service_account_id"
    namespace = "namespace"
    annotations {
      "iam.gke.io/gcp-service-account" = "gcp_service_account_email"
    }
  }
}

resource "google_service_account_iam_binding" "binding-name" {
  service_account_id = "kubernetes_service_account_id"
  role    = "roles/iam.workloadIdentityUser"

  members = [
    "serviceAccount:${data.google_client_config.default.project}.svc.id.goog[default/kubernetes_service_account_id]"
  ]
}

This actually fit for the need. Am I right ? @tisc0 ;)

[morgante]

You could also take a look at this module which handles things: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/tree/master/modules/workload-identity

[rileykarson]

Based on https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/tree/master/modules/workload-identity?rgh-link-date=2020-05-12T20%3A21%3A05Z it looks like there aren't any provider-level changes required to support this. Closing.

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.