On Fri, Dec 17, 2010 at 08:24:57PM -0500, Mohammed Morsi wrote: > I just spent a few cycles going over the deltacloud overview > diagram, figuring out which components and communication buses need > to be locked down in terms of encryption, authentication, and > authorization. Here are my findings in hopes of facilitating a > discussion around this (feel free to shout out if you think anything > can or should be changed, by no means is this set in stone). If it > looks good for the most part I will begin implementing this in the > deltacloud installer/configuration recipe next week (after I get > back to and integrate Mike's feedback to my last recipe patchset). > > Communication which needs to be secured: > ---------------------------------------- > End User -> Aggregator WUI: http (apache) > iwhd & core -> Cloud Providers: http (cloud specific) > Aggregator & image_builder_agent -> iwhd: http (libmicrohttpd) > image_builder_console -> image_builder_agent: qmf > image_builder_service, aggregator wui, condor_refershd, dbomatic -> > database: postgres > condormatic -> condor: condor > libdeltacloud, deltacloudc -> deltacloudd: http (thin/webrick) > > > Other communication which does not need to be secured: > ---------------------------------------- > Apache -> Thin (for aggregator wui, running on same box) > dbomatic -> condor (log parsing) > > > Components needing authentication/authorization > ---------------------------------------- > Aggregator wui > Condor > image_builder_agent > iwhd > core > db > > > Specific Tasks: > ---------------------------------------- > * setup mod_ssl for apache in recipe, ensure aggregator wui is > accessible via https > * configure ssl support for postgres in recipe > * configure ssl support for qpid broker and client for > image_builder_agent/console > * configure ssl support in libmicrohttpd for iwhd, or if we cannot, > restrict to local traffic only and forward approprate public traffic > from apache > * setup ssl for condor and lock condor down to only accept commands > from aggregator wui and condor_refreshd > * restrict core's thin & webrick servers to local traffic only, > forward public traffic from apache > * setup and assign certificates for various services which require > them (auto assign to clients who cant prompt user to verify > certificates) > * install kerberos, ldap, freeipa for user > authentication/authorization and management > - verify user on login in aggregator wui > - verify user has permission to submit jobs to scheduler > - verify user has permission to run requests on specific core > drivers / backend cloud providers (another job requirement when > instances are being scheduled, etc) > - verify user has permission to build images of certain types and > store them in the image warehouse > > > Eventually: > ---------------------------------------- > * tighten up postgres user access, create different users w/ limited > roles for the various deltacloud services (for aggregator wui, > condor_refreshd, dbomatic, image_builder_service) > * look into various cloud provider security solutions, how to > integrate into core if not done already (communicate w/ cloud > provider web services via ssl)
This looks great Mo. I have one question: Have you looked at all at IPA certificate manager/PKI management capability? I would have thought there was a way to automate the distribution of ssl certs much like the automated distribution of kerb keytabs. Also, did you look specifically at dealing with qmf and kerberos? Finally, we're going to need understanding of and documentation of how we would integrate with an org's existing Kerberos infrastructure (linux/unix only of course, Active Directory can be later). If you would, please look at the above issues and send out a revision of this as soon as you can. Thanks, --Hugh _______________________________________________ deltacloud-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/deltacloud-devel
