Re: Securing .pgpass File? - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Securing .pgpass File?
Date
Msg-id 20121002211954.GD11163@svana.org
Whole thread Raw
In response to Re: Securing .pgpass File?  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: Securing .pgpass File?  (Shaun Thomas <sthomas@optionshouse.com>)
List pgsql-general
On Mon, Oct 01, 2012 at 11:02:39PM -0000, Greg Sabino Mullane wrote:
> > Has anyone come up with a good solution for distributing a .pgpass file
> > that doesn't expose it to anyone who has access to the distribution
> > mechanism?
>
> No, you cannot easily keep it in version control/puppet securely.

In my experience we've handled this in a few ways:

- Postgres has ident auth, which avoids the use of password for local
  accounts, which helps in a lot of cases.

- Puppet has the concept of an "external node classifier". This is a
  script which gets called with the name of the node, and can return
  data which is then available to the puppet run.  So the password is
  stored elsewhere (in our case Foreman) which means you only need to
  worry about the people who can access the Foreman server or the
  puppet server.  Note people who can check arbitrary things into the
  repo and view the puppet output would be able to get the password by
  printing it to the debug log.

- Punt. Check in the password but set the access controls so it only
  work for very few IPs, then you only need to worry about people who
  can log into *those* machines.  Which is controlled by public SSH
  keys which you can check-in safely.  Not super safe, but for
  read-only accounts for e.g.  nagios might be ok.

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer

Attachment

pgsql-general by date:

Previous
From: Chris McDonald
Date:
Subject: Re: stored procedure multiple call call question
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Thousands of schemas and ANALYZE goes out of memory