SPEAKER: Welcome to an extended episode of the "What's What--
Service Accounts" series.
In this video, I'm going to demonstrate a few of the things
that we talked about in some of the previous episodes.
If you haven't caught those yet, check them
out in the description.
Without further ado, let's see service accounts in action.
For this first demonstration, I'm
going to show you how to create a compute instance with a user
managed service account attached to it
and how a user with access to this instance
is able to use that service account.
In this example, in addition to the project viewer role,
my user account is granted the compute admin role
on the project, so I can create and manage compute instances.
I also have the role service account user ,
but only for a service account called bucket admin,
and not the entire project.
The bucket admin service account has a role storage admin
assigned to it that allows it to create and manage GCS buckets.
OK, let's start by creating a compute instance by going over
here in Compute Engine.
Create.
If you scroll down here, this is where
you'll indicate what service account
you want to use for your compute instance.
So let's pick one that I don't have any access to.
Let's pick sequel admin and hit create.
And you'll see that this isn't going
to work because I have no roles assigned to my user account
over this service account.
And there it goes.
You hover over this little red circle.
It says it right there that I need the service account user
role on that service account.
So let's just delete this and create a new instance
with the right service account.
So once again, we're going to scroll down here
and this time I'm going to pick the bucket admin service
account, which I do have access to.
I am the service account user for that service account.
So give that a second while it creates.
Boom, there it is.
Green check mark means that the instance is running.
So next I'm going to show you that I don't have access
to create a bucket.
Using GS Util down here, I'm going to try to make a bucket
and this should fill.
And yes, access denied.
So I don't have access to create a bucket,
but I do have access to SSH into this instance.
And now that I'm in there, I can show you with gcloud offlist
that the credential account isn't me.
It's the service account attached to the VM
and there it is bucket admin.
So if I'm admin, that means I should
be able to create a bucket, even though I couldn't
do that as myself before.
So let's try that.
Gsutil.
Make bucket.
A new bucket.
And there it is.
No error message, and that's because I created a bucket
as a service account.
Note that I only needed the service account user
role to attach the service account to the instance.
But to use a service account from the compute instance,
I just needed to have SSH access.
That's really important to keep in mind for users
to have access to your VMs.
For this next demonstration, I'm going to generate a key
and show you how I can use it to act as a service account
to access resources.
This time, I'm going to be a user with a viewer
role in the project, and the service
account key Admin role granted only on a service account
called SQL admin.
That service account has a Cloud SQL Admin role sign,
so it's able to create new Cloud SQL instances
and manage any that are already in the project.
If you wanted to create a service account
key through the Cloud console, here's how you do that.
Under IM in Admin, service accounts and hit that menu
right next to the account that you want to create a key for.
There should be a create key option right there.
But for this demonstration, I'm going
to use the Cloud Shell, someone to create a key down here.
$ gcloud, iam, service accounts, keys create,
followed by a file name, and then we're going to indicate
the iam account that we want to create a key for.
So remember this will only work if you have the service account
key admin role assigned and since I
don't have that role assigned to me,
project wide, if I put a service account I don't have access
to budget admin, it won't work.
See?
Permission denied.
So let's put in a service account
that I do have that role signed for
and that would be a SQL admin.
And that worked so now the private key was
saved to that key.json file I indicated in the command.
You can check the keys that already exists with Gcloud IAM
service-accounts keys list, followed by the IAM account
flag and the service account that you
want to see a list of keys for.
The output for this is going to include the key I just created
as well as a system manage key that was added when the service
account was created.
So now that we have a key, let's see what I can do with that.
So first, let me just show you that I do not
have any roles or permissions that allow me to create a Cloud
SQL instance.
So let's try to create one as myself.
And this should fail.
Yes.
So I don't have that permission.
But my service account does.
So how do I use it?
Gcloud auth activate service account followed
by the service account name.
And then indicate the key file.
That was key.json.
Boom.
Activated service account credentials.
So to verify that, Gcloud auth list
will show that SQL admin is the active account right now.
And that means now if I try to create another SQL instance,
it should work.
And success.
So remember, the service account key admin role was only
used to create the key.
A user with as little as a project viewer role
will still be able to use that key
to act as a service account.
So be sure to have a really secure way of distributing
that key and a decent key rotation process in place.
This last demonstration is going to be like the last one,
except I'm going to be impersonating a service
account without keys.
My user account will only have the viewer role in the project.
On the IAM policy of the service account SQL admin,
I'm going to have the service account token creator role
and nothing else.
Let's see what I can do with that.
So for this demonstration, I'm just
going to delete the database instance that I
created in the last example.
So I'll try to do that first as myself.
So Gcloud SQL instances delete followed by the instance name.
Hit Yes.
And there you go.
I am not authorized to make that request.
But now let me run the same command.
Except this time, I'm going to add the impersonate service
account flag followed by the service account name.
Do I want to continue?
I'm going to say yes.
And as you can see, something is happening this time.
And the Cloud SQL instance is deleted.
And I was able to do that without having any roles having
to do with Cloud SQL assigned to me and without the use
of any service account keys.
All I had was a service account token creator role on that one
service accounts IAM policy.
The impersonate service account flag
works on any Gcloud command and is the most straightforward
example of how you can use the service account token creator
role.
The role also lets users create short lived credentials
and generate service account access tokens
so they can send requests to the Google Cloud REST API
as a service account.
Well, that's that for "What's What."
What do you think of the series?
Do you have any other questions about service accounts?
Feel free to let us know in the comments below.
And to learn more about service accounts,
visit cloud.google.com /iam/docs/service-accounts.
Thanks for watching.
And see you next time.
[MUSIC PLAYING]