Given that you're going to be using client certs for encryption, why would
you bother with Kerberos authentication?

The Puppet certificate system exists within a private ecosystem (unless you
change that) so you're not really gaining any additional control over your
environment.

Are there some fancy features that I might be missing or do those who fear
the command line want to do agent revocation via a GUI (at which point use
Dogtag or something like it).

Trevor


On Wed, Jun 5, 2013 at 1:51 PM, <[email protected]> wrote:

> Andy, thanks for all your answers.
>
>
> On Wednesday, June 5, 2013 9:25:38 AM UTC-7, Andy Parker wrote:
>>
>> 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.
>>
>
> WRT securing the channel: our current plans are to continue to rely on
> server certificates for channel encryption. I should amend my prior
> description by saying that we want to use Kerberos for *agent*
> authentication. Technically Kerberos provides master auth too, but we will
> be relying on traditional certificate based SSL server auth as part of
> securing the channel. It might be possible to use SLL with Kerberos TLS and
> skip the master certs, but that's not something that we need now.
>
> WRT moving code / backward compatibility: so far the server changes look
> relatively non-invasive. The client changes seem likely to be more
> invasive, but I understand the requirement to not regress on any existing
> behavior/dependencies. My goal is to make it "just work" with minimal to
> zero configuration. We'll see how achievable that is...
>
>
>> 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<https://github.com/puppetlabs/armatures>
>> ).
>>
>
> Yes. I want to get through a round of client prototyping first, but I
> think an armature would help structure this work. When I know a bit more
> I'll work on a draft.
>
>
>> 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)
>>
>
> OK. That's helpful. I think I'm working within standard apache idioms
> though there are some details that remain to be worked out. We can discuss
> this more when I start working up a formal change for this part of the
> master modifications (POC rest.rb diff here:
> https://github.com/mzeren-vmw/puppet/commit/draft_kerberos_baby_steps).
>
>
>  --
> 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.
>
>
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]

-- 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 [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.


Reply via email to