Tightening up deltacloud security

[Mo Morsi]

  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)


    -Mo

[Hugh O. Brock]

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

[Mo Morsi]

  On 12/20/2010 07:56 AM, Hugh Brock wrote:
>  On Fri, Dec 17, 2010 at 08:24:57PM -0500, Mohammed Morsi wrote:
> > <snip>
>  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. 
Yes, FreeIPA supports this capability

http://freeipa.org/page/Certificate_Management

We would still need to setup kerberos keytabs (through FreeIPA) to 
authenticate the clients requesting the certificates, but that should be 
straightforward to do in the recipe.

>  Also, did you look specifically at dealing with qmf and kerberos?
QMF supports kerberos, but at the QPID broker level. AFAIK there is 
currently no way to use kerberos to manage which objects and methods on 
those objects are available to which users, but for now this probably is 
unneeded and what is supported is good enough

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Messagi...

>  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). 
AFAIK this shouldn't be an issue, if a Kerberos instance is already in 
place, all we need to do is add principles for the various deltacloud 
services and clients, and Kerberos should handle the rest. We could 
provide a script as part of the recipe to configure an existing Kerberos 
instance.

>  If you would, please look at the above issues and send out a
> revision
>  of this as soon as you can. 
 From your feedback, I think three additional tasks are needed,

    - instead of setting up and assigning the ssl certificates manually, 
we need to setup FreeIPA and Kerberos to authenticate the end points 
requesting them and automatically hand them out
    - we need to configure the qpid broker and client to make use of 
Kerberos policies when determining what has access to those services
    - we need to provide a means to setup additional Kerberos policies 
as part of the recipe, not touching existing ones, should Kerberos 
already be setup. If Kerberos is installed but not FreeIPA, we need to 
only install the additional FreeIPA components and/or provide a means to 
migrate from the existing Kerberos setup to the new one.

I believe this covers it. If anything else looks off shout out, else 
I'll start implementing this in conjunction w/ Mike's recipe feedback.

   -Mo

[Hugh O. Brock]

On Mon, Dec 20, 2010 at 08:43:56PM -0500, Mohammed Morsi wrote:
>   On 12/20/2010 07:56 AM, Hugh Brock wrote:
>  >On Fri, Dec 17, 2010 at 08:24:57PM -0500, Mohammed Morsi wrote:
>  >><snip>
>  >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.
>  
>  Yes, FreeIPA supports this capability
>  
>  http://freeipa.org/page/Certificate_Management
>  
>  We would still need to setup kerberos keytabs (through FreeIPA) to
>  authenticate the clients requesting the certificates, but that
>  should be straightforward to do in the recipe. 
Great. That's probably the first thing to get working on.

>  >Also, did you look specifically at dealing with qmf and
> kerberos?
>  
>  QMF supports kerberos, but at the QPID broker level. AFAIK there is
>  currently no way to use kerberos to manage which objects and methods
>  on those objects are available to which users, but for now this
>  probably is unneeded and what is supported is good enough
>  
>
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Messagi...
Yes, oddly enough we just discovered that on the Matahari effort as
well. You're right, we don't need to worry about authorization via
kerberos, just authentication (we'll manage access control inside the
application).

>  >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).
>  
>  AFAIK this shouldn't be an issue, if a Kerberos instance is already
>  in place, all we need to do is add principles for the various
>  deltacloud services and clients, and Kerberos should handle the
>  rest. We could provide a script as part of the recipe to configure
>  an existing Kerberos instance. 
We'll definitely want to do this, yes.

>  >If you would, please look at the above issues and send out a
> revision
>  >of this as soon as you can.
>  
>  From your feedback, I think three additional tasks are needed,
>  
>     - instead of setting up and assigning the ssl certificates
>  manually, we need to setup FreeIPA and Kerberos to authenticate the
>  end points requesting them and automatically hand them out
>     - we need to configure the qpid broker and client to make use of
>  Kerberos policies when determining what has access to those services
>     - we need to provide a means to setup additional Kerberos
>  policies as part of the recipe, not touching existing ones, should
>  Kerberos already be setup. If Kerberos is installed but not FreeIPA,
>  we need to only install the additional FreeIPA components and/or
>  provide a means to migrate from the existing Kerberos setup to the
>  new one.
>  
>  I believe this covers it. If anything else looks off shout out, else
>  I'll start implementing this in conjunction w/ Mike's recipe
>  feedback. 
Great, I don't see anything missing here, I'll look forward to the
implementation :).

--Hugh