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?
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.
> 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?
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
On Thu, May 21, 2009 at 4:42 AM, Glenn Rempe <gl...@rempe.us> wrote:
> 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.
> The primary benefit here being that you don't store the password in
> your SCM.
> Glenn
> On May 20, 6:27 pm, "S. Robert James" <srobertja...@gmail.com> wrote:
> > 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?
> 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
> On Thu, May 21, 2009 at 4:42 AM, Glenn Rempe <gl...@rempe.us> wrote:
>> 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.
>> The primary benefit here being that you don't store the password in
>> your SCM.
>> Glenn
>> On May 20, 6:27 pm, "S. Robert James" <srobertja...@gmail.com> wrote:
>> > 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?
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.
> 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?
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?
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, 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?
|
