Hi Eric, Thanks for your comments, those will be very helpful. See below for some answers/comments.
On 23/02/2015 06:18, Eric Sorenson wrote: > >> On Feb 16, 2015, at 2:01 AM, Brice Figureau >> <brice-pup...@daysofwonder.com <mailto:brice-pup...@daysofwonder.com>> >> wrote: >> >> Hi, >> >> Following a conversation I had with Kevin and Deepak at last Ghent >> Contributor summit about solving SERVER-111[*], I started working on a >> clojure port of the Puppet authorization system (since I wrote a large >> part of it, I felt I was kind of best placed to start this). >> >> For the moment all the code is hosted in its own project on my github >> account (because that was simpler than abusing another trapperkeeper >> project as a PR for repeated development): >> https://github.com/masterzen/trapperkeeper-authorization >> >> It's a work in progress with only the following working basic >> functionalities at the moment: >> * various ip, host, wildcard, regex, opaque, backreference authorization >> entries creation/matching (ACE) >> * authorization entry list (ACL) creation and matching >> >> All those features should be fully compatible with the way Puppet >> authorization system works. > > Hi Brice! This project is really cool, thanks for taking it on. I have a > few comments about requirements and design that I hope can save some > work and make it easier to include this upstream once it's done. Cool :) > I went back and surveyed redmine, jira, and ask.pl.com > <http://ask.pl.com> for bugs around auth.conf to see what people have > run into over the years > ( https://www.google.com/search?q=site%3Apuppetlabs.com+auth.conf&gws_rd=ssl > <https://www.google.com/search?q=site:puppetlabs.com+auth.conf&gws_rd=ssl> ), > and from those results plus recalling conversations with #puppet there > seem to be a few general categories that we should examine when > designing a replacement Definitely, I'm open to suggestions. > First, I don't think you need to try to make it compatible with the > existing auth.conf format. It's relatively easy to support, so that was my first target which also would allow forward compatibility for the puppet-server. In other answer to your e-mail Henrik mentioned HOCON. I'm a huge fan of HOCON (using it in my $work project since one of the very first release), I will definitely add support for it. I will post my HOCON format proposal here later this week. > It'd be good to take the opportunity to move > to a structured data format that is easier to read and write > programmatically, which addresses issues like Branan's > PR https://github.com/puppetlabs/puppet/pull/1353 where the goal was to > have different parts of the module codebase manage snippets of auth.conf. Well this PR was a bit more than that, I read the thread correctly. To solve auth.conf generation issue we could just allow to have an include directive (supporting glob'ing), allowing to read fragments with maybe the possibility to merge fragments with the same resource (since the allow/deny ordering is fixed and not based on the file ordering). I think HOCON supports include out of the box. > Second, the main UX problem w/ auth.conf seems to be difficulty tracking > down why a particular request is being denied. I think this has improved > over time but I know it's incredibly frustrating to just get the 403 > error on the client and not be able to check the master's logs to see > why each set of 'permit' rules was not allowed. So it'd be awesome to > start out with easy discoverability/debugging as first class objectives. The version I'm working on gives the exact same error message as the current Puppet version which gives the URI, the method, the incoming certname and IP address, along with the rule file name and line. I don't think we can do much better (feel free to let me know if there's information we should add in case of a deny). > (Meta-question: are we sure there's not an existing model -- either a > reusable codebase or simply a config syntax -- that we can use directly, > rather than reinventing a wheel? The ones I'm most familiar with are > apache mod_access and Netscaler content-switching rules, which aren't > great examples, but surely this problem has arisen before.) I've checked if there was java or clojure library to implement this, but couldn't find anything. In fact beside Apache, Nginx or TCPwrappers, I don't think there are lot of host based ACL systems out there. We can't really use the first two formats because those are very different than our use case (and cover lots of things we don't really need). The last one looks like auth.conf IMHO. > Last, as a quick summary of some functional requirements, I'd like make > sure an implementation: > - doesn't rely on puppet-specific paths and could be re-used across > other services like puppetdb (auth.conf has some implicit magic because > IIRC the rules do not see the environment part of the path) Yes that's the design I was aiming to, nothing related to Puppet. I planned to have a "puppet" mode to support environment, but not in the first release, and only if the puppet mode is activated. > - had clearer semantics around authorizing IPs vs certificates (just > aesthetically, the regexp backreferences from auth rules back into path > matching are not my favorite) and addresses PUP-1562 I've already added the regexp backreference, which IMHO brings the nice feature of writing rules to enforce only one host can access a specific resource without having to write one rule per existing host. The current auth.conf supports 'allow-ip' for IP, and 'allow' for certnames. I followed the exact same mechanism. I mostly followed the current Puppet source code, so I'm afraid the current version will also fail at PUP-1562 (but since it's not strictly a line-by-line port, maybe it works, I need to check). > - resolves the confusion about access control in fileserver.conf > overlapping with auth.conf (see PUP-1237) I would say it's not my business :) I'm dealing with a library that will be used in Puppetlabs clojure products, which is not related to fileserver.conf at all. At its worst case we could read auth.conf. The core ACL part can also be used to implement fileserver.conf if we need to, but that's not the main purpose of this library. > - ... i think that's all :) > > I'd welcome some conversation on these items or additional ones if > anyone on the list feels like chiming in. None of it is not set in stone > but I would definitely like to build up set of design requirements and > acceptance criteria for the implementation before you spend a ton of > time on it. Sure, thanks for raising the various points and issues :) If there's any other concerns let me know. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54EB8528.1080901%40daysofwonder.com. For more options, visit https://groups.google.com/d/optout.
