On Tue, Jun 4, 2013 at 5:14 PM, <[email protected]> wrote: > This summer I am working in an environment where we have a > well-established Linux + Kerberos + Active Directory infrastructure. We > would prefer to re-use that infrastructure rather than maintain a separate > private key infrastructure for puppet. So, I am investigating enabling > Kerberos authentication for node <-> master authentication. So far it looks > like the work breaks up into several pieces: > > 1 MASTER > 1.a Configure Apache2 for Kerberos HTTP authentication > 1.b Retrieve the principle from the web request. > 1.c Enhance Puppet::Network::AuthStore::Declaration to support Active > Directory host principles (e.g. [email protected]). > > 2 AGENT > 2.a Acquire/build a Kerberos / GSSAPI capable HTTP client library > 2.b Integrate it into the puppet agent lifecycle > > I'm new to puppet and related technologies so would appreciate any high > level guidance/suggestions/etc. that the community might have to offer. > mjz > > As Trevor said, you'll also need to make sure that the channel remains encrypted. I think that the portions of the code that you are going to be trying to swap out (namely network communication infrastructure) are not currently designed for that. It will probably take a lot of moving things around and creation of some new classes to make something like this slot in cleanly. Also, all of this functionality will need to be optional so that scenarios that don't use kerberos don't take on new dependencies.
> --- > Further details and questions (in no particular order) > > * POC master progress - So far I have a very small set of non-production > quality edits to the puppet master code that allows GET > production/node/[email protected] to work as expected when using "curl > --negotiate -u:" as a client. See: > https://github.com/mzeren-vmw/puppet/commit/draft_kerberos_baby_steps. > I am just starting to create proper patches for pull requests. > Before you start making pull requests for something this large, I think it would be good to outline the parts that you are changing and what the design will be. This also seems like something that would fit well into the armature process (https://github.com/puppetlabs/armatures). > > * POC agent progress - I have not yet found a GSSAPI capable http client > library, but I have found and successfully tested > https://github.com/cbeer/net-ssh-kerberos which depends on git:// > github.com/zenchild/gssapi.git (MIT) which in turn depends on ffi > (LGPLv3). When I get to the client side work I may leverage gssapi to > extend Net::HTTP? > > I have to admit that I've never tried to do Kerberos over HTTP. A few quick web searches uncovered SPNEGO (http://en.wikipedia.org/wiki/SPNEGO) which looks to be the standard for negotiating various authentication mechanisms over http. > * How would Kerberos integrate with MCollective? - I don't really > understand the relationship between mcollective and puppet yet. How might > Kerberos auth affect mcollective based features or future enhancements? > MCollective and puppet are fairly independent components. MCollective has a plugin (agent in its terms) for controlling puppet, but puppet has very little knowledge, if any, of mcollective. I believe that mco already has a pluggable authentication mechanism, so kerberos might fit into it already. > > * Is pulling REMOTE_USER from the environment acceptable? Or do we need a > way to get the mod_auth_kerb user into a request header as we do for > X-Client-DN and X-Client-Verify? So far mod_rewrite hasn't been > cooperating here... > > I think it depends on how portable across rack implementations that is. > * Apache mod_auth_kerb only? I am focused on using Apache2's > mod_auth_kerb. I don't anticipate getting this to work for webrick, and > haven't yet investigated nginx. Would a single webserver solution be > acceptable? > I wouldn't worry about webrick. It is really only acceptable for development setups. As far as multiple webserver setups, we try to stick to plain rack, if possible. When that isn't possible then try to make sure that there is a way of configuring either puppet or the webserver to work together. I believe that historically we have tried to work with apache + passenger and nginx + ??? (that one is a little more fuzzy to me). > > * There's a related bug here: > https://projects.puppetlabs.com/issues/3958discussion: > https://groups.google.com/forum/#!msg/puppet-dev/ECIvFzj4dKo/ivOqTQEKVeoJ > > * Are there any plans to support ruby 2.0? Net::HTTP apparently has basic > auth support in 2.0, which might lead to cleaner Kerberos support (but I > really haven't looked at this in detail yet.) > Ruby 2 should be support as of 3.2 ( http://docs.puppetlabs.com/puppet/3/reference/release_notes.html#ruby-20-support ) > > -- > 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. > > > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13* **Register now and take advantage of the Early Bird discount - save 25%!* -- 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.
