Today I learned how I can impersonate the service account to access the resources/services in Google Cloud Platform without generating a new service account key and store it in my local machine for development purpose!
How we do it normally #
In order to access certain resource or service on the Google Cloud Platform, we normally go to the console, generate a new service account key and download it to our local machine. We'll pass the path to this service account key as an environment variable and it'll be consumed when we launch the service locally for development. It can be visualized as follows:
There are several issues with this approach: #
- It's easy to mis-commit this file to the source control tool like Github.
- The service account key is a long-lived and powerful credentials.
- You don't know how to store it properly and quite easy to lose it.
How we can make it more secure #
To solve the issues mentioned above, we can make use of impersonating the service account. The idea is that instead of generating a new service account key and store it locally, you can generate a short lived token (normally for only 1 hour) and use it to pass the authentication/authorization.
As far as I know, there are two ways to do it:
Before launching your service, do
gcloud auth login
In this case, the service can access the credential from your local environment automatically. I tried this with cloud sql proxy and it seems to work fine.Generate the short-lived token on the fly and export it as environment variable
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token --impersonate-service-account=<sa-name>.iam.gserviceaccount.com)
The above can easily visualized as below:
With that being said, you don't bother managing another service acount key anymore 😙!
Reference #
🙏🙏🙏 Since you've made it this far, sharing this article on your favorite social media network would be highly appreciated 💖! For feedback, please ping me on Twitter.
Published