0

I'm using Cloud Run for the backend of a project I'm working on, in part due to its generous free tier (2 million requests per month, free). But the services require some secret values (database password, Oauth secret key, etc.), so I have followed the Google recommendation to store these values in Google Secret Manager and load them as environment variables through Cloud Run.

However, the free tier of Secret Manager is much more restrictive, at only 10,000 free access operations per month. If cloud run spins up a container for nearly every request, it seems as though it must access secrets at approximately this rate too, drastically reducing the free tier quota.

So my question is, how should I set up the environment variables for my Cloud Run instance without destroying the free tier that made the platform so attractive in the first place? Simply putting the database password etc. in the environment variables seems like a bad idea, but it's unclear to me how much of a security risk that actually poses given that the project is a student website that doesn't contain any sensitive personal information in the database, and also given that a user with administrative access to the Google Cloud console could access the secret values from secret manager anyway.

Geno Racklin Asher
  • 101
  • 1

2 Answers2

2

Pay for Secret Manager. Those hardware security modules and compliance attestations to implement it are not free.

Or come up with a different solution. Different secret management software, less sophisticated store secrets in plain text files, different application deployment model. Which may not be compatible with exclusively using the managed Cloud Run product.

unclear to me how much of a security risk that actually poses given that the project is a student website that doesn't contain any sensitive personal information in the database

Possibly a small risk to your organization in the big picture, but being careless with secrets is a bad habit.

Every application, even small ones in a simple compliance environment, deserves some level of protection of secrets. At least restricted access configuration files. Definitely not embedded into application code.

a user with administrative access to the Google Cloud console could access the secret values from secret manager anyway.

Hiding data from authorized administrators is not the point of secret systems. Any access or deletion of secrets is logged. Which in theory enables catching disclosing these to an attacker, or use of old versions beyond the time when they were supposed to be rotated.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
1

To keep your costs low you need to figure out what the best approach is in order to keep your containers up or allow it to be shutting down.

In short, Cloud Run containers can be idle for up to 15 minutes before shutting down. Maximizing its up time tends to avoid extra requests to Secret Manager.

You can configure a monitoring system to send requests to your app every 10 minutes, in your most accessed hours, in order to keep your containers up, and send no requests in less accessed hours in order to leave it to shut down at night.

This way you can minimize containers starts and cold starts during business hours, and allowing them to shut down at night to save costs.

surfingonthenet
  • 695
  • 2
  • 6