1

It seems like common knowledge that it's a good practice to keep secrets files (anything containing passwords, API keys, etc.) checked out of your git repository (Indications here, here, here, here and there are many more)

Why?

Community
  • 1
  • 1
Marco Prins
  • 7,189
  • 11
  • 41
  • 76
  • Here is a dictionary entry for the word "secret": http://www.dictionary.com/browse/secret . – Sverri M. Olsen Nov 15 '16 at 15:17
  • Note: "checked out of" is the wrong phrase. Just say "out of". Being "checked out of" would imply that they are *in* the repository in the first place. Anything inside the repository is, by definition, *not* secret. – torek Nov 15 '16 at 15:20

1 Answers1

1

This enhances security by making the values of these "secrets" (and other password/security/token related values) only known within the production environment, as opposed to anyplace the repository is checked out. Each environment (for example, local development, development server, staging/demo server, production environment, etc) should have its own separate configuration of authentication or security parameters, if possible, and these should be configured within the local environment, and not stored in the application's code itself.

Even if your repository is private, it is still not safe. Developers come and go. Operations people come and go. Project management comes and goes. You might have some third party contractors with repo access. A big enough project tends to have lots of actors working on it over time, and it isnt necessary for any of them to know the production configuration values (except perhaps the ops folk). Even with a private repository, there is still a security risk for exposing secret keys/values to anyone with repo access.

Todd
  • 2,824
  • 2
  • 29
  • 39
  • What I've seen quite a lot is that people need some of these keys in development and then copy a version of the secrets to their computer anyway. If you need some of these keys in dev, does that mean you're doing something wrong? – Marco Prins Nov 15 '16 at 15:26
  • @MarcoPrins It depends on how important the service is that uses those keys, and your experience and expertise will be required to make that judgement. It could be ok to get moving fast on your new MVP project to store some less-critical keys there while you coordinate with developers and work towards creating a dev-only version of that service, and eventually migrate to a separate environment config file for each env. Just dont make it a long term plan to store this info in the app, and dont store critical (financial? prod db creds?) service auth data ever. – Todd Nov 15 '16 at 15:50