[Blogpost] Solving the Workload Identity sameness with IAM Conditions

[abdelfettah]

GKE offers a uniq feature called Workload Identity. This feature allows you to configure a Kubernetes Service Account (will call this one KSA for the remaining of the article) to use a Google Service Account (will call this one GSA for the remaining of the article) to access a Google API without having to manually download an inject Service Account Keys into Kubernetes Secrets. 

Workload Identity however has a single Identity pool per project, which means two identical KSA’s across two identical namespaces across two GKE clusters, will inherit the same IAM policy binding and therefore the same permissions. This is called the “Identity sameness”. It’s best explained in this doc.

Depending on how your clusters are organized this can be an issue, this article provide a way to solve this “Identity sameness” issue using IAM conditions

https://medium.com/google-cloud/solving-the-workload-identity-sameness-with-iam-conditions-c02eba2b0...

[Brewks]

Good day. Thank you for the post.
I've tried the suggested solution and it doesn't seem working now.
When the condition is set, access from the cluster where it should remain also gets disabled.
And the Google Documentation says (AFAIK) nothing about fields mentioned in the topic.
Could you please review and suggest an alternative way to enforce single cluster usage of WI service account?
Thank you.

[abdelfettah]

Hi,

I tested the solution and it still works. It's not meant too work this way, I put an update on the article with some more details https://medium.com/google-cloud/solving-the-workload-identity-sameness-with-iam-conditions-c02eba2b0...

The issue you might be facing is that if you delete and re-create the IAM binding or add a condition to an existing binding you will have to re-create the pods. The KSA to GSA token exchange happens at pod creating and when the IAM binding is updated the token the pod has is unvalidated.

[Brewks]

Hi, 
thank you for taking the time and additional comments.
I used one-time pod or job after each condition change, so pods recreation is not a root cause. 

Could you please clarify, in expression  request.auth.claims.google.providerId=='https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/europe-west4/clusters/gke-eu-we...'

is the right value a cluster selfLink, or is it constructed in some custom way? Will the template string be the same for zonal clusters?
Anyway, we will try to repeat tests then.

[abdelfettah]

Yes that SelfLink looks correct.

For zonal clusters I'm not sure I haven't tried. But you can run gcloud container clusters describe on the cluster to get the selfLink!