Puppet has an interesting approach to this problem : to be able to
communicate with th server, each client must have a signed certificate. Upon
first launch, the client will generate a request, send it to the server and
upon approval (which is manually done by the server admin), get the final
client cert signed by the server (which here acts a CA).
Details are scarce, but some information here :
http://docs.puppetlabs.com/guides/security.html
2011/1/26 David Voit <da...@codersau.de>
>
>
> 2011/1/26 Laurent Guyon <lgu...@adelux.fr>
>
>
>> Le 26 janvier 2011 à 15:25, David Voit <da...@codersau.de> a écrit :
>>
>>
>> > >>
>> > >> > 2.) Do we really need client authentication, for every component?
>> For
>> > >> the
>> > >> > arbiter, sure we need it - else we get a botnet like system. But
>> the
>> > >> other
>> > >> > components?
>> > >> > Reactoner and broker, need to authenticate too, else the "bad
>> guys"
>> > >> > could get secret data (all theoretical)
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> I'd say yes, all components must securely connect to others to avoid
>> any
>> > >> security breach.
>> > >>
>> > > Yes, there are list of servers and some things like that. It's better
>> to
>> > > crypt all of this if the admin want it. and it's not so harder to add
>> such
>> > > feature for all daemons, and after all, it's already done :p
>> > >
>> >
>> > It's not about encryption, it's about authentication. If you call a
>> https
>> > site, all the traffic is still encrypted, even without a client cert.
>> > You are responsible, if you connect willingly to the bad guys. With
>> shinken
>> > we have a problem, if the arbiter is not authenticated, couse it could
>> send
>> > any shell code, to all instances after it.
>>
>>
>>
>> I was effectively speaking about authentication, not encryption ;)
>>
>>
>>
>> I pointed that authentication need out few weeks ago, and effectively,
>> without authentication layer, an arbiter can send arbitrary commands to any
>> scheduler (tested).
>>
>>
>>
>> But with the authentication layer added this should be ok (note I didn't
>> make more tests for now...)
>>
>>
>>
>
> We already have this layer, with client certs (actually in this
> implementation, dualuse server/client certs)
>
>
>>
>> > > We discussed also on the future possibility to make the certificates>
>> >> creation automatic for components (scheduler, poller, roker,
>> reactionner),
>> > >> like done in the Prelude IDS project.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> > I also recommend that we don't ship certs with the tarball, but
>> > >> generate
>> > >> > them at install time.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> +1, I've already pointed that out ;)
>> > >>
>> > > Yes, it can be a very interesting feature :)
>> > > I don't know where is the best place for this (hook in setup.py or in
>> the
>> > > packager code for installing)? Is ther a packager guy to help us on
>> this
>> > > point? How is this thing manage in the other projects?
>> > >
>> > >
>> > I would say on both sides. setup.py for the developer and gentoo typed
>> guy
>> > :-). The package way for everybody else.
>> > The apache2 package does this on suse (not checked, from memory).
>>
>>
>>
>>
>>
>> One side should be easier to maintain that several.
>>
>>
>>
>> I think setup.py is definitively not the best place for this, as it's main
>> aim is to install the code.
>>
>>
>>
>> CA and certificates generation is a more external and manual postinstall
>> task.
>>
>>
>>
>> So, I would provide in the Shinken distribution a standalone script for CA
>> and certificates generation, that packagers will fire in the postinstall
>> process of their packages, and that sysadmins will use when installing
>> Shinken manually.
>>
>>
>>
>> But remember the CA and certificate creation should be optionnal, as many
>> sysadmins already have CA management tools and will use it rather a script
>> ;)
>>
>
> Ok i will create this script, this evening.
>
>
>>
>>
>> Laurent
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
>> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Shinken-devel mailing list
>> Shinken-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
--
Albéric de Pertat
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
