Google Cloud has recently introduced service account key expiry to address security challenges associated with long-lived service account keys. With this capability, the company states that "customers can now configure an Organization Policy at the organization, folder, and project level to limit the usable duration of new service account keys" – and thus reduce risks related to leaked and compromised keys.
Earlier, when creating a service account key, Google Cloud didn't let users specify an expiry date. The key stayed valid until they either deleted the key or deleted the entire service account. Now, with the ability to set the key expiry, it is helpful for specific scenarios, such as non-production environments or using 3rd party tools that can only authenticate with service account keys. However, changing the default configuration to include key expiry may lead to unintended outages for developers accustomed to long-lived keys.
Yet, for more advanced organizations that have service account keys disabled already using Organization Policy, the service account key expiry can also act as an exception process to allow using keys for a limited time without changing their organization’s security policy.
Organizations’ cloud administrators can go to the organization policy page and find the constraint with the ID "constraints/iam.serviceAccountKeyExpiryHours". Subsequently, through editing, they can configure a custom allow policy for a duration ranging from 8 to 2160 hours (90 days) with policy enforcement set to "Replace."
Screenshot of the organization policy page to set the expiry of the service account (Source: Google Cloud blog)
Alternatively, configuring the key expiry of the service account is to leverage the practice of key rotation – a process of replacing existing keys with new keys and then invalidating the replaced keys, a recommended way for production workloads. In a Google blog post, the authors wrote:
If you want to set up a key rotation for your service account keys in your organization, we recommend you monitor keys using cloud asset inventory instead of using key expiry to avoid potential outages. This will allow you to send warning notifications to developers when a key is about to expire, and it is time to rotate the key.
In addition, in an earlier LinkedIn post, Lukasz Boduch, a Google cloud architect at SoftServe, commented:
So, what if you Prod GCE or any other SA key expire? Also, if I remember correctly, Google has never recommended this feature for Prod, at least when this was pre-ga :)
And:
Btw also, in the past, you could export a key with an expiring date, did you know? All you needed is a certificate with an expiration date, so this "new" feature is not that cool and new after all.
Johannes Passing, a staff solutions architect at Google Cloud, wrote in a blog post in early 2021:
Things look different when you upload a service account key: uploading a service account key works by creating a self-signed X.509 certificate and then uploading that certificate in PEM format. X.509 certificates have an expiry date, and you can use that to limit the validity of a service account key.
Other Cloud Providers offer similar accounts like the service account in Google. For instance, in Microsoft Azure, the equivalent of a service account is called a "Service Principal." Like service accounts in Google Cloud, a service principal is also used to authenticate applications, scripts, or services to access resources within Azure. This account also has an expiry date that can be set during creation (the default is one year); however, here, key rotation is regularly recognized as a practice to improve security posture and reduce the risk of compromise.
Lastly, more details on service accounts in Google are available in the documentation.