[MUSIC PLAYING]
ROGER MARTINEZ: Whether you're a gigantic enterprise
or a small team at a startup or even a lone developer,
if you're using Google Cloud, there's
one thing you all have in common.
Your project will use and depend on service accounts.
Everyone uses them, but what are they?
What do they do?
Where do they come from?
And why should you care?
These are all important questions
that we have got to know the answers to.
I'm here to help you figure out what's
what with service accounts.
[MUSIC PLAYING]
So service accounts-- what exactly are they?
To answer that, let's take a look at something
you might already be familiar with--
a user account.
[AUDIO OUT] account represents Yajaira, the lead engineer
on your team.
She accesses the account with the email address and password
associated with it, and access to it
is shared with no one else.
[AUDIO OUT] IAM rules associated with it
that grant it permission to do some fun stuff,
like manage Kubernetes clusters, create compute instances,
and configure monitoring on the project.
As long as Yajaira works on the team,
she can do whatever the IAM policy allows.
And if she leaves a team, well, her account
would be disabled so that it couldn't be used anymore.
That's a user account.
A service account, on the other hand,
is an identity that a compute instance or an application
can use to run API requests on your behalf.
[AUDIO OUT] are a few major differences between a user
account and a service account.
Like Yahaira's user account, a service account
has an assigned email.
But instead of a password, it can only
be authenticated using a private-public RSA key pair,
and it can't be logged in via a browser.
[AUDIO OUT] accounts typically represent virtual machines
and applications.
And while user accounts should never be shared,
permission can be granted to users to impersonate service
accounts, allowing multiple users to access everything
that a service account can access.
[AUDIO OUT] accounts are granted IAM roles
to perform certain actions and access certain resources
in your project, just like a user account,
although they're usually executing automated actions
and might have multiple processes dependent on them.
That means you'll need to be extra careful when
you edit their access or if you want to disable or delete them.
[AUDIO OUT] two types of service accounts.
Well, first, there are Google-managed service
accounts.
You might see these sometimes referred to as service agents.
These are service accounts that google automatically
creates and manages for some Google Cloud Services.
For example, right off the bat, your project
is likely to have a Google APIs service agent.
This is a service account that runs internal Google processes
on your behalf.
There could be more Google-managed service accounts
that exist in your project, but you'll only
see them in your IAM policy or audit logs
when you enable an API or a service that needs it.
[AUDIO OUT] service accounts, you technically
can change and revoke their roles.
But that's generally not a great idea
because it could cause some services to stop
working correctly.
[AUDIO OUT] type of service account
that we have is a user-managed service account.
This is a service account that you explicitly
create using identity and access management.
You choose a name and the roles associated with it yourself.
[AUDIO OUT] into any that you create,
user-managed service accounts include default service
accounts.
These are user-managed service accounts
that are created when you use some Google Cloud Services that
are meant to help you to get started.
A default service account is created
for App Engine and any service that uses App Engine
and for Compute Engine and any service that
uses Compute Engine.
[AUDIO OUT] for those default service accounts is typically
PROJECT_NUMBER-c ompute@developer
.gserviceaccount.com for Compute Engine and PROJECT
ID@appspot.gserviceaccount.com for App Engine.
Default service accounts are generally granted the editor
role on your project.
For production workloads, this might be a bit much.
So it's recommended that you create your own service
accounts for these services and apply more restricted roles
to them.
How can we see these service accounts
in our Google Cloud project?
If you want to see all of the user-managed service
accounts that currently exist on your project,
you can use the Google Cloud console on their IAM
or through a CLI using the gcloud command.
The command $ gcloud iam service-accounts list will
nicely list your user managed service accounts,
display names, emails, and whether they're disabled.
[AUDIO OUT] see all of your service accounts,
including Google-managed ones, the command $ gcloud projects
get-iam-policy followed by your project ID is your best bet.
This will spit out your project's IAM policy,
the roles currently assigned to the accounts on your project.
This is going to include user accounts, user-managed service
accounts, and Google-managed service accounts,
as long as they have roles assigned to them.
[AUDIO OUT] have only begun to scratch the surface of service
accounts here.
There are still some other things
worth considering when we talk about service accounts.
In this series, we're going to learn more
about creating them, getting rid of them,
effectively managing them, properly securing them,
and using them for development.
If you like this video, hit subscribe or leave us
a comment below.
See you next time.
[MUSIC PLAYING]