4

I'm working on upgrading a "legacy" infrastructure where a handful of PHP, Rails and Perl (CGI) applications are in use. Historically, these applications have been written with the database credentials sprinkled into all the source code as program variables.

We are discussing ways to change this. One proposal suggests moving all DB creds to the Apache /etc/apache2/envvars file. Another proposal suggests use of Hashicorp's vault (don't quite fully understand how this beast works).

The envvars method seems better, but I assume this would mean that any compromised application would have full access to any other applications DB creds. I'm wondering if a better approach would include some sort of partitioning for applications where (bad example, but it happens) Bob's compromised 'todo list' wouldn't neccesarily compromise the credentials for an HR application by way of Apache environment variables.

Vault is.. weird. From what I can tell, it creates temporary DB credentials in the database. I don't fully understand how it works, so I can't tell if it's a good fit.

What's the best practice for protecting DB credentials on a web server? Anything is better than leaving them in source code but if we're going to make a big change here, I'd rather not have to do it again due to misinterpretations. I've looked over links here and here with little discussion about it.

  • environment vars are a common method. you can also import a single file with all the needed creds in it, and mark that one out of git. you could also use some sort of IPC like redis to share PWs – dandavis Sep 7 '17 at 19:17
2

There're many tools/systems that you can use for securing production secrets. Many of them will leverage some kind of KMS (key management system) and/or HSM (hardware security modules) to store the master key(s) that can be used by aplications to access secrets in production environments. See some of the great open-source solutions.

For example Lyft's Confidant is a secret management system that stores encrypted payloads in DynamoDB. The master key(s) are managed and access controlled by AWS KMS. HashiCorp Vault is also a solid option (but perhaps the feature set is too comprehensive). It offers similar set of features plus higher-level features such as auto mysql DB credential rotation. You should be able to pick'n choose based on your use cases and production setup.

1

Vault is a good solution of you are looking to manage credentials as well just keep them secure as it has full lease and date/time constraints built in.

In this instance you are just looking to store dB credentials envars are fairly standard just don't commit the envar file to source control.

Also bear in mind all these dbs have bound interfaces so it is as important to make sure you correctly bind to either localhost or a fixed IP range that is also protected/filtered by a firewall. That way even if the dB PW is exposed they still could not get remote access.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.