There are two related concerns on this concept: * protecting your credentials in source code * protecting your credentials on the server
For the first concern, I like to use encryption management tools like Blackbox (https://github.com/StackExchange/blackbox) With an encryption management system, you "enroll" certain files to be managed by the system. Instead of saving the plaintext files to version control, the encrypted files are saved. Approved users (via GPG keys in blackbox) are able to decrypt or edit (decrypt+edit+encrypt) the files. **When a project is deployed to a server, the files are decrypted and the plaintext version is left on the server** For the second concern, I've never seen a foolproof way to safeguard the plaintext "secrets". You can force stuff into environment variables, but hackers can still get to those. You can trash files after starting an application... but then you can't restart the application unless you have an external service that logs into the machine and decrypts/reloads/deletes. I would focus on safeguarding your secrets from versioncontrol, and constructing them in ways that are prepared for leaks (for example, rotating credentials periodically, using ip whitelisting to limit where they can be used, using ACLs on the various services to limit what each credential can do) -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/5c0f526f-299b-44bc-827e-1e0b41813586%40googlegroups.com.
