GKE workload identity pool VS workload identity pools from workload identity federation

Question

Google docu says that workload identity could be used to authorise GKE pods to consume services provided by Google APIs (and it works fine). It also says that there would be one automatically created identity pool called PROJECT_ID.svc.id.goog .

Docu about workload identity federation says: "You can use a workload identity pool to organize and manage external identities."

After I configured workload identity as described here (and it works fine) I am trying to retrieve workload identity pools existing in my project and I expect to see PROJECT_ID.svc.id.goog . I am using this command to list pools: gcloud beta iam workload-identity-pools list --location="global" --show-deleted and as an output I get:

local@local:~/$ gcloud beta iam workload-identity-pools list --location="global"
Listed 0 items.

So are GKE workload identity pool and workload identity pools , from workload identity federation, simply two absolutely separate entities? Or it is just beta API which is not completely working atm? Or it is something third?

Answer 1

Finding correct name to product is sometime difficult. 2 very similar name for 2 different products. -> That's your mistake.

---

Workload Identity is a GKE Addon. Before going deeper, you have to know that, on Google Cloud Platform, you don't need to use service account key file because the service account are automatically loaded on every services (Compute Engine, App Engine, Cloud Run, Cloud Function, Cloud Build,...) and accessible through the metadata server . The Google Cloud client libraries automatically detect the environment and use the metadata server if present.

The problem with GKE is that you can run container on several different Compute Engine instances (the nodes) and your different service (K8S services) can have different level of authorization. If you rely on the Compute Engine service account (default behavior without the Workload identity addon), all the pods on the same instances use the same service account (and thus have the same permissions).

To solve that, the Workload Identity addon creates a proxy that intercept the metadata server calls and reply with the correct bind service account for this pods/service on GKE

---

Workload identity pool is totally different. The principle is to configure third party identity providers (such as AWS, Okta, or even custom) and to define the conditions to accept the third party token (email, claims,...).

When the token is accepted, you can perform a call to impersonate a service account, and thus generate a new token (a Google compliant one this time), that you will be able to use in subsequent calls.

The principle here is to avoid to use service account key file, and to rely on third party identity provider to interact with GCP. For example, on AWS you need to call BigQuery, you can create a token with Workload identity pool and your AWS identity and then call BigQuery without the need to exchanges secrets between the platforms.

Note: the best way to keep a secret secure is not to have secret!

Answer 2

My guess is that historically Google started with GKE Workload Identity as a GKE-specific feature a came to a generic approach titled Workload Identity Federation. Both approaches allow you to create access bindings for external identities but use slightly different syntax. Again, I guess they started with GKE and then came to more generic and flexible scheme.

Another platforms, like AWS or Azure do the same k8s magic with Workload Identity Federation feature.