Database Password best practices

[S. Robert James]

We have our cap deploy setup to take a new app server from zero to
working, all automatically.

One issue we're getting stuck with is: Where to store the database
password?

I'll show you what we thought of, and why we don't like it. I'm sure
some of the pros here have already grappled with this, so I'd like to
here what you say.

1. Store in cap deploy files.
PROBLEM: We don't want every developer who ever had access to cap
deploy source to know the passwords.

2. Store in file on each server.
PROBLEM: This would require manual setup of a new server.
PROBLEM: Even if we accept to do it manually, in the course of doing
so, it's quite likely that the password will get emailed around.
"Anyone remember the pw to setup a new server? The box is down and I
need to do a replacement quick."

3. Use a nonpassword system
Windows supports authentication via user account on a known machine.
I'm not sure how it works, or how secure it is. Haven't found any
simple, secure way to do this via Linux. The ideal would be to tell
the database server "If user rails_app on any of the local machines
wants to connect, they don't need a password." But I'm not sure if
there is a simple and secure way to do this.

4. Use some type of encryption
I'm not sure how to use this to solve problems. The key needs to go
somewhere, and so we're back to square one, on where to store the key.

What do you do? Is there a best practice? What do the large
enterprise / J2EE shops do?

[Glenn Rempe]

You might take a look at the Thoughtbot Suspenders template Rails
app. It contains a deploy.rb that prompts you for a db password when
you run cap deploy:setup and stores that password in a shared file on
the remote DB server.

http://bit.ly/QcrOl

The database.yml file is then setup to pull the password from this
shared file:

http://bit.ly/svm27

The primary benefit here being that you don't store the password in
your SCM.

Glenn

[Simone Carletti]

I created a standalone recipe months ago.
You can grab it from gist, save the file in your lib folder and load it from deploy.rb.
http://gist.github.com/2769

It provides a couple of additional options.

-- Simone

--
Simone Carletti

Site & Blog: http://www.simonecarletti.com
Email: wep...@weppos.net
LinkedIn: http://linkedin.com/in/weppos
Nick: weppos | Skype: weppos

[Lee Hambley]

Or,

You can condigure passwordless access (tricky?) from the local machine only

GRANT select,delete,update, (anything else you need) ON `` TO `railsuser`@localhost;

FLUSH PRIVILEGES;

(by excluding the IDENTIFIED BY 'passwd' it should be a passwordless account)

I'm not condoning this practice, work with it in line with your company's policy on security & passwords!

- Lee

2009/5/21 Simone Carletti <wep...@gmail.com>

[Donovan Bray]

We use a file that's ignored by the scm and we check a template with
bogus passwords into our deploy scripts. This let's developers use the
deploy scripts to setup their own environments without divulging
production env secrets. Ops maintains the official secrets file and
it's kept in a central location that only ops has access to.

On May 20, 2009, at 6:27 PM, "S. Robert James"

[S. Robert James]

On May 21, 10:38 am, Donovan Bray <donno...@gmail.com> wrote:
> We use a file that's ignored by the scm and we check a template with  
> bogus passwords into our deploy scripts. This let's developers use the  
> deploy scripts to setup their own environments without divulging  
> production env secrets.  Ops maintains the official secrets file and  
> it's kept in a central location that only ops has access to.

How does the app get access to it? Is it NFS mountable in a known
location, or do ops manually copy it locally?

[Donovan Bray]

The file is kept with the deploy scripts and tasks reference the
variables kept in the secrets file. For example we have a task that
generates the database.yml based on an erb template and copies it out
to the deploy location. The only place that username password exist
on the remote server is in the generated database.yml. The only place
that username and password exist in the deploy scripts is the secrets
file which is gitignored and only a sample checked in.

On May 21, 2009, at 8:34 AM, "S. Robert James"