7 important details on GCP service accounts

"Do you want to understand how Google Cloud accesses resources in your GCP project?"

The answer is simple: "Service accounts". Service accounts are an integral part of the Google cloud platform.

In this article, We are going to see what service accounts are, how they work and some of the important terminologies that everyone should know while working on GCP.

Service account in GCP

Service account is a type of identity in google cloud platform which is provided to applications like compute engine VMs, Cloud Functions etc.

How it differs from the user identity is shown below

Note: Since service accounts are resources, they can only be created in a project. Service accounts cannot be created at folder / organization level. However, service accounts in a project can be provided access at the folder / organization level.

Analogy with AWS

If you are coming from an AWS background, then service accounts are similar to the users in AWS. With AWS users, we can generate access credentials and use it anywhere for authorizing the AWS APIs.

The difference is that AWS users can have console access which is not possible with service accounts.

Service account key

We can generate credentials from the service account which is called a service account key. The key gets stored as a file. This key can be used anywhere for authenticating with Google Cloud APIs.

If you are working in the GCP project, then you don’t need to use a service account key as the GCP services automatically generates access tokens from the service account.

Best practice: Avoid using service account keys as they can be used to call Google APIs which the service account has access to. They should be used as a last resort.

However, there are other techniques to avoid using the service account keys. The use cases are discussed in detail in this section.

Authenticate as a service account

If you have a service account key, then authenticating with it is very straightforward. You need to set an environment variable GOOGLE_APPLICATION_CREDENTIALS to the path of the service account key file in the machine.

Important: Setting GOOGLE_APPLICATION_CREDENTIALS does not automatically update gcloud active account to the service account. So gcloud will continue to use user account credentials only. If you want gcloud to use service account, then you have to run gcloud auth activate-service-account command

The other approach is using the service account impersonation. It's basically that the user can act as a service account. So there is no key file needed.

Instead the user who is impersonating the service account needs to have 2 roles on the service account. The roles are Service account Token creator and Service Account user. To impersonate a service account, you can run the following command

This is more secure as we don’t need a service account key.

Get access token from service account

There are multiple ways to get the access token

• You need to authenticate as the service account. If you have gcloud installed, then the token can be generated using the command

• You can also get the access token from the compute engine metadata server. This metadata server by default is available on all VMs, Cloud Functions etc

  
  

• Directly call the IAM Credentials REST API

  
  

By default, the expiration of the token is 1hr. But method 3 can be used to set expiration upto 12 hrs by setting up organization policy.

These are called short-lived credentials as they expire after some time.

Default service account

Default service accounts are the service accounts automatically created by GCP for App Engine & Compute Engine. They are not the same as service agents.

When you enable the Compute Engine API, GCP creates a service account with email <project-number>[email protected].

Similarly when an app engine application is created in the project, GCP creates a service account <project-id>@appspot.gserviceaccount.com.

GCP by default gives the editor role to both of the service accounts.

Best practice: Avoid using default service accounts as they have an editor role which is too powerful.

Service Agents

Service agents are the service accounts which are managed by GCP for accessing resources in the project.

Now you might say, why is that required?

For example, Let's say you want to create a GKE cluster. GKE under the hood uses a compute engine to provision the VMs. Typically when the VMs are created, GCP uses caller identity for provisioning the VMs.

But when it comes to GKE, which identity GCP will consider for provisioning the VMs? The answer: GKE service agent.

In a above image, we can see that there is Kubernetes Engine Service Agent which has a predefined role: Kubernetes Engine Service Agent

The roles are granted to the service agents because they are provisioning resources on behalf of GCP in our project. These identities are automatically created when we enable the API

Warning: These IAM bindings should not be deleted otherwise this can cause GCP environments to behave unexpectedly. This generally occurs if someone sets IAM bindings authoritatively.

This can be better understood by an example as follows

• Enable Kubernetes Engine API. Once the API is enabled, you should see in the IAM that the service agent is automatically granted a role.

  
  

• Deploy a GKE cluster.

  
  

• Delete a GKE Service agent IAM binding and refresh the page. After deleting the service agents, we can see that there are problems in the Kubernetes Cluster.

• Add back the IAM bindings of the service agents. The cluster is back in the normal state.

Monitoring service account usage

As your organization grows, the number of service accounts grows along with the peoples who have access to those service accounts. So it is very important to monitor the service account usage.

Service account key usage can be monitored by creating a filter

In the authenticationInfo, we can see that the bucket is created by authenticating with the service account key file. The attribute serviceAccountKeyName which can be used to check whether a service account key is used.

Policy analyzer can be used to check who has access to impersonate service accounts.

Common Use cases

Now, you should have a good understanding of the service accounts in GCP. If you like this post, please do share it with your colleagues.