[MUSIC PLAYING]
CARTER MORGAN: Welcome to another episode
of "VM End-to-End," a show where we have a VM skeptic
and a VM enthusiast come together
to hash out all things VM related.
Thanks for being here today, Brian.
BRIAN DORSEY: Happy to be here.
What's the topic for today?
CARTER MORGAN: Oh, you know what it is.
I need to know about identity.
I need to know about access.
I want to know why I can't just SSH into everything
or if I can.
What do you got for me, Brian?
BRIAN DORSEY: OK.
So a little quickie bit here, and then I'm
going to bring a guest in because I
don't know all the details.
So one, you can just SSH in, right?
It's a computer.
SSH works with keys.
So you've got a key pair, and it works
as-- when you have that token, you can get into any machine
that the public key's on.
And you can just manage those all yourself
if you've got a system to do that.
But it can get to be a lot and get quite complicated,
especially as your organization gets larger.
And we have a way to delegate the creation of those keys
to Google's identity infrastructure.
And that is why I wanted to bring in Emanuel, who's
one of our colleagues who focuses on identity and access
management.
Welcome, Emanuel.
EMANUEL BURGESS: Brian, thank you
for that amazing introduction.
How are you today, Carter?
CARTER MORGAN: Yeah, I'm doing well-- a little confused,
but I think Brian can tell you where my struggles lie.
BRIAN DORSEY: So Emanuel, what's the high level
on identity and access management in Google Cloud?
EMANUEL BURGESS: Brian, that's a great question.
So let's really go back and define what is IAM, right?
So IAM stands for Identity and Access Management.
And so what basically that means is that you can delegate,
or you can control, who has access to what resources
in your Google Cloud account.
CARTER MORGAN: OK.
So you can get your who has resources,
or who has access to what resources.
Who's setting that up?
EMANUEL BURGESS: Well, so at first,
you need to set up a domain.
And so there's a person that's called the super admin.
So the super admin goes into the Admin Console,
and they set up your domain.
And so once they set up your domain,
it automatically creates an organization for you.
Now, this super admin is a role who can do anything
within the Admin Portal.
So they can manage users.
They can create groups.
They can set up multifactor authentication.
They can do all of these things via the Admin Portal.
BRIAN DORSEY: So we've got this super admin and domain.
And the thing I'm used to looking at the most
is projects.
How do those connect?
EMANUEL BURGESS: Right.
And so a domain one-to-one maps with an organization.
And so if we think of projects, projects
sit under an organization.
And so you can really think of an organization as the root
node within your GCP account.
And so with the root node, you can have things under them,
like projects and folders.
And then you can assign resources to projects as well.
CARTER MORGAN: Oh.
And then this hierarchical structure
is what's used to give access to different areas, I take it.
EMANUEL BURGESS: Absolutely.
There you go.
CARTER MORGAN: So then what about
if I want a script or something to access services-- like,
I want a script to access part of Google Cloud's resources
for me.
What do I do then?
EMANUEL BURGESS: If you want an outside application or workload
to access things within Google Cloud,
you can use what's called a service account.
CARTER MORGAN: And what's that?
EMANUEL BURGESS: So you can really
think of a service account as a special account that's
granted to applications in order to be able to interact
with APIs within Google Cloud.
And so if we really want to put this in context,
let's look at a user account, right?
So if I'm a user, and I have access to Google Cloud,
I would go via Chrome to the Google Cloud website,
and then I would log in.
And so when I put in my username and password,
I'm authenticated.
After I'm authenticated, I get to inherit the permissions
or roles that are attached to a group
that I'm assigned to, right?
But if I'm an application, I can't do that.
I can't go and log in to Google Chrome.
So I would need a service account
in order to interact with APIs and services
within Google Cloud.
BRIAN DORSEY: Got it.
That makes sense.
So we have these organization units
that give access to things.
If I'm a user, I can get in one way.
Maybe I can SSH in.
If I'm programs, I can connect to other APIs via these service
accounts.
Are there any other ways that programs get access?
EMANUEL BURGESS: Yeah.
So you have service accounts.
And then you also have service account keys, right?
So back in the day, in the way, way distant past,
right, we gave outside applications access
to workloads or resources in Google Cloud using
service account keys, right?
But service account keys are problematic.
One of the things that make service account keys really not
a good choice if you're trying to really securely build
resources in Google Cloud is because they never end, right?
They live on forever.
And so service account keys, if they're leaked,
can cause a really major issue.
And so whoever has access to your service account keys,
in theory, can impersonate a service account
and get access to all the APIs and all the features that
are attached to that service account.
And then in addition to that, this causes a secrets
management issue, right?
So how do we manage these keys that are just floating around?
So now, you have to come up with a secrets management strategy
in order to safeguard and provide
some type of peace of mind around these service account
keys.
CARTER MORGAN: I never actually thought about some
of these downsides of service account keys.
And I like just saying, these things
from the way distant past.
I love that.
What you just talked about, though,
made me think of something.
It seems like service accounts are used for resources
within Google Cloud.
What if I have some service outside of Google Cloud
that I want to authenticate into?
Is there any way to let Google manage that?
EMANUEL BURGESS: Well, yeah.
So we can do that.
So let's say I'm using Terraform, right?
So I want to build infrastructure
within Google Cloud using a tool called Terraform, right?
So I can do that.
So long ago, in order for me to do
that, in order for the outside application Terraform
to interact with the resources in my Google Cloud account,
I had to give it service account keys, right?
And so I would set up Terraform.
I would create a provider block.
I would pass it my service account keys.
And the service account keys would impersonate a service
account within Google Cloud, right?
So that worked.
But now, I can build my resources,
but now, I have to manage that specific key.
So now, we can use what's called short-lived credentials,
and I don't have to worry about managing these service account
keys.
So now, if I want to build infrastructure
in Google Cloud using Terraform, I
can use short-lived credentials in order
to authenticate Terraform with Google Cloud.
CARTER MORGAN: I love how excited
you were to tell me more about these short-lived tokens.
EMANUEL BURGESS: I love it.
I love it.
CARTER MORGAN: Because they are that cool.
They really are.
So thank you.
All right.
So but now, to the question before--
is it possible to get this kind of security or access
to external workflows?
EMANUEL BURGESS: Well, yeah.
So we also have a feature that's called workload identity
federation.
And so if you have workloads that are external
or outside of Google Cloud that have their own identity
provider, you can authenticate using these short-lived tokens.
And so what happens is you have an application who
gets credentials from its identity provider,
and then those credentials are passed
to Google's token service.
And Google token service takes those credentials,
creates an ephemeral short-lived token
that it passes to the external application.
And now the external application can access and impersonate
a service account within Google Cloud.
BRIAN DORSEY: Got it.
OK.
So we've got a lot of different kinds of access here, right?
So we've got users, service accounts, short-lived tokens,
workload stuff.
How do I decide which ones of these
to use in a given situation?
EMANUEL BURGESS: I mean, that's a great question.
So it all depends, right?
So if I'm a user, and I just have a outside application that
doesn't have an identity provider-- let's
say, once again, I'm using Terraform, right?
I can use short-lived credentials
to authenticate that outside application
and impersonate a service account within Google Cloud.
If I have a workload that has an identity provider-- like,
let's say I'm using AWS for my identity provider,
or I'm using on-premise Active Directory,
or I'm using Azure Active Directory,
or let's even say I'm using Okta.
In those cases, it would be best to use workload identity
federation so you can dynamically
generate keys and not have to worry about manually generating
keys from gcloud command line or one of the other methods.
BRIAN DORSEY: And then all of this taps into IAM.
Actually, that's awesome.
So you've got a consistent way to look at it.
That's super cool.
So if somebody wants to dig in more on this,
where should they start?
EMANUEL BURGESS: In order to get more information about IAM,
security best practices, workload identity federation,
short-lived credentials, you would go
to cloud.google.com/IAM/docs.
CARTER MORGAN: Yeah.
And thank you so much, Emanuel, for coming in
because I had never heard of short-lived tokens.
I'd never heard of workload identity federation.
And I never really thought about some of the downsides
to even service accounts and the long-lived static keys.
So to recap, would you say using IAM is a best practice, maybe,
going forward?
EMANUEL BURGESS: Absolutely.
I think, if you're working in any large organization,
setting up IAM using organizations
is really the best way to go.
Now, if you wanted to just play around with Google Cloud,
you could sign up with just your Gmail account.
But if you did that, that wouldn't give you access
to all the benefits of organizations, right?
So if you're at a large enterprise,
organizations, to invoke IAM on your Google Cloud account
is the best way to go.
CARTER MORGAN: Wow.
So that's about all.
I learned so much today about workload federation,
short-lived tokens, and more.
Brian, Thanks for bringing Emanuel on.
I got to give you props.
BRIAN DORSEY: No, thank you, Emanuel.
This was great.
EMANUEL BURGESS: I appreciate you, Brian and Carter.
Thank you guys for the opportunity.
CARTER MORGAN: Yes.
If you're listening at home, leave a comment with something
you learned.
So I learned about short-lived tokens, workload federation.
What's something that you learned about?
Thank you.
And that's all for this episode of "VM End-to-End."
[MUSIC PLAYING]