How to store CLIENT_KEY + CLIENT_SECRET

Storing secrets in database just moves the problem around – how do you store the credentials for accessing the database?

I can't recommend https://doppler.com/ enough!

This is possibly going to depend on how/where your app is hosted.

For example, if you're hosting your app on AWS with EC2, you can easily store your secrets in an S3 bucket, encrypted with KMS. Your EC2 instance would then inherit the role capable if interacting with the proper KMS key to fetch, decrypt, and inject your secrets into your apps runtime (could be a file on disk, environment variables, etc).

The "ideal" solution (at least in my mind) is to use something like Hashicorp's Vault. Vault can securely store any data you want, but can also integrate with other services (like your database) to manage credentials and even rotate them on set intervals. Vault is going to be one of the most flexible and comprehensive options, but also likely the trickiest to set up since it is so customizable.

Where do you host?

Also since you're learning about not comitting secrets to version control, I highly recommend you familiarise and follow 12-Factor App

Using a tool according to this situation is more acceptable I guess. You can use Keywhiz, Vault or any other Secret manager to provide ENVs but creating your own way can cost you when you are under heavy load. Also you can automate things when you use proper tools.

You definitely don't want to keep the credentials in a db regardless of it being encrypted at rest. The same problem remains: you need to use credentials to connect to that database and those would need to be in your repository or somewhere else in plaintext.

The answer for this question really varies depending on your architecture and stack. If you're on an EC2 in AWS, you can use SecretsManager and reference the keys (of the SecretsManager key/value pairs) in your code, and provide access to the SecretsManager object via IAM role access to the EC2 instance.

If you have time to set up HashiCorp's Vault, you can use that as an alternative to AWS' secrets manager. The set up for Vault is a bit more complex and requires some time to get familiar with it.

With Python apps you can use https://pypi.org/project/python-dotenv/. I'd use Ansible to create a template for the dotenv file, populate it via my vars and secrets at deploy time, and then the app, during runtime, will parse the dotenv file into environment variables which it will then use while running. So then, no worries if your server restarts or whatever. As long as your app is enabled to run on startup, it will read the persistent dotenv file and start normally. The secrets are encrypted within the repo, and the key to decrypt them for deployment can exists on your CI/CD server.

Hopefully that makes sense...

What cloud provider are you using? Most have a solution for storing/retrieving secrets.

This isn't the first time I've heard this question, I always go back to this advice when storing credentials: article on storing credentials.

TL;DR encrypt them in source code, storing them anywhere is going to cause problems.

We use EnvKey.com for storing and managing our secrets across our projects. Best thing we ever did. We can bring developers on and remove them from a project without impacting security (They never see the keys). Do it from day one and key management will be simply a no brainer that you never have to worry about again.

https://www.envkey.com/

(Not affiliated, just a very happy user)

You can use the .gitignore file to avoid mixing development data with production data.

You can use a script that uses git to build instead of doing it manually. Your secret data can be added to the app at build time - it should be hidden in files on the server. You can also use templates and write config files at build time with the sensitive data, then secure them with file permissions.

Using git manually takes time and is prone to errors—You may forget to do something important when you are in a hurry. Writing the same git, chmod and chown commands over and over again is great for people who like to show off their command line skills... It's better to use a build script that will also secure everything.

How does your script know the environment it is working in (dev, test or production)? You can use a hidden file with the name of the environment so you don't use sensitive data when you don't need it.

A persistent secure storage is basically what you'd want to use for that.

I would use a dedicated service for that, something like Google Cloud's Secret Manager https://cloud.google.com/secret-manager.

Some platforms (Heroku for example) let you safely store env variables as well.