Never, under any circumstances should you put AWS keys into a file. Doing so introduces a major security risk and may expose them to the public. Do not put them in a file “just to test” or “just to try” to get around access denied warnings. If these keys are pushed to GitHub it is difficult to get them removed completely. These keys must only be entered as environmental variableslocally and Heroku environments. See below or talk to your alumni mentor for how to use them safely.
Extremely Important Part 2!!!!
This is a learning experience that uses real data. It is MUCH more important that you are careful and understand fully what you are doing rather than get a feature done. I would much, much rather you fail (for the moment) to complete a feature you planned for the sprint than expose sensitive data, login credentials, or keys used to connect to services and APIs. Maintain perspective. None of these projects must be completed “on time”.
Edge Guides has a comprehensive guide to common web application vulnerabilities and the ways that Rails (5.2) can be used to avoid them. Discuss this option with your alumni mentor.
Use Environmental Variables
Rather than use configuration files, you can set up environmental variables locally and in Heroku. See this brief overview on how to set up environmental variables in Heroku.
For development, using the dotenv gem might be your safest bet at this stage of each of your projects. Installation and usage are given in the environmental variables overview.
Upgrade to Rails 5.2
Rails 5.2 has a way of storing credentials through an encrypted file. The discussion is part of a long (and very good) article on web app security.
Upgrading your current code to Rails 5.2 would be ideal, except that you may encounter new issues whenever you change versions.
The most important thing is to be aware of what information you have stored locally that is sensitive and should not be put up on a readily accessible repo .. unless it is encrypted.
Using a Sandbox
According to Ian, many services provide a sandbox (i.e. play or development) mode via a separate set of credentials. When testing, use sandbox credentials or fake credentials (talk to your mentor about how to handle these seams during testing).
Alternatively, some services will let you limit credentials to performing certain actions or “read only” mode. Or allow you to cap the amount of activity.
Using VCR for Testing
If you are using VCR and the app has sensitive credentials, you need to check with your mentor so that your credentials don’t leak into your test data.
Things NOT to commit to GitHub
Try to avoid uploading real data to a repo, even if encrypted. Other files might be uploadable, if they are properly secured. Talk to your mentor about the best strategy for your team.
- Real data – yours or that of your community partners. Make sure that live databases are ignored by GitHub (use .gitignore)
- Keys to APIs
- Login credentials