> On Feb 16, 2015, at 2:01 AM, Brice Figureau <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. I went back and surveyed redmine, jira, and 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 First, I don't think you need to try to make it compatible with the existing auth.conf format. 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 <https://github.com/puppetlabs/puppet/pull/1353> where the goal was to have different parts of the module codebase manage snippets of auth.conf. 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. (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.) 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) - 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 - resolves the confusion about access control in fileserver.conf overlapping with auth.conf (see PUP-1237) - ... 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. --eric0 Eric Sorenson - eric.soren...@puppetlabs.com <mailto:eric.soren...@puppetlabs.com> - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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/06660FEA-0E86-48E8-863E-6DCAB7ACF7D0%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
