Clojure authorization system for SERVER-111...
161 views
Skip to first unread message
Brice Figureau
Feb 16, 2015, 5:02:08 AM2/16/15
to puppe...@googlegroups.com
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.
On my todo-list:
* route rules creation/matching (path and regex, restriction by method
or environment)
* parsing auth.conf file format
* ring handler to check incoming request
* generate artifacts for consumption in other project
* actually use this project in the Puppet Server
Of course, I'm ready to move this project under the Pupeptlabs umbrella
(or to merge the code to another trapperkeeper project) when it will be
more mature.
Feel free to take a look to the existing project (and why not
contribute :).
Thanks.
[*]: https://tickets.puppetlabs.com/browse/SERVER-111
--
Brice Figureau
My Blog: http://www.masterzen.fr/
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.
On my todo-list:
* route rules creation/matching (path and regex, restriction by method
or environment)
* parsing auth.conf file format
* ring handler to check incoming request
* generate artifacts for consumption in other project
* actually use this project in the Puppet Server
Of course, I'm ready to move this project under the Pupeptlabs umbrella
(or to merge the code to another trapperkeeper project) when it will be
more mature.
Feel free to take a look to the existing project (and why not
contribute :).
Thanks.
[*]: https://tickets.puppetlabs.com/browse/SERVER-111
--
Brice Figureau
My Blog: http://www.masterzen.fr/
Eric Sorenson
Feb 23, 2015, 12:18:36 AM2/23/15
to puppe...@googlegroups.com
On Feb 16, 2015, at 2:01 AM, Brice Figureau <brice-...@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 ), 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 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.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles
puppet platform // coffee // techno // bicycles
Chris Price
Feb 23, 2015, 9:58:02 AM2/23/15
to puppe...@googlegroups.com
On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson <eric.s...@puppetlabs.com> wrote:
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 ), and from those results plus recalling conversations with #puppet there seem to be a few general categories that we should examine when designing a replacementFirst, 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,
It would be cool if we could figure out a way to represent the rules in HOCON, since that's the format we're using for pretty much all of our new config files going forward. That way, the same modules and tooling that we're building up around that data format could be used on the auth stuff, and the syntax would start to look more consistent and familiar compared to other new puppet config files. Since HOCON is basically a superset of JSON I'm thinking that maybe the rules could be written as basically a big array of maps. It'd be a little more verbose than the existing syntax, but I think the tradeoffs might be worth it.
(This is presuming, of course, that we don't find some other existing model that we like, as Eric suggested.)
Trevor Vaughan
Feb 23, 2015, 10:09:29 AM2/23/15
to puppe...@googlegroups.com
Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great.....
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Chris Price
Feb 23, 2015, 11:48:02 AM2/23/15
to puppe...@googlegroups.com
On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:
Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds great.....
Totally agree that we have too many formats. That's why we tried to put a lot of thought into picking one that we think is robust enough to standardize on going forward. :) Also, the current auth.conf format is none of the above, so moving it to any of the above would mean 'n - 1' formats :)
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com.
Henrik Lindberg
Feb 23, 2015, 12:22:54 PM2/23/15
to puppe...@googlegroups.com
On 2015-23-02 17:47, Chris Price wrote:
> On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan <tvau...@onyxpoint.com
> <mailto:tvau...@onyxpoint.com>> wrote:
>
> Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds
> great......
> On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan <tvau...@onyxpoint.com
> <mailto:tvau...@onyxpoint.com>> wrote:
>
> Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds
>
>
> Totally agree that we have too many formats. That's why we tried to put
> a lot of thought into picking one that we think is robust enough to
> standardize on going forward. :) Also, the current auth.conf format is
> none of the above, so moving it to any of the above would mean 'n - 1'
> formats :)
>
Is there an overlap with Node Classifier and RBAC as they also specify
>
> Totally agree that we have too many formats. That's why we tried to put
> a lot of thought into picking one that we think is robust enough to
> standardize on going forward. :) Also, the current auth.conf format is
> none of the above, so moving it to any of the above would mean 'n - 1'
> formats :)
>
rules? We would want to have a common way to handle rules in different
domains.
- henrik
>
> On Mon, Feb 23, 2015 at 9:57 AM, Chris Price <chris@puppetlabs..com
> <mailto:ch...@puppetlabs.com>> wrote:
>
> On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson
> <eric.s...@puppetlabs.com
> <mailto:eric.s...@puppetlabs.com>> wrote:
>
>
> 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
> <http://ask..pl.com> for bugs around auth.conf to see what
>
>
> 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
> 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> ),
> https://www.google.com/search?q=site%3Apuppetlabs.com+auth.conf&gws_rd=ssl
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 <tel:%28410%29%20541-6699>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> tvau...@onyxpoint.com <mailto:tvau...@onyxpoint.com>
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> 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
> <mailto:puppet-dev+...@googlegroups.com>.
> -- This account not approved for unencrypted proprietary information --
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> 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
> <mailto:puppet-dev+...@googlegroups.com>.
> Groups "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-dev+...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
Trevor Vaughan
Feb 23, 2015, 12:39:52 PM2/23/15
to puppe...@googlegroups.com
That works. I just put in a feature request against Hiera for a HOCON native back end :-D.
Also, if you'd pop out some native types that can manipulate these things, that would be nifty.To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com.
Trevor Vaughan
Feb 23, 2015, 12:40:52 PM2/23/15
to puppe...@googlegroups.com
Hmm....can we push some of this down into Environments? It would be nice to have different auth.conf's (and the others) per environment so that I don't have to bust out my regex-fu every time.
Thanks,On Mon, Feb 23, 2015 at 12:22 PM, Henrik Lindberg <henrik....@cloudsmith.com> wrote:
On 2015-23-02 17:47, Chris Price wrote:
On Mon, Feb 23, 2015 at 7:09 AM, Trevor Vaughan <tvau...@onyxpoint.com
<mailto:tvau...@onyxpoint.com>> wrote:
Sorry to derail for the moment but HOCON + JSON + YAML + XML? Sounds
great......
Totally agree that we have too many formats. That's why we tried to put
a lot of thought into picking one that we think is robust enough to
standardize on going forward. :) Also, the current auth.conf format is
none of the above, so moving it to any of the above would mean 'n - 1'
formats :)
Is there an overlap with Node Classifier and RBAC as they also specify rules? We would want to have a common way to handle rules in different domains.
- henrik
On Mon, Feb 23, 2015 at 9:57 AM, Chris Price <chris@puppetlabs..com
<mailto:ch...@puppetlabs.com>> wrote:
On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson
<eric.s...@puppetlabs.com
<mailto:puppet-dev+unsub...@googlegroups.com>.it, send an email to puppet-dev+unsubscribe@googlegroups.com
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CAMx1QfL9TvgyWJ5__utWk12CQ3y_q0Wk63uJr6efMxoEk4gLeA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 <tel:%28410%29%20541-6699>
tvau...@onyxpoint.com <mailto:tvau...@onyxpoint.com>
-- This account not approved for unencrypted proprietary information --
--
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+unsubscribe@googlegroups.com
<mailto:puppet-dev+unsub...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVgeG5fYRqa3xkj9%3DKEQBpwB%2BUv%2BbRJsY0LoPTL8BZQ%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com
<mailto:puppet-dev+unsub...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLpVd2swVDpqvX5Xgtq%3DL7txZTkYKUTHLdOX5vOGUh-4g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/mcfnl1%247av%241%40ger.gmane.org.
--
Eric Sorenson
Feb 23, 2015, 12:48:10 PM2/23/15
to puppe...@googlegroups.com
On Feb 23, 2015, at 9:22 AM, Henrik Lindberg <henrik....@cloudsmith.com> wrote:
> On 2015-23-02 17:47, Chris Price wrote:
>> Totally agree that we have too many formats. That's why we tried to put
>> a lot of thought into picking one that we think is robust enough to
>> standardize on going forward. :) Also, the current auth.conf format is
>> none of the above, so moving it to any of the above would mean 'n - 1'
>> formats :)
> Is there an overlap with Node Classifier and RBAC as they also specify rules? We would want to have a common way to handle rules in different domains.
Do you mean the rules that these services themselves model? (Like mapping objects to permission levels in RBAC) Because that is a very different data model that I wouldn't expect to render in a config file format at all.
> On 2015-23-02 17:47, Chris Price wrote:
>> Totally agree that we have too many formats. That's why we tried to put
>> a lot of thought into picking one that we think is robust enough to
>> standardize on going forward. :) Also, the current auth.conf format is
>> none of the above, so moving it to any of the above would mean 'n - 1'
>> formats :)
> Is there an overlap with Node Classifier and RBAC as they also specify rules? We would want to have a common way to handle rules in different domains.
On the other hand these services _should_ be able to use the auth.conf replacement to control access their HTTP endpoints, though. Right now all the clj services just have simplistic certificate whitelists.
Brice Figureau
Feb 23, 2015, 2:53:23 PM2/23/15
to puppe...@googlegroups.com
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-...@daysofwonder.com <mailto:brice-...@daysofwonder.com>>
> <http://ask.pl.com> for bugs around auth.conf to see what people have
> 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.
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
>> 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 :)
>>
>> 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.
> <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> ),
> ( https://www.google.com/search?q=site%3Apuppetlabs.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.
> 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.
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.
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.
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.)
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)
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
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'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.
If there's any other concerns let me know.
Chris Price
Feb 23, 2015, 4:22:00 PM2/23/15
to puppe...@googlegroups.com
On Mon, Feb 23, 2015 at 9:39 AM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:
That works. I just put in a feature request against Hiera for a HOCON native back end :-D.
Good idea!
Also, if you'd pop out some native types that can manipulate these things, that would be nifty.
This should probably be considered 'beta' quality right now, as we're actively working on improving the back-end library that is used to manage the config files so that it does a better job of retaining formatting when you round-trip a config file to/from disk, but here's the module we intend to use for managing these files:
https://github.com/puppetlabs/puppetlabs-hocon
https://github.com/puppetlabs/puppetlabs-hocon
While I'm at it, 'include' statements should be available in all config files since includes > concat for ordering files in Puppet....and we do like Puppet for managing our configs..... ;-)
Interesting. HOCON does support that but I don't think our Ruby library does yet, because we weren't really sure whether people would want to use it.
Trevor Vaughan
Feb 23, 2015, 4:30:45 PM2/23/15
to puppe...@googlegroups.com
Well, without 'include' statements, you'd better add some ordering to your puppetlabs-hocon module.
Currently, auth.conf is order dependent and I don't really see how you're going to change that (so you probably need ordering anyway).I suppose you could add some systemd-like before/after/depends syntax.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMx1Qf%2BRO6KM5pHjjF-yWog%2B5yxeJpJ%3DRLoUeC5E3P1CbDJD_Q%40mail.gmail.com.
Chris Price
Feb 23, 2015, 5:04:00 PM2/23/15
to puppe...@googlegroups.com
On Mon, Feb 23, 2015 at 1:30 PM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:
Well, without 'include' statements, you'd better add some ordering to your puppetlabs-hocon module.Currently, auth.conf is order dependent and I don't really see how you're going to change that (so you probably need ordering anyway).
Agree, ordering will be important for a use case like auth.conf.
Brice Figureau
Feb 24, 2015, 5:48:35 AM2/24/15
to puppe...@googlegroups.com
On Mon, 2015-02-23 at 06:57 -0800, Chris Price wrote:
> On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson
> <eric.s...@puppetlabs.com> wrote:
>
> 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 ), and from those
> On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson
> <eric.s...@puppetlabs.com> wrote:
>
> 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%
> 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,
>
>
> It would be cool if we could figure out a way to represent the rules
> in HOCON, since that's the format we're using for pretty much all of
> our new config files going forward. That way, the same modules and
> tooling that we're building up around that data format could be used
> on the auth stuff, and the syntax would start to look more consistent
> and familiar compared to other new puppet config files. Since HOCON
> is basically a superset of JSON I'm thinking that maybe the rules
> could be written as basically a big array of maps. It'd be a little
> more verbose than the existing syntax, but I think the tradeoffs might
> be worth it.
How about this:
> 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,
>
>
> It would be cool if we could figure out a way to represent the rules
> in HOCON, since that's the format we're using for pretty much all of
> our new config files going forward. That way, the same modules and
> tooling that we're building up around that data format could be used
> on the auth stuff, and the syntax would start to look more consistent
> and familiar compared to other new puppet config files. Since HOCON
> is basically a superset of JSON I'm thinking that maybe the rules
> could be written as basically a big array of maps. It'd be a little
> more verbose than the existing syntax, but I think the tradeoffs might
> be worth it.
rules {
"/path/to/first/resource" {
type = path
allow_ip = [ "192.168.10.0/24", "127.*" ]
allow = "*.abc.edu"
}
"^/path/to/(.*)/" {
type = regex
deny = "badhost.domain.com"
allow = [ "$1.domain.com", "goodhost.domain.com" ]
}
}
Since in HOCON objects are merged together when including another
"rules" object its properties would add. The only downside is that the
Config library (the HOCON java support) doesn't seem to support globbing
on include.
What I'm not sure is if hocon respects order of object keys (which might
matters to some for rules ordering).
But it's a much more nicer syntax than using an array:
rules = [
{
endpoint = "/path/to/resource"
type = path
allow_ip = [ "192.168.10.0/24", "127.*" ]
allow = "*.abc.edu"
},
...
]
which is much jsonesque,but might be more correct if order matters,
IMHO.
> (This is presuming, of course, that we don't find some other existing
> model that we like, as Eric suggested.)
--
Brice Figureau <brice-...@daysofwonder.com>
Chris Price
Feb 24, 2015, 9:47:24 AM2/24/15
to puppe...@googlegroups.com
On Tue, Feb 24, 2015 at 2:48 AM, Brice Figureau <brice-...@daysofwonder.com> wrote:
On Mon, 2015-02-23 at 06:57 -0800, Chris Price wrote:
> On Sun, Feb 22, 2015 at 9:18 PM, Eric Sorenson
> <eric.s...@puppetlabs.com> wrote:
How about this:
rules {
"/path/to/first/resource" {
type = path
allow_ip = [ "192.168.10.0/24", "127.*" ]
allow = "*.abc.edu"
}
"^/path/to/(.*)/" {
type = regex
deny = "badhost.domain.com"
allow = [ "$1.domain.com", "goodhost.domain.com" ]
}
}
Since in HOCON objects are merged together when including another
"rules" object its properties would add. The only downside is that the
Config library (the HOCON java support) doesn't seem to support globbing
on include.
What I'm not sure is if hocon respects order of object keys (which might
matters to some for rules ordering).
I'm pretty sure it doesn't make any guarantees about the order of object keys, unfortunately.
But it's a much more nicer syntax than using an array:
rules = [
{
endpoint = "/path/to/resource"
type = path
allow_ip = [ "192.168.10.0/24", "127.*" ]
allow = "*.abc.edu"
},
...
]
which is much jsonesque,but might be more correct if order matters,
IMHO.
Yeah, I agree, it's a little more clunky that way, but probably worth it since it makes it 100% clear that the order matters. Also, I think that it'll be easier to programatically manipulate (via puppet modules, etc.) with the array syntax.
FWIW we've been using colons over '=' in the config files we ship so far, but that doesn't really matter since it'll support either.
I'll defer to Eric and others in terms of what the keys should be inside of the maps, since I'm not particularly a power user on that subject :)
Thanks!
Brice Figureau
Mar 9, 2015, 4:59:11 AM3/9/15
to puppe...@googlegroups.com
SERVER-111:
https://github.com/masterzen/trapperkeeper-authorization
I've tried to put the better documentation I could in the project
README, but I think that's not where I shine.
So let me summarize what this library does.
The aim is to provide an authorization layer that could be used in the
Puppetlabs JVM projects. For this the library offers two components:
* a DSL to build authorization rules (either internal or from a HOCON
file, auth.conf not yet supported)
* a ring middleware that can be added to a compojure app, checking
incoming request against the authorization rules.
Authorization rules is a list (in insertion order) of independent rule.
A rule is:
* an endpoint (either a complete request path-info, or expressed as a
regex)
* optionnally a restricting HTTP method
* an ACL
And ACL is a list of access control entry, which are fully compatible
with the existing Puppet system (the rationale is that this system seems
to work, and most of the people in the ecosystem at least know it a bit,
so why design a different system?).
There can be several access control entries, each supporting either
allowing/denying based on the incoming request certificate CN part of
the subject DN, or the remote peer IP address.
* allow and allow-ip
* deny and deny-ip
At the end of the ACL, we have an implicit 'deny all' rule.
Allow and deny support the following:
* exact names: 'www.domain.org'
* wildcard names: '*.domain.org'
* regex names: '(this|that).domain.org'
* backreference names: '$1.domain.org'
* opaque names (same definition as for current Puppet version)
Allow-ip and deny-ip support the following:
* exact IPv4 or IPv6: '192.168.0.1' or '::1'
* network IPv4 or IPv6: '192.168.0.0/24'
* wildcard: '192.168.*'
When an incoming request ends up in the ring middleware, the request URI
is matched against the rules (in order), if none matches the request is
denied (implicit deny *), if one matches, its ACL is checked. If the ACL
allows the request, the rest of the ring handler are executed, otherwise
a 401 is returned with a message telling which rule triggered (and
where it was loaded from).
So to build rules, the most straightforward system is use the HOCON
support:
# rules.conf
rules = [
{
path: /path/to/resource
type: path
allow: [ "*.domain.org", "*.test.com" ]
allow-ip: "192.168.0.0/24"
deny: "bad.guy.com"
deny-ip: "192.168.1.0/24"
},
{
type: regex
path: "(incoming|outgoing)"
allow: "www.domain.org"
}
]
Then in the project to use those rules:
(ns test
(:require [puppetlabs.trapperkeeper.authorization.rules :as rules]
[puppetlabs.trapperkeeper.authorization.ring-middleware :as
ring]))
; loading rules from a file
(def rules (rules/config-file->rules "rules.conf"))
; our ring app
(def app
(-> handler
(ring/wrap-authorization-check rules)))
So it's quite simple.
You can also define rules programatically with a dumb DSL:
(def rules (-> rules/empty-rules
(rules/add-rule (-> (new-path-rule "/path/to/resource")
(allow "*.domain.org")))
(rules/add-rule (-> (new-regex-rule "(this|
that)-resource")
(allow "$1.domain.org")))))
The code is, I think, quite fully covered by tests.
I'd also like to add a few features like deploying to clojars,
simplified auth.conf support, Puppet support (ie environment),
performance, etc...
Now, I'm ready to donate this project to Puppetlabs, if you guys are
interested, just let me know how we can achieve the transfer or
ownership (well you should first do a thorough code review, since it's
my first complete clojure project :).
Anyhow, it was a fun project to hack on.
Thanks,
--
Brice Figureau <brice-...@daysofwonder.com>
Chris Price
Mar 9, 2015, 11:52:53 AM3/9/15
to puppe...@googlegroups.com
On Mon, Mar 9, 2015 at 1:59 AM, Brice Figureau <brice-...@daysofwonder.com> wrote:
I think I've completed a milestone in respect with what you wanted and
SERVER-111:
https://github.com/masterzen/trapperkeeper-authorization
I've tried to put the better documentation I could in the project
README, but I think that's not where I shine.
So let me summarize what this library does.
The aim is to provide an authorization layer that could be used in the
Puppetlabs JVM projects.
Brice,
This sounds great, thanks a ton for putting it together! I'll try to get some reviews going, and maybe at some point roll an experimental build of Puppet Server that uses it so that Eric and others can play with it.
Just to give you a heads up on timelines for things: Puppet4.0/Puppet Server 2.0 are at the top of the hot list, Puppet Server 1.1/2.1 (mostly perf/tuning improvements) is after that, but Auth is pretty near the top of the list after that. Hopefully we can at least poke a little before then, though.
Thanks again!
Chris
Brice Figureau
Mar 9, 2015, 1:15:34 PM3/9/15
to puppe...@googlegroups.com
On Mon, 2015-03-09 at 08:52 -0700, Chris Price wrote:
> On Mon, Mar 9, 2015 at 1:59 AM, Brice Figureau
> <brice-...@daysofwonder.com> wrote:
>
> I think I've completed a milestone in respect with what you
> wanted and
> SERVER-111:
>
> https://github.com/masterzen/trapperkeeper-authorization
>
>
> I've tried to put the better documentation I could in the
> project
> README, but I think that's not where I shine.
>
> So let me summarize what this library does.
>
> The aim is to provide an authorization layer that could be
> used in the
> Puppetlabs JVM projects.
>
>
> Brice,
>
>
> This sounds great, thanks a ton for putting it together! I'll try to
> get some reviews going, and maybe at some point roll an experimental
> build of Puppet Server that uses it so that Eric and others can play
> with it.
No jars have been pushed yet anywhere. I'll try to do that soon.
> On Mon, Mar 9, 2015 at 1:59 AM, Brice Figureau
> <brice-...@daysofwonder.com> wrote:
>
> I think I've completed a milestone in respect with what you
> wanted and
> SERVER-111:
>
> https://github.com/masterzen/trapperkeeper-authorization
>
>
> I've tried to put the better documentation I could in the
> project
> README, but I think that's not where I shine.
>
> So let me summarize what this library does.
>
> The aim is to provide an authorization layer that could be
> used in the
> Puppetlabs JVM projects.
>
>
> Brice,
>
>
> This sounds great, thanks a ton for putting it together! I'll try to
> get some reviews going, and maybe at some point roll an experimental
> build of Puppet Server that uses it so that Eric and others can play
> with it.
> Just to give you a heads up on timelines for things: Puppet4.0/Puppet
> Server 2.0 are at the top of the hot list, Puppet Server 1.1/2.1
> (mostly perf/tuning improvements) is after that, but Auth is pretty
> near the top of the list after that. Hopefully we can at least poke a
> little before then, though.
I'll take this time to polish and bug fix whatever I can (oh and also
spend some time on an exotic island without any computer).
Still I'd be interested in any comments you, Eric0, or anyone could make
both on the code or file format or whatever :)
Thanks!
--
Brice Figureau <brice-...@daysofwonder.com>
Chris Price
Mar 9, 2015, 4:20:08 PM3/9/15
to puppe...@googlegroups.com
On Mon, Mar 9, 2015 at 10:15 AM, Brice Figureau <brice-...@daysofwonder.com> wrote:
On Mon, 2015-03-09 at 08:52 -0700, Chris Price wrote:
>
> This sounds great, thanks a ton for putting it together! I'll try to
> get some reviews going, and maybe at some point roll an experimental
> build of Puppet Server that uses it so that Eric and others can play
> with it.
No jars have been pushed yet anywhere. I'll try to do that soon.
Don't worry about jars, we'll just build it locally. Easy to do.
> Just to give you a heads up on timelines for things: Puppet4.0/Puppet
> Server 2.0 are at the top of the hot list, Puppet Server 1.1/2.1
> (mostly perf/tuning improvements) is after that, but Auth is pretty
> near the top of the list after that. Hopefully we can at least poke a
> little before then, though.
OK, I don't think there is any hurry :)
I'll take this time to polish and bug fix whatever I can (oh and also
spend some time on an exotic island without any computer).
Oh, now you're talking!! Can I go?
Still I'd be interested in any comments you, Eric0, or anyone could make
both on the code or file format or whatever :)
Definitely, will try to start getting those trickling in ASAP.
Brice Figureau
Mar 9, 2015, 5:02:40 PM3/9/15
to puppe...@googlegroups.com
On 09/03/2015 21:20, Chris Price wrote:
> On Mon, Mar 9, 2015 at 10:15 AM, Brice Figureau
> <brice-...@daysofwonder.com <mailto:brice-...@daysofwonder.com>>
> On Mon, Mar 9, 2015 at 10:15 AM, Brice Figureau
> wrote:
>
> On Mon, 2015-03-09 at 08:52 -0700, Chris Price wrote:
> >
> > This sounds great, thanks a ton for putting it together! I'll try to
> > get some reviews going, and maybe at some point roll an experimental
> > build of Puppet Server that uses it so that Eric and others can play
> > with it.
>
> No jars have been pushed yet anywhere. I'll try to do that soon.
>
>
> Don't worry about jars, we'll just build it locally. Easy to do.
Too late, I clojarified the thing:
>
> On Mon, 2015-03-09 at 08:52 -0700, Chris Price wrote:
> >
> > This sounds great, thanks a ton for putting it together! I'll try to
> > get some reviews going, and maybe at some point roll an experimental
> > build of Puppet Server that uses it so that Eric and others can play
> > with it.
>
> No jars have been pushed yet anywhere. I'll try to do that soon.
>
>
> Don't worry about jars, we'll just build it locally. Easy to do.
https://clojars.org/masterzen/trapperkeeper-authorization
It might be easier for a quick run.
> > Just to give you a heads up on timelines for things: Puppet4.0/Puppet
> > Server 2.0 are at the top of the hot list, Puppet Server 1.1/2.1
> > (mostly perf/tuning improvements) is after that, but Auth is pretty
> > near the top of the list after that. Hopefully we can at least poke a
> > little before then, though.
>
> OK, I don't think there is any hurry :)
> I'll take this time to polish and bug fix whatever I can (oh and also
> spend some time on an exotic island without any computer).
>
>
> Oh, now you're talking!! Can I go?
> Still I'd be interested in any comments you, Eric0, or anyone could make
> both on the code or file format or whatever :)
>
>
> Definitely, will try to start getting those trickling in ASAP.
Eric Sorenson
Jun 22, 2015, 7:26:14 PM6/22/15
to puppe...@googlegroups.com, brice-...@daysofwonder.com, brice-...@daysofwonder.com
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
Reply all
Reply to author
Forward
0 new messages