On 10/01/2012 02:05 PM, Jeff Janes wrote:
Who are those people? Do they have administrative access to the 20
machines? If so, it seems to me that the game is already over. If
not, what mechanism do you use to keep them out? Perhaps that
mechanism could be extended to cover this case as well; or use
host-based authentication on the PG server.
Anyone from a NoC guy, DBA, or systems admin. In the case of the systems
admins, yeah, they have root and could see everything anyway. But
someone just administering Nagios settings would get access to .pgpass
if we put it into bcfg2. Yuck. :)
Host-based works if you want everything to work under the super-user
admin user. That's not necessarily true for some one-off utility that
should have a better sandbox around. Creating a whole user on the box to
run one or two tools seems a bit silly as a work-around. It doesn't
solve connections that *must* be remote, such as replication, or
third-party tools which connect over TCP like Bucardo, or Slony, either.
Each of these have a specialized user on our systems, and use .pgpass to
avoid unnecessary password proliferation.
I'm not familiar with those tools, at least not at an administrative
level. Don't they allow tiered access so that some things can have
stricter access controls?
No. :(
I can't remember about Puppet since I haven't used it in so long, but
bcfg2 is basically just a giant directory structure, and we put ours in
GIT for safekeeping and to track changes. Implementing ACLs in GIT is a
bit of a PITA, so we're avoiding that as a last resort.
I don't see how that can work. It sounds like an infinite regress.
How do you distribute the key without exposing it?
No idea. That's why I asked. ;)
I figured we can't be the only company out there with a bunch of servers
who is tired of manually copying a .pgpass file everywhere, and someone
has since devised something workable. It doesn't hurt to ask before I
spend a bunch of time building something. I try to avoid NIH syndrome
when possible.
I'm fine with that answer, but I had to at least broach the subject.
Thanks, Jeff. :)
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@xxxxxxxxxxxxxxxx
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
