SPEAKER: Service accounts-- where do they come from?
In the last episode, I mentioned that there are some service
accounts that are created automatically
for us, like Google-managed service accounts and default
service accounts.
That's really nice, but you might want
to know how to create your own.
After that, how will you manage them?
What will you do when you need to get rid of one?
These questions mean that it's time
to talk about what's what with creating, managing,
and retiring your service accounts.
Creating a service account is as easy as one gcloud command--
gcloud iam service-accounts create.
Upon creation, this new service account
will have no rules assigned, so zero access to any APIs
and services.
Before we talk about assigning roles and permissions,
let's iron out the creation process a little bit more.
Every service account should have a purpose.
One of the best best practices that you could practice
is to make sure a service account's purpose is
clear to you and to any other administrator that
might inherit your project in the future.
So when you create a service account,
make sure that you include a descriptive display name.
If you want to take it a step further,
and I recommend that you do, you can include even
more details and context in that service account's description.
When creating service accounts, make
it a habit to figure out a meaningful display name
and description on creation by tacking on the --display-name
and --description flags to your gcloud command.
This will be especially useful if your project accumulates
a long list of service accounts, each with a different purpose
and set of IAM roles assigned to it.
You can view the display name and description for any service
account using gcloud iam service-accounts describe,
followed by the service account email.
You can always update these fields in the console
or by using the CLI with gcloud iam service-accounts update.
When you have service accounts in your project,
a big part of managing them is managing
the IAM roles and permissions associated with them.
If you're already familiar with Google Cloud's IAM policies,
then you might already know that checking what a service
account is capable of doing is as simple as checking
the IAM policy of your project.
gcloud projects get-iam-policy followed
by your project ID will show you all the IAM role
bindings on your project, including the roles assigned
to your service accounts.
Service account management doesn't only
mean understanding what resources service accounts have
access to, but also who has access to your service
accounts.
When you're taking a look at your IAM policy,
take note of any accounts that have
roles associated with managing or using service accounts.
This includes predefined roles like Service Account Token
Creator, Service Account Admin, and Service Account Key Admin.
Some of these roles will allow users
to make changes to, or even act as, service accounts.
That means it's technically possible for a user
that you intend to be restricted to have unrestricted
permissions via a service account with bloated access.
It's a security topic that we'll cover in a later episode.
In addition to the IAM policy on your project,
there is also an IAM policy for each service
account in your project.
The role bindings on these policies
are limited specifically to their corresponding service
account, and are not visible on the project's IAM policy.
You can retrieve a particular service accounts IAM
policy with gcloud iam service-accounts
get-iam-policy, followed by the account email.
All of this role and policy info is
available from the Cloud Console under IAM and Admin Settings.
There may come a day when you'll want to get rid
of a service account.
You could just delete it.
But beware-- once you do, any users, applications,
or VMs that are configured to use it to access any resources
will lose that access.
It is important to use caution when deleting a service
account, especially if you're not so
sure about what it's used for.
It's much safer to disable it first.
Once an account is disabled, yeah, applications
will lose that access that they had through it,
just like when you delete it.
But a disabled service account can easily
be re-enabled at any time.
Does that mean that when you delete a service account,
it's completely, totally, utterly,
and hopelessly lost forever?
No, not exactly.
You could undelete a deleted service account,
but only if two things are true--
one, the service account had to have been deleted
within the past 30 days, and two,
there can be no other service accounts
in existence on your project with the same name
as the deleted service account.
That's because disabling a service account
will reserve the name, but deleting it will not.
After you check the service account's details and roles
and decide it's probably not in use,
you can disable the service account with gcloud iam
service-accounts disable.
If it turns out that the account is needed again
for whatever reason, enabling it is as simple
as gcloud iam service-accounts enable.
Otherwise, you can delete it with gcloud iam
service-accounts delete.
So we talked about how we can best create service accounts
by providing them with a clear purpose,
and how to safely delete them by disabling them first.
We also talked about managing their access
by checking the project and service account IAM policies.
That's only part of what goes into managing service accounts.
Next time we'll expand on that, and talk a bit more
about securing service accounts' roles and IAM policies.
See you then.
[MUSIC PLAYING]