MARTIN OMANDER: Luka.
LUKA FONTANILLA: Martin, great to see you.
How fair things?
MARTIN OMANDER: Well, thank you.
In a previous video, you showed us
how to set up a CSED pipeline and GitHub actions
using service account keys.
But you also said there was a better way of doing it.
LUKA FONTANILLA: Yeah, exporting service
account keys leads to a lot more work.
For example, when you need to rotate the keys.
That's where Workload Identity Federation comes in.
MARTIN OMANDER: But we must use a key, right?
How else would Google know that the call from GitHub is legit?
LUKA FONTANILLA: The magic is in the implementation details.
Let's take a closer look.
[MUSIC PLAYING]
MARTIN OMANDER: All right.
We're trying to eliminate exported service account keys.
But how can GitHub deploy codes securely to Google Cloud
without a service account key?
LUKA FONTANILLA: Well if someone had my car key,
they could drive my car regardless
of whether I allow it or not.
MARTIN OMANDER: Yeah, that makes sense, Luka.
And that poses a lot of security concerns, right?
LUKA FONTANILLA: Exactly.
And even though GitHub is securely
storing that service account key,
it adds one more place of vulnerability.
Plus, the key is long lived.
MARTIN OMANDER: Right.
Right.
And many organizations even forbid the export
of keys for that very reason.
LUKA FONTANILLA: Right.
Fortunately, we now have Workload Identity Federation,
which means we don't have to rely on keys anymore.
MARTIN OMANDER: How does that work?
LUKA FONTANILLA: Well, with Workload Identity Federation,
when the unknown actor tries to use my car
key in the analogy earlier, I am able to decide
if the car will unlock or not.
So instead of my car key being open to any user
out there when the key is clicked,
a message is first sent that describes their identity.
MARTIN OMANDER: Like who I am, or if I'm old enough to drive,
for example?
LUKA FONTANILLA: Exactly.
When the car key is clicked, a message is sent to a service
that I control.
I can set it up first to only trust
messages coming from certain car keys
or to only allow users that meet given condition based
on information in the message itself.
MARTIN OMANDER: Great.
This seems promising, Luka.
What happens next?
LUKA FONTANILLA: So should the authorization succeed,
the service will send a token back to my car key,
enabling the actor to use it on behalf of me.
The token itself, however, is only single use.
MARTIN OMANDER: Got it.
And each time the key is used, the same flow takes place.
Sounds like I won't have to worry about long-lived service
account keys anymore.
LUKA FONTANILLA: Exactly, Martin.
And we have some best practices for Workload Identity
Federation setup as well.
Let's get into it.
All right, Martin.
We are going to start by setting up Workload Identity Federation
through the Cloud UI.
MARTIN OMANDER: Perfect.
And I presume we can always go back and automate
this setup with G Cloud commands at the command line,
right, later?
LUKA FONTANILLA: Exactly.
We even have all the commands you need for setup here
in the auth action README.
MARTIN OMANDER: That's great.
Now, what's the first step?
LUKA FONTANILLA: The first thing you'll need to get started
is enabled the IAM credentials API in the Google Cloud
Console.
MARTIN OMANDER: Sounds good, Luka.
Let me do so real quick.
All right.
It should be good to go there.
What's next?
LUKA FONTANILLA: Awesome.
So next, we are going to work through configuring a workload
identity pool and provider.
Let's search for Workload Identity Federation
in the Google Cloud Console.
MARTIN OMANDER: Sounds good, Luka.
Looks like I'll need to select the new workload provider
and pool option.
LUKA FONTANILLA: That is correct.
There will be a few things we'll need to do here.
The first will be to create an identity pool, which
manages a group of identities and their access
to Google Cloud resources.
Thinking back to our analogy earlier,
the pool would be the keyring our car key is on.
MARTIN OMANDER: Ah, OK.
That makes sense.
So the pool just manages these identities.
And each of the identities, or keys on the keyring,
would be a provider like GitHub for example?
LUKA FONTANILLA: Exactly, Martin.
In our case, GitHub.
But it can be any--
any identity provider that supports OIDC.
MARTIN OMANDER: Oh, any provider.
Do you have an example of what you might be
able to do here beyond GitHub?
LUKA FONTANILLA: Of course, Martin.
A good example might be a service running on an AWS EC2
instance accessing unstructured data from Cloud Storage.
MARTIN OMANDER: Got it.
To make sure I'm understanding then,
Workload Identity Federation would allow my app
on Amazon Web Services to make a validated request to my Google
Cloud Storage bucket.
And if valid, it would have short-lived access
to that bucket?
LUKA FONTANILLA: That is exactly right, Martin.
And all without the need to export a long-lived key.
MARTIN OMANDER: Beautiful.
It's all falling into place, Luka.
So to get started, let me create a pool.
I'll name this Git--
GitHub Actions Cloud Run workflow here to be specific.
I'll add a provider to this pool.
I assume that'll be GitHub.
LUKA FONTANILLA: That's correct.
Let's choose the OIDC and fill in the information for GitHub.
MARTIN OMANDER: Perfect.
I'll fill in that now.
Oh, what's this issue, or URL field, all about, Luka?
LUKA FONTANILLA: So that'll be a specific URL where
GitHub issues the OIDC token.
Let's check GitHub's documentation for that.
MARTIN OMANDER: OK.
Checking GitHub's documentation.
Ah.
There it is.
Found it.
Copy that, update that field now.
All right.
Not-- what are these attribute and condition inputs here?
LUKA FONTANILLA: Great question.
So the attribute mapping flag is how we map claims from the OIDC
token that GitHub provides to attributes within Google Cloud.
MARTIN OMANDER: Got it.
So those conditions in the car example, that could be like,
is the driver 18 or older?
Are they a family member?
And so on.
And that information would be provided when
the user clicked the car key?
What sort of information can GitHub provide here?
LUKA FONTANILLA: There's a fair amount
that GitHub will provide you, Martin.
And GitHub has a full list.
But to tease out just a few, the repository, workflow ID, actor,
and event name are all common options.
MARTIN OMANDER: So I could, for example,
restrict authentication based off of the repo name
to further lock down access?
LUKA FONTANILLA: Exactly.
The only thing we will need to do
is map them to attributes within Google Cloud.
Let's add a few mappings.
So the first mapping will be the required google.subject,
which we can set to the subject for the OIDC token.
MARTIN OMANDER: All right.
Adding it now.
LUKA FONTANILLA: Second, we can add a few values.
One, for the actor in case we want
to restrict access down to the individual person,
and the other for the repository.
MARTIN OMANDER: Oh, OK.
Adding that as well.
Now, what about the attribute conditions here?
How do I make sure authentication is restricted
to the right repository?
LUKA FONTANILLA: Great question.
And we do so through the attribute condition flag.
The condition can be a common expression language
statement or an IAM policy.
I personally like to use CEL.
It's really simple to use and great for evaluating
expressions.
Plus, we have great docs on it as well.
MARTIN OMANDER: Gotcha.
What would the common expression language of CEL statement
be in this case?
LUKA FONTANILLA: So it's going to be something really simple.
Let's add a CEL statement setting assertion.repository
to the name of your repo, Martin.
MARTIN OMANDER: Great.
I'm doing that now.
LUKA FONTANILLA: The auth action provides
a lot of flexibility, huh?
MARTIN OMANDER: It really does.
OK, Luka.
Is this all I need to do to use Workload Identity
Federation with GitHub?
LUKA FONTANILLA: Last step, Martin,
would be to allow the workload identity
provider to impersonate the service
account you use to deploy the Cloud Run service.
MARTIN OMANDER: Oh, right.
So I need to explicitly specify what service account will
be impersonated.
So what service account will this run on
on the Google Cloud side?
That makes sense.
But how do I do it?
LUKA FONTANILLA: Yeah, so once the pool and provider are
created, we can click into the pool and grant access
to a specific service account.
MARTIN OMANDER: OK, I'll click into the pool now.
So this service account, Luka, this will be one with access
to our Cloud Run resources?
LUKA FONTANILLA: That's correct.
MARTIN OMANDER: Great.
Looks like everything is set up.
And we're ready in Google Cloud.
Let's go and update GitHub.
So let's say.
All right.
I'm in the actions workflow file in GitHub.
And I see the original auth action,
the one we set up last episode.
So what should I change here?
LUKA FONTANILLA: So the changes are actually quite simple.
Instead of the service account key,
we are going to add two new parameters, the workflow
identity provider, and the service account to impersonate.
MARTIN OMANDER: Got it.
I'm going to fill these in with GitHub secrets
that I will create shortly.
So one quick question here, Luka.
What's the format of the workflow--
Workload Identity Federation provider?
LUKA FONTANILLA: So the format of the provider
includes the Google Cloud project number,
the name of the workload identity pool,
and the name of the provider.
We can also use G Cloud commands to fetch the full provider
programmatically as well.
MARTIN OMANDER: Great.
Just fetch the workload identity provider.
We really need a shorter name for it.
LUKA FONTANILLA: I know.
MARTIN OMANDER: That's a lot to say.
LUKA FONTANILLA: It's a lot to say.
MARTIN OMANDER: All right.
Anyway, so the-- this provider and the service account
are saved as secrets in GitHub.
Now, anything else before deploying?
LUKA FONTANILLA: Nope.
It all seems set up, Martin.
MARTIN OMANDER: Perfect.
Let me try out the new CSED workflow.
I'll make a minor change to my code here.
Let's see if it redeploys my service.
LUKA FONTANILLA: Let's do it.
So as the workflow runs, Martin, you'll
notice that the auth action step exports temporary credentials
to our environment.
MARTIN OMANDER: Awesome.
And looks like my service redeployed to Cloud Run.
And all without a service account key.
LUKA FONTANILLA: It's pretty great, right?
MARTIN OMANDER: All right, Luka.
So with these changes, anytime my GitHub action workflow runs,
the workflow is validated as coming from my repository
and a single-use key is provisioned for the Cloud Run
deployment.
Right?
LUKA FONTANILLA: Exactly, Martin.
We are a longer letting just about anyone who has
access to our keys use our car.
That is now locked down based on conditions we control.
Plus, there is no need to export long-lived credentials, which
means our workflow is more secure.
MARTIN OMANDER: Brilliant.
And thank you, everyone, for tuning in.
If you like this video, please subscribe below,
and leave a comment.
Also, let us know if you have any questions for Luka
about what we covered in this video.
And if you're interested in more actions managed by the Google
GitHub actions team, check out their org in the description
below.
Until next time.
LUKA FONTANILLA: Bye
[MUSIC PLAYING]