deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject Re: Dynamic selection of driver
Date Mon, 15 Nov 2010 15:49:34 GMT
On Fri, 2010-11-12 at 09:29 -0500, Jim Jagielski wrote:
> On Nov 11, 2010, at 8:21 PM, David Lutterkort wrote:
> 
> > Hi,
> > 
> > Toby Crawley is really the one who brought this up - here's a summary of
> > a discussion we had a couple days ago.
> > 
> > Right now, the deltacloud server only ever uses one driver; that means
> > that if you want to talk to multiple clouds, you need to have one
> > deltacloud server running for each of them. Clearly, not very admin
> > friendly.
> > 
> > Toby actually experimented with this (wanna share your patch, Toby ?).
> > To me, the cleanest way to enable dynamic selection of the driver is to
> > select the driver through add'l HTTP headers. For example, by sending
> > 
> >        X-Deltacloud-Driver: ec2
> >        X-Deltacloud-Endpoint: https://eu-west-1.ec2.amazonaws.com/
> > 
> > you'd be using the eu-west region of EC2.
> > 
> > We would maintain the current behavior of the driver as the default when
> > these headers are absent; so if you start 'deltacloudd -i mock', clients
> > that don't set the Deltacloud headers will talk to the mock driver.
> > 
> 
> Sounds good, but shouldn't there be some sort of auth mechanism
> to "verify" that an authorized entity set those headers?

I don't think that's necessary - since the Deltacloud server doesn't
store any credentials, the user also needs to include their credentials
with the request (as a HTTP basic auth header)

ASAICT, worst case, they have invalid credentials, and the only attack
they could launch is DOS either on the Deltacloud server (which they
could in any case) or on the backend cloud (which they also can do w/o
Deltacloud)

David





Mime
View raw message