What is Workload Identity Federation?

Workload Identity Federation is a keyless application authentication mechanism for calling Google Cloud APIs. In this video, we show you what Workload Identity Federation is, how to set it up, and how you can use it to replace service account keys with tokens for applications running outside of Google Cloud. Watch to learn how you can authenticate your application’s access with Workload Identity Federation!

Chapters:
0:00 - Intro
0:12 - The disadvantage of service account keys
1:16 - How workload identity federation works
1:46 - How to use workload identity federation
2:57 - Learn more

Product: Workload Identity Federation; fullname: Joanna Smith;

[patricknelson]

Ok, here's the ELI5 version (as I understand it 😅):

Imagine you're a kid and you want to go play at your friend’s house every day after school, but… there are very strict rules! Your mom said that you’re allowed to play with your friend, but each day you want to play, you still need a note giving you permission that you have to give to your friend’s mom. On the flip side, your friend’s mom is cool with it too, but she doesn’t just trust the note; she needs your mom’s phone number will call her each time to make sure you’re still allowed that day. So, now that school is out, you go home and you get your mom to write you a new note. You visit your friend’s house and hand it to your friend’s mom. Your friend’s mom calls your mom to make sure the note isn’t fake. If it’s real, your friend’s mom gives you permission to play with your friend, but… _only_ for the day!

Except here, you're _actually_ an app, server or some other automated system (the "workload"). Your mom is actually your Identity Provider (IdP) which is somehow affiliated with your workload behind the scenes. At first when your mom said you’re allowed, that was just when you enabled OIDC for your workload on the IdP side. Your friend is actually a service account living in GCP (the Resource Provider) and your friend’s mom is the Security Token Service. The phone number you gave your friend’s mom early on is actually analogous to your Workload Identity Pool (WIP) where you point back to the IdP (and your IdP gives those details to you to plug into the WIP). Your friend’s mom _initially_ approving is like that IAM policy binding that connects your service account (your friend) to and your WIP which then points back to your IdP.

Now, when it’s time to go play at your friend’s house and you bring your mom’s permission note: That’s your OIDC token that your IdP generated (that's the card icon at 1:31). When your friend’s mom calls, that’s when the Resource Provider (GCP in this case) reaches out to the IdP to verify the authenticity of the OIDC token (unfortunately not shown in this video). When your friend’s mom gives you temporary permission to play, that’s the Security Token Service issuing a temporary access token to then allow you to then “impersonate” the service account.

[patricknelson]

Yep, the other folks are right, this is complicated (and I understand the video is terse because it's very high level, but it does come off a bit "draw the owl", hah). However: I've taken time to understand more deeply exactly how it works, and coming back to this video, I can definitely say that it would have been *far easier* to understand if at 2:50 the diagram had the arrows pointing different directions, i.e.:

1. The Workload Identity Pool were pointing to the Identity Provider, since it's in GCP where you plug in that information on the provider side, telling it which IdP to trust.
2. Pointed the service account *to* the Workload Identity Pool instead (i.e. this is the IAM policy binding on the SA side which associates that SA with the particular pool/provider, including it's custom attribute assertions, if any).

And yes, _it is true_ that even on the provider side where the workload runs, you also have some config to point back to the resource provider and it's service accounts (e.g. GCP in this case, using it's credential configuration file). However, that's later in the process, when the "workloads" points to the service account. So... this can be even more confusing for a beginner just trying to grasp when they have to rely on limited (yet complex) details in this video.

[joachimbergstrom]

Excellent info, but had to pause and rewind many, many, many, many times during those 3 minutes...

[rynkrn-xm]

So I understand that the issue they are trying to resolve is to ditch the Service Account keys as a way to authenticate the service account, however they are basically just offloading the responsibility of authenticating the service account to the identity provider. It is unclear what the process of authentication is for the Identity provider. I'd imagine for a human user, that may entail using a username and password, maybe some form of MFA, but if you are trying to authenticate a server or application what would you use to authenticate? perhaps just another API Key??

[veybmofqtwzxgp]

Keyless? Don't you need a key to authenticate to the said "Identity Provider"?

[rafaeel]

Why is this better than service account impersonation?

[arunprasadchief]

I still need to keep the keys to generate the token, what is the improvement here. I am plainng to use only google cloud and python hosted in iis.

[sravanganta]

Can anyone explain how to setup this to use in azure devops pipeline for provisioning infra in gcp using terraform.

[shuuji]

I could figure out how Workload Identity Federation can be used after setting up GitHub Actions and Google Cloud integration by myself. This video helped me to understand how to set up:

I think the complexity came from the nature that the Workload Identity Federation supports and abstracts any kind of identity provider. Identity providers usually tend to become very complex, so compared to that complexity, I would say Google Cloud's implementation is much simpler and elegant although it feels too complex at first especially when someone does not have experience with other identity management services like SAML.

[bryangillespie]

Ok, I ditched the keys, now I have to manage "identity provider" credentials. Seems like the goal posts have just shifted and now instead of the key being the secret I have to manage, the identity provider credentials are the secret I have to manage.

[mehdikaramnejad]

Wow why is so unnecessarily complicated. I just want my google cloud run application to be able to get signed URLs. What am I even doing on this youtube video

[Mw-odsd]

I hate them so much for making everything over complex