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!