On Friday 5 April 2013 at 20:49, Andy Parker wrote:
> 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. 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 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
