JENNY BROWN: Welcome to Cloud Security Basics, a series where
we explain the ins and outs of securing your application
on Google Cloud.
Sound fun?
Then stick around.
Because in this episode, you'll learn
about Google Cloud service accounts
and why you might want to be using them.
[MUSIC PLAYING]
[PHONE DIALING]
SPEAKER: Hello, Cloud detective.
Last time, you foiled my plan to compromise your company's
security.
But you used IAM to keep your members identity secure
and keep me from accessing the data I wanted.
Your employees are secure enough,
but what about your scripts and applications?
If the applications that can automatically
access your resources can be compromised,
then so can a lot of your company's information.
JENNY BROWN: OK, so here's what we know.
Many times, it's useful to have an application or script that
can access resources like data storage buckets
or other Cloud resources on your behalf
without needing a person to manually sign off
on the access.
One way of doing this is by storing a user's credentials
and letting the automation script or application use
those.
But there are a lot of pitfalls involved when
working with user credentials.
For example, if I'm using my user credentials
to access the resources in my automation script,
then any time I share access to the script,
I'll have to share my credentials with someone else.
And this opens up the possibility
of someone using my credentials for something I didn't intend.
And since I'd also have to store my credentials somewhere
for my script to be able to use them,
this adds another security risk.
What if the wrong person gets access to those secrets?
So ideally, I'd like an automated way
to share access to my Google Cloud resources
without having to store or share my user account credentials.
Luckily, Google Cloud provides a lot of tools and services
to protect users from this exact problem.
And in this case, Google service accounts
could avoid many of these issues.
For example, instead of just giving out my user credentials
to run workloads on VMs, it would be better
to create a service account for the application
and grant it access to call Google APIs
so that users don't even need to be involved.
Then I could grant groups of people access
to that service account.
And this access can be easily revoked if necessary
and doesn't involve sharing user credentials
to access a resource.
But how should I set them up?
Let's think about this.
What else do I know about using service accounts?
A service account is a robot identity,
but don't tell them that.
And this service account identity
is assigned to permissions and roles
in order to access resources and set credentials the same way
you'd grant access to humans.
So because service accounts provide the same access
as user accounts, it would be wise to significantly limit
scope and review who has account permissions
and access to your accounts on a regular basis.
Service accounts don't use passwords
in the same way a user account might.
So if you're within Google Cloud,
then you can just attach service accounts to instances
and other resources within Google Cloud.
And it'll securely take care of authenticating the identity
of the service account.
But if you're using service accounts in another Cloud
platform or on prem, you can use public and private keys
to authenticate those service accounts.
And if you're using a service key,
it's important to not download them
because then you've gone from an identity problem, which
is what service accounts are intended to solve,
to a secrets management problem like, who
has access to that key file?
And how will that access be controlled?
This is why some organizations set up policy disabling account
creation entirely.
And if you give an individual your service account key code,
it's really not so different from giving someone
your username and password to your account.
It grants them access to whatever you have access to.
So if we decide to use keys, I want
to, well, one make a policy that we store them somewhere secure
and that we don't do something like commit the service account
credentials to the repository with the source code, which
would defeat a lot of the benefits of service
accounts, two, look at key rotation.
A security best practice is to rotate service account keys
regularly.
And this just involves creating a new key,
switching apps to the new key, and then deleting the old key.
But it helps a lot with securing our credentials
as long as they're stored and accessed securely.
Still, that doesn't prevent the very human errors
like assigning the wrong service accounts to the wrong users
or applications, which would grant unnecessary permissions.
So to minimize the chance of that happening
as much as possible, just like with IAM,
it would be wise to use a naming convention for your service
accounts.
It should be easy to look at a service account
and know its purpose.
A naming pattern like that could be effective
here as long as the service account name fits
into the 30-character limit.
So if a Cloud team requires BigQuery and Cloud Storage
access to automate data uploads, we
would provision a service account named that.
And finally, I want to implement a policy
of tracking and logging unused service accounts.
So hopefully, we have some logging and monitoring set up
because a single application can have hundreds
of service accounts if needed.
And as these continue to pile up,
admins may start to lose track of them all.
Maybe it would be wise to create a policy to disable service
accounts that haven't been used in a while
or at the least have someone manually take a look at them
to see if they're still valid.
That's it.
I think I have enough info to set this up.
SPEAKER: Egads, Detective.
I see you solved yet another Cloud Security riddle of mine.
I was hoping to prey on the automated access points
into your Cloud infrastructure by searching
for stored tokens, passwords, and credentials and source
repos, but I didn't find any.
It seems like you're using Cloud--
it seems like you're using Google Cloud service
accounts to keep your application
secure and scalable.
Service accounts can thwart people like me,
allow access to the right identities when necessary,
and allow applications to access GCP resources
without human intervention.
They make it possible to efficiently and quickly set up
permissions, scopes, and roles for your organization
to keep people like me out.
I hate to admit this, but you should use service accounts
if you need to authenticate applications or scripts to use
additional Google Cloud Services.
You can use them to give out permissions
across numerous resources without having
to expose user data and possibly negatively impact your app
security.
But you can't stop every violation from occurring.
Be ready.
Because next, we'll find out, what
will you do when something sneaks past your defenses?
Hopefully, you're monitoring and logging
what's happening in your application,
or else you have no idea what to do when something goes wrong.
JENNY BROWN: So there you have it, another episode
of Cloud Security Basics.
Next episode, we'll focus on using
logging and auditing to track down suspicious activities.
So stay tuned for the rest of the Cloud Security Basics
series.
Because when it comes to security,
you can't let bad actors win.
[MUSIC PLAYING]