Introduction to service accounts on Google Cloud Platform
Background
Imagine that you are a developer working remotely. You have just logged on for the day, with a cup of coffee in hand, and you want to check your email inbox. You enter the username and password for your email account, and if your login credentials are correct, you are granted access to your inbox. By doing so, you have essentially made a request to your email service’s API, and you were authorized with the login credentials that are associated with your user account.
This process can be applied to a ton of scenarios in today’s web applications. A user account represents a specific individual and user accounts are used to authorize and authenticate users to services. This approach works well enough for humans, but what if you want to authenticate an application to use services on the cloud, particularly Google Cloud services? After all, your application should be able to run API requests on your behalf. In that case, what you need is a service account. The following is how GCP documentation describes service accounts, and I think it sums up the concept perfectly:
A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.
Service accounts are similar to user accounts in that they are identifiable by a unique email address and they are used for making authorized API calls, but there are some crucial characteristics that set the two apart:
- User accounts authorize people, service accounts authorize applications.
- Service accounts do not have passwords. Therefore, it is not possible for someone to log in using a service account via a browser.
- Service accounts are not members of your Google Workspace domain. This means that assets shared with your Google Workspace domain are not shared with service accounts.
Authentication and Key Management
Since service accounts do not have passwords, you might be wondering how they authenticate to Google. Service accounts are associated with private/public RSA key-pairs, and they use this key pair to prove their identity. When a service account is created, the public part of the key pair is stored on Google Cloud and the private part is only available to the creator. The key file associated with a service account includes the private key in the following format:
{
"type": "service_account",
"project_id": "project-id",
"private_key_id": "key-id",
"private_key": "-----BEGIN PRIVATE KEY-----\nprivate-key\n-----END PRIVATE KEY-----\n",
"client_email": "service-account-email",
"client_id": "client-id",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/service-account-email"
}Google Cloud APIs use the OAuth 2.0 protocol for authenticating service accounts. The client ID and the private key associated with a service account are used to create a signed JWT and this JWT is used to request an access token from Google OAuth 2.0 Authorization Server. This token is then used to call Google APIs. When the token expires, this process is repeated.
Once a service account is created, it needs to be maintained. You can either let Google take care of managing private/public keys for you (Google-managed keys) or, if your app is not running on GCP or an environment that supports OIDC and identity federation, you can opt to manage those keys yourself (user-managed keys).
Keep in mind that if you choose to manage these keys yourself, you will be responsible for the security of the private key and all management operations including periodic rotation. Rotation in this context means creating a new key, updating your application to use the new key, and deleting the old key. This is necessary because if a key is leaked and someone gains access to the leaked key, they will also have access to any resource that particular service account has access to, and this will likely be untraceable.
Managing Permissions
Service accounts are a very powerful feature of GCP, but in the wise words of Uncle Ben:
With great power comes great responsibility.
And configuring your service account’s permissions is your responsibility! On GCP, it is possible to grant different permissions to service accounts just like you can grant permissions to a member on a project. For example, if you want to allow a service account to store objects in a Cloud Storage bucket, you can grant it the Storage Object Creator role (roles/storage.objectCreator). One important thing to note here is that when granting permissions, you should always follow the principle of least privilege and only grant a service account the minimum set of permissions required to achieve its goal.
It is also worth noting that GCP users who have the Service Account User role (roles/iam.serviceAccountUser) on a service account can access all the resources that particular service account has access to. So you should be cautious not only when granting permissions to a service account, but also when granting the Service Account User role to a GCP user, since this role indirectly provides access to resources.
Conclusion
This was a short introduction to what service accounts are and how they should be used. In conclusion, service accounts are used to authorize applications to use Google APIs and services on Google Cloud Platform. The key file for a service account can be used to authenticate as your service account, so necessary precautions should be taken to ensure its security. There are many other nice features of service accounts, such as impersonation and creating short-lived credentials so watch this space for more in-depth articles.
I hope this introductory post on GCP service accounts was useful to you, and if it was, give us a follow!
