Security of facts (aka: who can see my facts?)

[Arnaud Gomes-do-Vale]

Hello,

I have a module for deploying an application which relies on an
(external) MySQL database. Here is a simplified version of the relevant
parts:


class myapp::database {

$db_user = my_db_user
$db_name = my_db_name

# generate_db_passwd is a custom script, basically a wrapper around
# "openssl rand"
exec { '/usr/local/bin/generate_db_passwd':
creates => '/etc/facter/facts.d/myapp_db_passwd.yaml'
}

if $myapp_db_passwd {
# This will be collected on the MySQL server.
@@database_user { "${db_user}@${::fqdn}":
ensure => present,
provider => mysql,
password_hash => mysql_password($myapp_db_password),
}

@@database_grant { "${db_user}@${::fqdn}/${db_name}":
privileges => ['all'],
provider => mysql,
}
}
}


Now I'm not sure this is really secure. The custom fact myapp_db_passwd
may be disclosed to local users of the app server if they have the
correct access rights (nothing to worry about, these are typically the
application admins). It is sent to the puppetmaster and stored in
PuppetDB. Can anyone fetch it from here?

--
A

[Chuck]

I wouldn't put any sensitive information in a fact, unless the only people with access to PuppetDB and your Servers are admins who already have access to this information.  But even then I still wouldn't do it.

At this time I would say the best route would be something like hiera.

[Arnaud Gomes-do-Vale]

Chuck <css...@gmail.com> writes:

> I wouldn't put any sensitive information in a fact, unless the only people
> with access to PuppetDB and your Servers are admins who already have access
> to this information. But even then I still wouldn't do it.

That's more or less the conclusion I arrived at, except I can't find any
real reason not to trust the Puppet ecosystem with my facts. I mean, my
servers and PuppetDB are secure (well, they should be, unless I screwed
things up), inventory service is turned off on my dashboard, so I should
be safe, shouldn't I?

> At this time I would say the best route would be something like hiera.

Except AFAIU Hiera doesn't allow me to generate values on the client
node. The whole point of my fact-base approach is that I don't want to
manage database passwords, they just have to be long-enough random
strings.

--
A

[Virender Khatri]

puppetdb also expose facts etc. details via api calls too, you might want to check that out.

take a look at hiera-gpg puppet module to store hiera variables in encrypted form, it will provide enough security on hiera/git side.

A

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/y9hzjpkfdw2.fsf%40licencieux.ircam.fr.

For more options, visit https://groups.google.com/groups/opt_out.

[Tom Noonan]

But that doesn't address the concern that you can't auto generate
values and store them in Heira, as Arnaud mentioned. Is our
understanding on this flawed? I see a Puppet source on
http://docs.puppetlabs.com/hiera/1/data_sources.html#puppet, but that
just says "Coming soon."

My solution thus far, for file based passwords like Bind keys and Bacula
passwords, has been to generate passwords on the puppetmaster
and then pull the values into templates via file reads. This relies on
the filesystem security of the puppetmaster, but if that is gone you're
pretty well hosed anyway. The generation script on the puppetmaster
handles password aging and regeneration. Not the most graceful
solution, but it works well for me. If there is a better way I'd love
to hear it, however.

[jcbollinger]

On Monday, November 4, 2013 10:36:01 AM UTC-6, tujwww wrote:

puppetdb also expose facts etc. details via api calls too, you might want to check that out.

take a look at hiera-gpg puppet module to store hiera variables in encrypted form, it will provide enough security on hiera/git side.

I would strongly recommend securing access to PuppetDB's REST API.  I think by default it is accessible only from the host machine, and that may be good enough, but check that I'm right.  Certainly your master should run on a machine that is secured to only personnel authorized to have the information that it serves.

I cannot recommend using hiera-gpg with Puppet 3 if you make heavy use of parameterized classes (which is typical these days).  Hiera-gpg will decrypt its data file not only for each datum stored therein, but also for every hiera lookup miss (to verify that it is indeed a miss).  Puppet 3 performs a hiera lookup for at least each class parameter that is not assigned in a class declaration, and that can exact an excruciating performance penalty when many of those lookups fall through to hiera-gpg.


John

[jcbollinger]

On Monday, November 4, 2013 6:52:51 PM UTC-6, Tom Noonan wrote:

But that doesn't address the concern that you can't auto generate
values and store them in Heira, as Arnaud mentioned.  Is our
understanding on this flawed?  I see a Puppet source on
http://docs.puppetlabs.com/hiera/1/data_sources.html#puppet, but that
just says "Coming soon."

My solution thus far, for file based passwords like Bind keys and Bacula
passwords, has been to generate passwords on the puppetmaster
and then pull the values into templates via file reads. This relies on
the filesystem security of the puppetmaster, but if that is gone you're
pretty well hosed anyway.  The generation script on the puppetmaster
handles password aging and regeneration.  Not the most graceful
solution, but it works well for me. If there is a better way I'd love
to hear it, however.

It is relatively easy to write a custom hiera back end, in which you can use whatever code you like to lookup or generate a value for any given key (or not).  You could use such a thing to integrate password generation and recall (and even encrypted storage, if desired) into hiera.


John

[Arnaud Gomes-do-Vale]

jcbollinger <John.Bo...@stJude.org> writes:

> It is relatively easy to write a custom hiera back end, in which you can
> use whatever code you like to lookup or generate a value for any given key
> (or not). You could use such a thing to integrate password generation and
> recall (and even encrypted storage, if desired) into hiera.

Thanks, I had not thought about a custom Hiera back-end but that makes
sense.

--
A