81–90 of 214 posts
Earlier quoted context omitted.
Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
Disclaimer: I worked on it.
Earlier quoted context omitted.
FWIW I have a /private directory in the root of all vhosts, so it looks like: /srv/www/domain.com/public_html/ |--------->/private/ |--------->/logs/ |--------->/tmp/ Anything stored in /private/ is not publicly accessible by the web server process, but can be read or written by anything running under the user's username. It's specifically for storing things like configuration files. I think this should be standard p…
Thanks for the tip. How do you keep passwords and keys in sync amongst team members safely?
Earlier quoted context omitted.
Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
It's relatively common to provision secrets with configuration management software like Chef/puppet/ansible/etc using, e.g. Chef's encrypted data bags.
Another slightly heavier-weight solution with some nice properties is to use a credential broker such as Vault: https://www.vaultproject.io/
Earlier quoted context omitted.
Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for logging-in, hashing the passwords, making sure your server can only be reached via SSH, adding firewalls, filters, etc. etc. Then some hacker in Eastern Europe comes along (or some beginner at the NSA/GCHQ) and finds out that your .git is exposed and somehow gains…
It's really bad out in AppSec land
Earlier quoted context omitted.
Better yet: $ rm -rf .git/ It's way safer to delete the repo history from the production server than to rely on Apache rules copied from a forum.
Better better yet, don't use git to move code from test to prod. Use rsync, and exclude .git and other nuisance files. Unfortunately I can't seem to convince anyone that this is good practice. :-(
rsync --checksum --ignore="..."
rsync is even easier than SSHing to git pull, or opening up a pushable repo on a server. For once the simple approach is clearly better!
Earlier quoted context omitted.
Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
I typically handle this by versioning a `config.example` file, which includes all the necessary config keys an application expects. The example file defaults these attrs to various strings meant to show they are examples only. I include instructions to copy the `config.example` to a `config.yml` (or some other appropriate extension), and replace the values as necessary. The `config.yml` file is specifically excluded in the `.gitignore` file. The application will only load the `config.yml` file when started, so I also ensure to raise a descriptive error informing team members when they are missing a local `config.yml`.
This allows the `config.example` to also serve as a self-documenting config for the application, as comments can be included that identify and explain each of the config keys and their purposes.
Someone on StackOverflow says this will tell nginx not to serve hidden files. location ~ /\. { return 403; } My question - do I need to put this once at the top of my configuration file and all it good or does it need to go into multiple places in the nginx config? It would be great if there was a simple, universal way to say to nginx "don't serve hidden files from anywhere under any circumstances".
apt-get install zutils
zgrep -r "\.git" /var/log/nginx/The author doesn't give any suggestions for alternative ways to deploy. What are the best practices here? What should operators that currently deploy this way do instead?
1. Configure your webserver to hide common directories and files.
2. Don't store passwords / credentials in version control. 2a. If you use a test suite, add a test to verify this.
3. Have a make step that builds the deployment content into a separate directory. (e.g. a gulp deploy task)
4. Rsync the deploy content to your destination server.
Instead of 4, more complex systems (with multiple servers, libraries, etc) use Docker to build an image from your deloy content.