Workload Identity Federation for Developer Access

[HadiqaKhan]

Hi Everyone!

I have studied the use-case for Workload Identity Federation and currently, my GitHub Actions are using that feature to impersonate service accounts. I have researched and studied but could not find the solution or resources for my use-case.

Use-case: I have to remove the use of service account keys among developers. I want them to use WIF for authenticating and interacting with GCS and other APIs from their local development environment. We are not using any other identity provider  so it is also not applicable to connect using Okta. We are using Google Workspace as a identity and I want the developer's workspace accounts to impersonate Service accounts and update, manage GCS without using service account keys.

Looking forward for solutions!

[DamianS]

Hello @HadiqaKhan  ,Welcome on Google Cloud Community.

I have question regarding usage of this SA. How your developers want to interact with Google Cloud? Are they want to simple perform commands like gcloud compute instances list or gsutil ls ? Or they want to deal with Google Cloud APIs programmatically ?

Reason I'm asking is because:

"Workload Identity Federation lets you use credentials from external identity providers like AWS and Azure Active Directory to generate short-lived credentials, which workloads can use to temporarily impersonate service accounts. Workloads can then access Google Cloud resources, using the service account as their identity."

And for source like GH Actions, WIF will act perfectly, however I'm wondering if with your case simple SA impersonation via 

gcloud config set auth/impersonate_service_account SERVICE_ACCOUNT_EMAIL

without creating service keys, but with granting needed permissions for SA will be sufficient.

What I;m trying to say is, that you you don't want to grant your developers high privileges BUT you want to allow them deal with GC via service account, SA impersonation should be enough, especially if they have accounts under your Workspace.

The configuration which should be done, will be only to grant ServiceAccount Token creator role for developers and needed permissions for SA account. Once done, each time developer will perform gcloud command, will receive this info:

~/Downloads/google-cloud-sdk 2 > gcloud compute instances list                                                                                  gcloud test at 08:49:33
WARNING: This command is using service account impersonation. All API calls will be executed as [dadmian@.iam.gserviceaccount.com]].
WARNING: This command is using service account impersonation. All API calls will be executed as [dadmian@.iam.gserviceaccount.com].
NAME               ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
aws-exporter-test  us-central1-a  n1-standard-1               10.128.0.2   .175  RUNNING

 1. Create SA
2. Grant needed permissions at project/directory level for SA
3. Grant each developer following IAM role

• Service Account Token Creator

4. Configure impersionation via CLI by executing this command: gcloud config set auth/impersonate_service_account SERVICE_ACCOUNT_EMAIL

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

[HadiqaKhan]

Hi DamianS,

The developers will interact with the GCS buckets programmatically. They will use the service account key to upload files and perform other operations on the buckets from their local development environment. Meanwhile, I will try to implement the approach you have provided and see if it works for my specific case.

Thanks for the support!

Regards,

Hadiqa Khan,

LinkedIn Medium GoogleCloudskillsboost