Support IAM SA impersonation to avoid using keys for authentication

[OsamaMM]

Context

There is a need among GCP customers to be able to impersonate IAM service accounts in the data sources instead of using service account JSON keys, as these keys may represent a security risk in case they are leaked or compromised. This will come very handy in multi-tenant GKE clusters (hosting multiple apps maintained by different teams), where multiple Cloud Logging data sources will be created (one per tenant project), as this raises the need for using different service accounts to isolate tenants (one service account per data source that will only have read access to the tenant's project log buckets).

Impact

Many customers block the creation of SA keys using the constraints/iam.disableServiceAccountKeyCreation org policy, so these customers cannot use the plugin today if they want to isolate their tenants and have a SA per scope as opposed to giving the GCE's default SA read access to all log buckets in all apps' GCP projects.

Workarounds explored

• Use the GCE default SA, but this is not viable in multi-tenant clusters as one single SA will need access to all tenant projects.
• Use the JSON key for each per-tenant service account, but many customers block this with the disableServiceAccountKeyCreation org policy to avoid the security risk it involves.

Suggestions

Add a feature to support the impersonation of IAM service accounts, similar to what can be done with the gcloud CLI using the --impersonate-service-account flag. This way, the GCE default SA can impersonate a specific SA (via the roles/iam.serviceAccountTokenCreator IAM role) for each data source that has only IAM access to the tenant's project logs.

[xiangshen-dk]

Implemented the feature in v1.4.0.