Manage your Cloud Run secrets securely with Secret Manager 

Thank you!

Happy to hear that the video helped!

This guy thanks you 😃 I appreciate your kind words.

Good point! We have skipped gcloud commands in many videos because text in a terminal all looks the same after a while. But maybe we should rethink that approach.

On Thursday at 4pm US Pacific time we are releasing a video that shows how this is done. Keep tuned to the Serverless Expeditions playlist and you will see it: ru-vid.com/group/PLIivdWyY5sqJwq_pgOxcHzusWjXDVCEiX

@@MartinOmander thanks. I'll surely keep an eye out for the demo.

I think as he said, it would be ok initially but if you are to update the secrets then you would need to redeploy your service or rerun your init or have an endpoint that you can call to fetch the secrets and reset the .env file

@@discoverlance Yep. That I know of. Actually, I did always wanted the above feature when I started first with secrets and cloudrun. Now can migrate to this without any hesitation.

I believe you are referring to using the Secret Manager client library. That will incur cost if you go beyond Secret Manager's free quota. If you are concerned about the cost, you can cache the secret in your Cloud Run service. In practice, you'd declare a global variable in your code and check if that variable has a value when your service receives an HTTP request. If it doesn't, read the secret from Secret Manager and assign it to the variable. Then use the secret in that variable. You could also mount secrets as environment variables, as described in the video. This essentially does the same as above for you, so you don't have to write any extra code. Which approach you use is largely up to your personal preference, or that of your organization. Hope this helps!

@@TheMomander Thanks very much for the reply. So if i cache the secret I think i need to restart the container when i decided to update my secret. How can I restart my container or any other way to do it ?

@@yansongguo8354 Either deploy a new version of your container, or expose an HTTP endpoint in your container that clears the in-memory cache when you access it.

@@TheMomander Thanks very much🎉

Correct, reading secrets from Secret Manager as environment variables in Cloud Run is a preview feature as I'm writing this (May 24, 2021). It's not covered by Google's SLA. If you are not comfortable with that, you can use the Secret Manager client library, which is a GA feature. There is code for using the client library as well in the repo linked to from the video description.

I'm revising this comment to report that this feature is now in GA. It has been for some time but I didn't spot this comment earlier.

!

Do you mean you want to store your secret in Secret Manager but your code should read it as a file? Click "Edit and deploy new version" for your Cloud Run service. Scroll to the bottom of the "Container" tab and click the button "Reference a secret". In the "Reference method" dropdown, pick "Mounted as volume". If you are instead deploying from the command-line with "gcloud run deploy", use the --update-secrets option. If you search for "gcloud run deploy" you will find the documentation for this option. Hope this helps!

@@TheMomander how would I test this locally? Is it possible?

@@terrillwilson1345 In Google Cloud your code will read the secrets from what looks like a file, for example "./client_secret.json". (It's really a simulated in-memory file provided by Cloud Run and Secret Manager and not a physical file on disk). In your local dev environment you could create a *real* file on disk called "./client_secret.json" that contains the secret. The same code will read the real file when it's running locally and the simulated file when it's running on Google Cloud.

@@TheMomander this doesn't answer the question. the question is reading the file in code, for example: if mounted to /env/admin, can i load the cert like: cert('/env/admin') i cant find a single example out there of anyone showing how to do this

@@Patryc Let's say you have the password "ABC123" that your Cloud Run service needs. You'd start out by creating a new secret in Secret Manager. Now you have a choice about how to access it from your code: as a virtual file, as an environment variable, or using the Secret Manager client library. You asked about how to read the secret as a file. Let's say you mount this secret as "/secrets/password.txt" in Cloud Run. Your code in Cloud Run could then open and read the virtual file "/secrets/password.txt" like any other file: open() in Python, fs.readFile() in Node.js, java.io.FileReader in Java, os.ReadFile() in Go, etc. The contents of the file will be "ABC123". Hope this helps!

That's a very general statement and not always true in some scenarios.

@@KevinBoutinas a rule, you should never do this. It's such an easy way to exploit your service and one of the easiest ways to accidentally leak your sensitive secrets to log files, error reports etc.

For each system, the dev team will have to make a decision on how to to store secrets. It will always be a tradeoff, and there is no single answer that is right for all systems. Reading secrets from environment variables is convenient, especially if you have code that does it already. The alternative is to use the Secret Manager client library instead and make sure you don't give the service account access to list secrets. And whether you use environment variables or the client library, make sure you give each service access only to the secrets it needs.

Many developers prefer to consume secrets as environment variables (per the Twelve-factor Methodology) and lots of existing software reads secrets that way. But if you don't want to do that, you can call the Secret Manager client library instead. You still get all the auditing, encryption, and lifecycle management of Secret Manager, but your secrets will not be in environment variables.

@@TheMomander Secret Manager definitely the way to go. The video named "Secrets in serverless - 2.0" , on this same channel, explicitly calls out "hopefully that made it really clear that you should not store secrets in plaintext environment variables." We need to be encouraging security best practices and helping developers stay safe! Developer preference shouldn't compromise security.

That is a perfectly valid way of handling secrets if you're on GKE. If you are not using GKE, or if you want versioning and auditing of your secrets, Secret Manager is another great way of doing it.