[MUSIC PLAYING]
ROGER MARTINEZ: A secure Google Cloud project
is a happy Google Cloud project, and a big part
of maintaining that security is securing your service accounts.
Remember, access to resources can
be granted to service accounts in the same way
that they can be granted to users.
And not only are they designed to be used by applications
and virtual machines, they can be accessed by other users,
too.
That means that a service account
that's set up with access to too many resources
and that's accessible by too many users
introduces a serious vulnerability.
So in this episode, we'll talk about what's
what with securing your service account's roles
and permissions.
When thinking about securely managing service accounts,
you could start by asking two questions--
what resources can your service accounts
access, and what permissions do your service accounts need?
For example, let's take this service account
with the editor role assigned.
What resources can this service account access?
Well, with the editor role, the answer
is pretty much all of them.
OK, so what permissions does this service account need?
The answer to that will depend on what
you need the service account to do,
and it's likely to be a lot less than the permissions associated
with the editor role.
This means that you'll have to adjust the project's IAM policy
to delegate the appropriate IAM roles and permissions.
When you do that, it's best to adhere to the principle
of least privilege.
That means assigning to your service account
the minimum access required for it to carry out its intended
function.
Any account with permissions beyond what it needs
introduces an unwanted security risk.
So steer clear of assigning broad roles to your service
accounts, like owner or editor, especially
in a production environment.
This is true even for default service accounts that
are created for you with the editor role assigned right
off the bat.
Yeah, it's useful for development.
But make sure to narrow things down when turning things up
for production.
Applying the principle of least privilege
also means limiting which users have access
to your service accounts.
Access to your service accounts can mean different things
since there are a number of predefined IAM roles
that will grant users permissions over your service
accounts in different ways.
Let's talk about some of these service
account-related roles that might impact your project security.
First up, we have the Create Service Account and Delete
Service Account roles.
They allow users to do exactly what their names say--
create new service accounts and delete existing service
accounts, respectively.
It's worth noting that the Create role on its own
doesn't let you do anything beyond creating a new service
account.
You'll need to be granted additional permissions
to make changes to its roles or to manage its IAM policy.
Likewise, the Delete role does not
include the permissions to undelete, disable, or enable,
only delete service accounts.
Up next is that Service Account User role.
With this role, users are allowed
to act as a service account to run certain operations.
For example, a user that has the permission
to create Compute Instances, Cloud Functions, or AppEngine
Apps will need the service account user
role assigned so that they can attach a service account to any
of those resources.
Next there's Service Account Admin.
A user with this role can do all administrative tasks on service
accounts-- enable them, disable them, delete them,
and update their details.
They can even make changes to the service account IAM
policies so a user of this role can delegate access to service
accounts to other users.
For that reason, the Service Account Admin role
is very powerful and should be delegated very carefully,
if at all.
Another administrative role for service accounts
is a Service Account Key Admin role.
Users of this role will be able to create and delete
service account private keys.
These keys can be used by other users
to run commands as a corresponding service account.
As you can probably guess, this can become problematic,
especially if you have a boatload of keys floating
around without an effective way of tracking them or managing
their distribution.
This is another role that you'll want
to delegate very carefully.
And finally, there is a Service Account Token Creator.
With this role, a user is able to use
the impersonate-service-account flag to run gcloud commands
as a specified service account.
Now, this kind of impersonation doesn't
require the use of any private keys
and is considered a safer alternative.
The Service Account Token Creator role
also lets users create OAuth2 access tokens,
sign blobs, or generate self-signed JSON Web Tokens.
The Service Account User, Admin, Key Admin, and Token Creator
roles I mention could be granted to any account
by adding the binding to a project's IAM policy.
But watch out.
By granting them on a project's policy,
it will grant those permissions on every service account
that exists on that project.
Now, this likely goes against the principle
of least privilege and is generally not a great idea.
Instead, you can avoid overdelegating access
to service accounts by editing individual service account IAM
policies.
Service accounts aren't just accounts.
They're also considered resources
with an attached IAM policy.
By binding users to these roles on individual service accounts,
you will decrease the likelihood that a user will
make an accidental change and substantially decrease
the blast radius if a user account is ever compromised.
Do your best to grant users access only to the service
accounts that they actually need.
It's also worth noting that yes, service accounts
can be granted these roles on other service accounts.
So take into account instances where
a user can have indirect access to a service account
through another service account.
You can see a service account's IAM policy
with gcloud iam service-accounts get-iam-policy followed
by a service account.
By understanding the roles associated
with service accounts and by doing
a thorough review of your IAM policies
to apply the principle of least privilege,
you'll be taking major steps towards maintaining
a safe and secure project.
But that's not all.
Even after you've done that, there's still more
you need to know about securing your service accounts.
Next time, we'll spend some time talking
about securely impersonating service accounts
and effectively managing their private keys.
See you there.
[MUSIC PLAYING]