Adding trusted information to puppet manifests

[Andy Parker]

In issue #19514 (https://projects.puppetlabs.com/issues/19514) there
is some discussion about adding some trusted information to the puppet
manifests. Chris Spence has provided a suggested solution, but he
wasn't sure about it. It adds a topscope variable called
"servernodename" that contains the name that the node has checked in
with, which is validated against the certificate.

The proposed solution fits this one particular use case, but has the
drawback of continuing the use of topscope for different purposes.
There has been a bit of discussion between Patrick, Eric, and myself
about this and we batted around a couple of ideas:

* Create a pseudo-class, like settings, for trusted data
* Use these topscope variables
* Create a topscope hash for trusted data

The first seems kinda nice, but has the issue that class scope lookups
leak topscope.

> bundle exec puppet apply -e '$foo = 1 notice($settings::foo)'
Notice: Scope(Class[main]): 1
Notice: Finished catalog run in 0.04 seconds

This means that it would be very easy to use something that you think
is trusted, but it turns out you are actually using the untrusted top
scope fact.

The second (topscope variables) have the problem, that there is
nothing unifying them into a common whole that calls out what all of
the trusted data is. It also has the drawback of creating an ever
growing set of variables that will conflict with people’s manifests.

The third option probably turns out to be the best. It gives us a
place to add more trusted information over time without having to
worry about clobbering manifest data. It doesn’t leak data from other
sources. It also fits with normal data structures and data structure
manipulation functions that exist.

So in order to get the trusted name we should create a top level hash
named “trusted”, with a key called “nodename”.

I think that this should be done without modifying the Puppet::Node
class/object and instead we just inject this one top level variable in
the compiler.


--
Andrew Parker
an...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

Join us at PuppetConf 2013, August 22-23 in San Francisco -
http://bit.ly/pupconf13
The first 150 tickets sold will be available at a 35% discount - register now!

[Peter Meier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> So in order to get the trusted name we should create a top level

> hash named �trusted�, with a key called �nodename�.

I think this a good idea. However, I don't really like the name, I
think it's not specific enough and is confusing for people who do not
understand, why this a trusted value while facts aren't. But I don't
have something better to propose.

Maybe we should think a little bit more about what kind of data should
go into that hash. Yes trusted data, but maybe we can find a better
description for it that makes it more unique and more specific.

> I think that this should be done without modifying the
> Puppet::Node class/object and instead we just inject this one top
> level variable in the compiler.

And we need to ensure, that it can't be overwritten by any client
sending a fact called trust. But I think that's quite obvious ;)

~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFhYXoACgkQbwltcAfKi3+UfwCZAVyqjJ2q2gNd5XrRC+dLQcrL
7+IAoKQq7pu7+YurzoyHiJtbd5CSAZC6
=BzkF
-----END PGP SIGNATURE-----

[Erik Dalén]

I don't really see how they conflict as variables in people's manifests will be in class scopes and facts are in top scope.

But I agree that it will make it trickier to know what is trusted and what isn't as there's nothing distinguishing them.

>
> The third option probably turns out to be the best. It gives us a
> place to add more trusted information over time without having to
> worry about clobbering manifest data. It doesn’t leak data from other
> sources. It also fits with normal data structures and data structure
> manipulation functions that exist.
>
> So in order to get the trusted name we should create a top level hash
> named “trusted”, with a key called “nodename”.

Hmm, not sure about the name "trusted", maybe "server" as it is data set by the server and not the client?

Also, will this still be set when running puppet apply? Of course it won't be trusted or server set then, but might be nice for compatibility.

>
> I think that this should be done without modifying the Puppet::Node
> class/object and instead we just inject this one top level variable in
> the compiler.
>

Yeah, there's some issues to think about with custom auth.conf settings though. Like if you allow other certs to access catalog or node objects, or even unauthenticated access to them.

--
Erik Dalén

[Erik Dalén]

Actually, on second thought it would be good if this was usable in hiera hierarchies. Will that work with a value in a hash?

Can you do something like '%{trusted["nodename"]}'?

--
Erik Dalén

[Andy Parker]

On Sun, Apr 7, 2013 at 5:07 AM, Peter Meier <peter...@immerda.ch> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> So in order to get the trusted name we should create a top level

> hash named “trusted”, with a key called “nodename”.

I think this a good idea. However, I don't really like the name, I
think it's not specific enough and is confusing for people who do not
understand, why this a trusted value while facts aren't. But I don't
have something better to propose.

We batted around a few here as well and didn't come up with anything better :)

 

Maybe we should think a little bit more about what kind of data should
go into that hash. Yes trusted data, but maybe we can find a better
description for it that makes it more unique and more specific.

I was thinking that we could put other things about the certificate (subject, etc.). I was thinking that we might even have a way for users to define extensions to add site specific data.

 

> I think that this should be done without modifying the
> Puppet::Node class/object and instead we just inject this one top
> level variable in the compiler.

And we need to ensure, that it can't be overwritten by any client
sending a fact called trust. But I think that's quite obvious ;)

Maybe obvious but a good thing to test :)

 

~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFhYXoACgkQbwltcAfKi3+UfwCZAVyqjJ2q2gNd5XrRC+dLQcrL
7+IAoKQq7pu7+YurzoyHiJtbd5CSAZC6
=BzkF
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To post to this group, send email to puppe...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Andy Parker]

On Mon, Apr 8, 2013 at 4:42 AM, Erik Dalén <erik.gus...@gmail.com> wrote:

Actually, on second thought it would be good if this was usable in hiera hierarchies. Will that work with a value in a hash?

Can you do something like '%{trusted["nodename"]}'?

Hiera doesn't support that kind of lookup....

 

--
Erik Dalén

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To post to this group, send email to puppe...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Erik Dalén]

On Monday 8 April 2013 at 18:44, Andy Parker wrote:

> On Mon, Apr 8, 2013 at 4:42 AM, Erik Dalén <erik.gus...@gmail.com (mailto:erik.gus...@gmail.com)> wrote:
> > Actually, on second thought it would be good if this was usable in hiera hierarchies. Will that work with a value in a hash?
> >
> > Can you do something like '%{trusted["nodename"]}'?
>
> Hiera doesn't support that kind of lookup....

Well, that would be good to fix in hiera anyway for structured facts support.

--
Erik Dalén

[Sean Millichamp]

On Sun, 2013-04-07 at 14:07 +0200, Peter Meier wrote:
> > I think that this should be done without modifying the
> > Puppet::Node class/object and instead we just inject this one top
> > level variable in the compiler.
>
> And we need to ensure, that it can't be overwritten by any client
> sending a fact called trust. But I think that's quite obvious ;)

I like the overall idea being discussed, but perhaps another /
additional approach would be to put facts in their own variable too.

Instead of $::operatingsystem
You have $::fact['operatingsystem']

It would be easy to provide backwards compatibility (just expose both
names) and also easy to provide a configuration option for a
transitional period. Then it would be simple for people to remember: if
you are grabbing data from $::fact, treat it as untrusted.

Just a thought...

Sean

[Eric Sorenson]

Thanks for this Sean, would you mind taking a moment to comment on the section in ARM-5 regarding this? I'm curious especially what you think about this top-level hash compared to the alternatives.

https://github.com/puppetlabs/armatures/blob/master/arm-5.structured_facts/structured_facts.md

On Apr 10, 2013, at 4:13 AM, Sean Millichamp <se...@bruenor.org> wrote:

> I like the overall idea being discussed, but perhaps another /
> additional approach would be to put facts in their own variable too.
>
> Instead of $::operatingsystem
> You have $::fact['operatingsystem']

Eric Sorenson - eric.s...@puppetlabs.com
#puppet irc: eric0

[Brice Figureau]

Hi Sean,

That's something I'm trying to push for more than 1 year, you'll find my
attempt and its counter-arguments in the following bug:

https://projects.puppetlabs.com/issues/11915

Somehow this wasn't that well received :)
Feel free to upvote accordingly.
--
Brice Figureau
My Blog: http://www.masterzen.fr/

[Brice Figureau]

On Thu, 2013-04-11 at 22:53 -0700, Eric Sorenson wrote:
> Thanks for this Sean, would you mind taking a moment to comment on the
> section in ARM-5 regarding this? I'm curious especially what you think
> about this top-level hash compared to the alternatives.
>
> https://github.com/puppetlabs/armatures/blob/master/arm-5.structured_facts/structured_facts.md
>

I must admit I haven't closely followed those last months puppet
development, and especially the ARM system. So my question (after
reading arm-0) is how do we comment on this ARM-5 proposal?

--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!

[Eric Sorenson]

On Apr 12, 2013, at 2:11 AM, Brice Figureau <brice-...@daysofwonder.com> wrote:

> I must admit I haven't closely followed those last months puppet
> development, and especially the ARM system. So my question (after
> reading arm-0) is how do we comment on this ARM-5 proposal?

Hi Brice -- I think everyone is still trying to figure out what works best. You can either
(a) ask on the mailing list as normal, since every ARM should have at least one mailing list thread about it started by the author
(b) open a github issue (and maybe a pull request) if there is something you want to see added or changed in the body of the arm
(c) add a github line comment on the commit / pull request like you would for code review if that fits best