Puppet users - Nov 2013 - Security of facts (aka: who can see my facts?)

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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/y9hhabsh3p2.fsf%40licencieux.ircam.fr.
For more options, visit https://groups.google.com/groups/opt_out.

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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f53cd860-f56b-4380-a94b-968f1abb144b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Chuck <csschwe@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

-- 
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+unsubscribe@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.

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.


On Mon, Nov 4, 2013 at 7:49 PM, Arnaud Gomes-do-Vale
<Arnaud.Gomes@ircam.fr>wrote:
> Chuck <csschwe@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
>
> --
> 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+unsubscribe@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.
>
-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAH3EniGR%3DaqDNT-jke8aP7AtpvPEtuHcgxGtbrEg1tOuWwpAKw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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.

On Mon, 4 Nov 2013 22:06:01 +0530
Virender Khatri <vir.khatri@gmail.com> 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.
> 
> 
> On Mon, Nov 4, 2013 at 7:49 PM, Arnaud Gomes-do-Vale
> <Arnaud.Gomes@ircam.fr>wrote:
> 
> > Chuck <csschwe@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
> >
> > --
> > 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+unsubscribe@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.
> >
> 
-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20131104185251.41e7c004%40vncBox.tjnii.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/525bbd6f-bea0-4751-b1a1-f4a00ba98b05%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1e7cd9de-3600-4da6-8295-971fdb5d6dc0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

jcbollinger <John.Bollinger@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

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/y9hd2mean2v.fsf%40licencieux.ircam.fr.
For more options, visit https://groups.google.com/groups/opt_out.