Great video 👍The only thing that I wished was in the video is related to pricing. Reason is that the docs says first 10k requests for a secret are free and then after it is $0.03 per 10k requests... so with this CloudRun integration I'm assuming that one request will be made per secret when a new container is spun up, and I'm assuming it is the same with the file mapping option... but when using the secrets manager api directly (as shown in the code sample) will it work differently? I'm guessing that each time the code runs it will be one request, but would love to know for sure :)
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: th-cam.com/play/PLIivdWyY5sqJwq_pgOxcHzusWjXDVCEiX.html
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)
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.
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
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.
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.
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
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 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!
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.
@@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.
he is soooooo intelligent and able to present in an understandable way! he is great!
Thank you!
This is awesome, I'm glad Cloud Run now support this 🎉🎊
Great video 👍The only thing that I wished was in the video is related to pricing. Reason is that the docs says first 10k requests for a secret are free and then after it is $0.03 per 10k requests... so with this CloudRun integration I'm assuming that one request will be made per secret when a new container is spun up, and I'm assuming it is the same with the file mapping option... but when using the secrets manager api directly (as shown in the code sample) will it work differently? I'm guessing that each time the code runs it will be one request, but would love to know for sure :)
Yes, you are right: every time you make a direct call to Secret Manager, it will be counted as one "access operation".
This guy is awesome..
This guy thanks you 😃 I appreciate your kind words.
Could you please show a demo or point to a documentation of how to use memcache with cloud run?
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: th-cam.com/play/PLIivdWyY5sqJwq_pgOxcHzusWjXDVCEiX.html
@@MartinOmander thanks. I'll surely keep an eye out for the demo.
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)
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🎉
Thanks Martin, this video is very helpful!
Thanks, this video helped me alot!
Happy to hear that the video helped!
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
Would've also been very useful with identical gcloud cli commands!
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.
But it's still not in GA right? Is it still safe to use on production?
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.
!
Hello, how to handle ssh key during building docker image for Cloud Run? SSH key is for private Git repository.
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
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!
We currently calling the api during the init phase our app and exporting it to env. Is there any issue with it??
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.
wow. really cool stuff
Very good 👏👏🚀
It's so helpful because of what I'm doing.
I'm glad to hear that!
🙂
🙋♂️
Setting secrets as environment variables is pretty insecure and bad practice though. You should definitely avoid doing this!
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.
Great, usually i create a secret.yaml in gke
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.