On Monday, March 9, 2015 at 10:15:34 AM UTC-7, Brice Figureau wrote: > > Still I'd be interested in any comments you, Eric0, or anyone could make > both on the code or file format or whatever :) >
Hi Brice, as you saw on the SERVER-111 ticket traffic, I wanted to give this some attention and work towards adopting it. I spent a couple of days poring over everyone's contributions to this thread, your trapperkeeper-authorization README, the old auth.conf docs, bugs, and ancient folklore and here's what I came up with. ## configuration ordering - It needs some explicit way to indicate order of application for rules (and potentially resolve conflicts?). The closest model seems to be cisco style ACLs with just a number and you evaluate them in increasing order. There is a set order of evaluation for ACE rules inside an ACL, but not ACLs against one another - with regexps in particular its possible to match things you don't intend. include - Should support dropping snippets in a directory since these are easier to manage with puppet itself, than a monolithic file. Commentary on this email thread suggested that hocon does this out of the box, which would be cool. versioning - Should have some concept of which version of the syntax the config is written in, like puppet reports do. ## inside rules Backreferences - The old saying about "you have a problem, and think to use regular expressions. Now you have two problems." is pretty apropos! The primary use case is matching URL elements against the content of the certificate. I'm not sure that this needs to support full regexp, which adds complexity and another mini-language that users need to understand and debug. It feels like this is too flexible on the matching side (requires a regex) and too constrained on the acl side (it only matches the cert subject not additional cert data like subject alt names or other extensions). I would love to get some real-world examples of using backreferences that are *not* "permit the cert mentioned in the url" IP addresses - are the allow_ip syntaxes really necessary/in use? (Side question: if so, why have all 3 of IP, wildcard, and CIDR notation? CIDR can express all of them and is more natural to firewall/ACL rules) I don't have an exhaustive survey of everyone's auth.conf, but some github searches and informal polls indicated that this is not often used. It seems like having certificate data is both safer and more useful, so unless there are some strong requirements for IP matching I'd suggest removing this completely. ## ux When fully parsed, log out the internal representation of the rulesets w/ ordering, so people can see that things are landing where they expect. When processing an incoming request, the service should log rule-by-rule misses or matches. (It may already do this, as you mentioned earlier in the thread, I need to get it running and try) I'm asking around (would love to hear from anyone on this list!) for any real-world examples of nontrivial auth.conf that we could convert to the new format and see how expressiveness and readability are affected. --eric0 -- 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/baa1bf6f-4d54-455b-a8f9-6073b230a581%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
