I’m investigating <https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity|Workload Identity Federation for GKE>. Our org has been long-time users of the previous impersonation-based Workload Identity - so I was excited to hear about this newer WLID that doesn’t require the 2-way mapping between k8s and GCP service accounts.
Except - I just read that the IAM Policy Troubleshooter <https://cloud.google.com/policy-intelligence/docs/troubleshoot-access?_gl=1*x5d8nh*_ga*MTU2ODk1MTMzNS4xNzQ0MzkxNzEw*_ga_WH2QY8WWF5*czE3NTI3MTMyNzMkbzE2NyRnMSR0MTc1MjcxNjIxNyRqNTQkbDAkaDA.#:~:text=Other%20types%20of%20principals%2C%20including%20groups%2C%20domains%2C%20workforce%20identities%2C%20and%20workload%20identities%2C%20are%20not%20supported|doesn’t support workload identities>, among other principal types. Sure enough I can’t find any sort of service account email related to the k8s service account - nothing in audit logs, gcloud auth print-identity-token
just gives an error.
So I’m very curious: how are teams that use WLID Federation for GKE debugging IAM issues? Now that there’s no service account email to plug into the troubleshooter , audit logs, etc. And when you can create a
principalSet
binding that grants to all pods in a cluster, seems the grants can get sprawled out