Manage your Cloud Run secrets securely with Secret Manager

Рет қаралды 29,676

Күн бұрын

Code shown in this episode → goo.gle/3boFqFb
Secret Manager docs → goo.gle/3eFNtzm
Secret Manager is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data that provides a central place and single source of truth to manage, access, and audit secrets across Google Cloud. In this episode of Serverless Expeditions Extended, Martin demos how you can update an existing Cloud Run service to use Secret Manager without changing any code and while applying the Principle of Least Privilege. Watch to learn how you can use Secret Manager with your Cloud Run service!
Timestamps:
0:00 - Intro
1:31 - Secret Manager
1:45 - Updating a Cloud Run service to use Secret Manager
2:48 - Putting the database password in Secret Manager
3:25 - Referencing Secret Manager from Cloud Run
3:45 - What did we achieve?
4:47 - Two other ways of accessing Secret Manager
5:42 - Wrap-up
Clarification on the video: if you mount a secret as an environment variable (and point it to the “latest” version of that secret), the latest value of the secret is loaded whenever a Cloud Run instance of your service is started. This happens all the time. So even if you don’t re-deploy your Cloud Run service yourself, the new value of the secret will eventually make it into your Cloud Run service.
Checkout more episodes of Serverless Expeditions → goo.gle/ServerlessExpeditions
Subscribe to Google Cloud Tech → goo.gle/GoogleCloudTech
#ServerlessExpeditions #ServerlessExpeditionsExtended #CloudRun
Product: Cloud Run, Secret Manager; fullname: Martin Omander;

Пікірлер: 49

@uxweb 3 жыл бұрын

This is awesome, I'm glad Cloud Run now support this 🎉🎊

@deedetres703 Жыл бұрын

he is soooooo intelligent and able to present in an understandable way! he is great!

@TheMomander Жыл бұрын

Thank you!

@smiljantukic 5 ай бұрын

Thanks Martin, this video is very helpful!

@r3jk8 3 жыл бұрын

wow. really cool stuff

@Ismaelsk8 3 жыл бұрын

Very good 👏👏🚀

@BraulioCassule 6 ай бұрын

Thanks, this video helped me alot!

@TheMomander 6 ай бұрын

Happy to hear that the video helped!

@radeksmola1898 2 жыл бұрын

Hello, how to handle ssh key during building docker image for Cloud Run? SSH key is for private Git repository.

@SunggukLim 6 ай бұрын

This guy is awesome..

@TheMomander 6 ай бұрын

This guy thanks you 😃 I appreciate your kind words.

@Patryc Жыл бұрын

so ive mounted my secret but i cannot for the life of me figure out how to access it. say ive mounted the same way as in your example. what path would i need to access from my app? or, in my case specifically, i've mounted in `/env/admin`. can i access it like `cert('/env/admin')`? EDIT: my problem was my build trigger was configured to use the inline cloudformation.yaml, not the repository cloudformation.yaml

@sujeshthekkepatt1328 3 жыл бұрын

We currently calling the api during the init phase our app and exporting it to env. Is there any issue with it??

@discoverlance 3 жыл бұрын

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

@sujeshthekkepatt1328 3 жыл бұрын

@@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.

@meuko 2 жыл бұрын

Would've also been very useful with identical gcloud cli commands!

@TheMomander 2 жыл бұрын

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.

@pablov.viteri9345 Жыл бұрын

How can i call the path of the secret mounted like local path, for example: "./cliente_secret.json", but instead using secret manager? I dont found any example. (I am not interested in retrieve the bits, only call the entire file as a "local" file on secret manager. Thank you

@TheMomander Жыл бұрын

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!

@terrillwilson1345 Жыл бұрын

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

@TheMomander Жыл бұрын

@@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.

@Patryc Жыл бұрын

@@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

@TheMomander Жыл бұрын

@@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!

@orinda.harrison 3 жыл бұрын

Could you please show a demo or point to a documentation of how to use memcache with cloud run?

@MartinOmander 3 жыл бұрын

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: kzfaq.info/sun/PLIivdWyY5sqJwq_pgOxcHzusWjXDVCEiX

@orinda.harrison 3 жыл бұрын

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

@discoverlance 3 жыл бұрын

But it's still not in GA right? Is it still safe to use on production?

@MartinOmander 3 жыл бұрын

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.

@TheMomander 2 жыл бұрын

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.

@ashtonjohn2481 Жыл бұрын

@yansongguo8354 3 ай бұрын

Hi. Can you elaborate more on the third way to access secret manager? I am using cloudrun but worrying that if we cloudrun scale the access to secret manager api will surge and give me a big surprise in my cost. ( better an example of what is the correct way to use the third way in cloudrun)

@TheMomander 3 ай бұрын

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!

@yansongguo8354 2 ай бұрын

@@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 ?

@TheMomander 2 ай бұрын

@@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.

@yansongguo8354 2 ай бұрын

@@TheMomander Thanks very much🎉

@marcosvelasquezcampoverde6478 3 жыл бұрын

🙂

@marcosvelasquezcampoverde6478 3 жыл бұрын

🙋‍♂️

@Gary21H 3 жыл бұрын

Setting secrets as environment variables is pretty insecure and bad practice though. You should definitely avoid doing this!

@KevinBoutin 3 жыл бұрын

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

@Gary21H 3 жыл бұрын

@@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.

@MartinOmander 3 жыл бұрын

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.

@TheMomander 2 жыл бұрын

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.

@Gary21H 2 жыл бұрын

@@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.

@Babbili Жыл бұрын

Great, usually i create a secret.yaml in gke

@TheMomander Жыл бұрын

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.