In the previous blog post, we vibe coded a basic Gemini chatbot, deployed it to Google Cloud Run and configured CI/CD ensuring that every commit to the GitHub repo resulted in a new build being automatically deployed to Cloud Run.
We took an insecure shortcut! Our app needs a Gemini API key and we declared it as an environment variable. Although environment variables aren’t publicly readable in Cloud Run, they’re not the most secure option for storing API keys. This especially becomes an issue as you work with teams greater than 1, where not everyone should have access to sensitive data. But you still need a way for your app to access that sensitive data.
Google Cloud Secret Manager is a secure and centralized management system for storing, managing, and accessing sensitive information such as API keys, passwords, and certificates.
For our simple chat app, Secret Manager ensures that only the app has access to the API key and provides additional benefits such as key versioning and expiration, without requiring code changes to the app.
Making the code changes
We're going to migrate the app to use Secret Manager. We do so with the following prompt to my IDE of choice, Google Antigravity:
Instead of using an environment variable for the Gemini api key, use Google Cloud Secret Manager.
Antigravity provides the following implementation plan:
After proceeding with Antigravity's implementation plan, we see the following code changes:
We will accept the code changes, push the commit and merge it in GitHub. Once the code PR has been merged into the main branch, GitHub will kick off a build (as per our CI/CD setup in Part 1 of this blog series). GitHub indicates that a build is in progress with a yellow dot on the frontpage for the repo as follows.
You can also view the build output while it is in progress by clicking that dot. The build is being carried out by Google Cloud Build but the status is synchronised with GitHub so progress can be viewed there.
Due to our CI/CD setup, Cloud Run will deploy the newly created container image immediately. But we haven't actually configured Secret Manager yet!
Create secret
We now need to go to Google Cloud Secret Manager in the Google Cloud console and create a key as follows:
We need to note the path to the secret as we will need this path to access it later. You can see the project ID and name of the secret below.
Although we are now using Secret Manager to store our API key, we rely on two environment variables to point us to the key - the project ID (a number) and the name of the secret. We noted down the path from the screenshot above and it contained these pieces of information. Therefore we need to edit our Cloud Run deployment to declare these environment variables.
Now let's check out the app!
Uh oh! That was unexpected. The 403 error gives us a clue that this is a permissions problem. We created the secret but didn't allow it to be accessed by our Cloud Run instance. This is a feature! Secrets are access controlled such that only certain users have access to them.
Our Cloud Run app runs under a service account, a special type of Google account intended to represent a non-human user. We need to ensure that the service account has permission to read secrets. We will go to the Identity and Access Management (IAM) permissions for our service account and add the "Secret Manager Secret Accessor" permission as shown below.
Ok now we should be good to go!
And there we have it. We have successfully migrated our code from using an environment variable to retrieve our Gemini API key to using Google Cloud Secret Manager. This is not only more secure but also far more flexible. Check out Secret Manager here.
