Three Things About Google Cloud Service Accounts

Service Accounts Deserve a Purpose

When you’re working out of a development project, it can be tempting to use a generic all-powerful dev service account with unfettered access to everything via the Editor role. Even some of the default service accounts are created with that access. But you’ve heard of the principle of least privilege right? It’s the thing system administrators have been yelling about for decades whenever someone asks for root access. It means that you should only have access to the minimum permissions you need to do your job. This goes for services accounts too.

Your purpose is to publish messages to this pub/sub topic
  • What roles could this account probably have assigned?
  • What services or APIs could this account probably accessing?
  • What applications/users/systems could be using this account?
  • What would probably break if I disable this account?

Something to try:

If you’ve got some mysterious looking service accounts in your project, update the description and the display name in one shot:

gcloud iam service-accounts update SERVICE_ACCOUNT — display-name “A DECENT DISPLAY NAME” — description “A DESCRIPTIVE DESCRIPTION”

Service Accounts are Resources Too

As it turns out, a service account is more than just an IAM account. They’re resources too. The same way you might want to limit which people have access to a server or a database, you want to make sure you do that for your service accounts, too.

Something to try:

Check the IAM policy for a service account with this gcloud command:

gcloud iam service-accounts get-iam-policy SERVICE_ACCOUNT
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member MEMBER — role=ROLE

You don’t always need private keys

When you’re accessing Google Cloud from your local machine, how do you access the service accounts you need? If your answer involves generating a json key every time you need one then you deserve to know that there’s an easier and more secure way.

Sheesh

Something to try:

First, you’ll need to grant the Service Account Token Creator role to the user for the service account they want to use. You can do that with the command I mentioned above:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member MEMBER --role=roles/iam.serviceAccountTokenCreator
export MYTOKEN=$(gcloud auth print-access-token)
{
"delegates": [
],
"scope": [
"https://www.googleapis.com/auth/cloud-platform",
],
"lifetime": "3600s"
}
curl -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken -H “Authorization: Bearer $MYTOKEN” -H “Content-Type: application/json; charset=utf-8” -d @request.json

More Things About Service Accounts

That’s just 3 things about service accounts but there’s a lot more information on best practices when it comes to making them, managing them, and using them. Here’s a link to the official documentation if you’re into that sort of thing. If you want to learn more about short-lived service account credentials, you can find that right here. If you’re tired of reading, check out a video series on the Google Cloud Tech Youtube channel here.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Roger Martinez

Roger Martinez

Developer Advocate for Google Cloud. Opinions are my own.