Open Stack

On Thu, Oct 11, 2012 at 08:30:56AM -0400, Eoghan Glynn wrote:
> > > Maybe I'm missing something fundamental, might make sense to walk
> > > through a hypothetical case ...
> > > 
> > > - Bob has two instances, webserver & DB both of type m1.medium
> > >
> > So Bob is a member of tenant "T1", and creates a stack (associated
> > with T1), which contains the instances
> > 
> > > - Alice has a single instance, mailserver of type m1.medium
> > >
> > > - Bob and Alice are associated with different tenants
> > 
> > So she is a member of tenant T2
> >  
> > > - Heat creates 3 new proxy users, webserver_user, DB_user &
> > >   mailserver_user
> > 
> > So webserver_user, DB_user are in T1, mailserver_user is in T2
> 
> 
> OK, cool, so that's basically the opposite of what I understood by
> "separate tenant" idea mooted earlier. 

Yeah, sorry I actually ended up describing what we currently do rather than
the theoretical "separate tenant" scheme, misread your question somewhat ;)

> As long as the generated {instance}_users are always associated with
> the same tenant as the original instance owner then, yep, no mapping
> is necessarily required, as long as everything we need to do after
> the fact is scoped at the tenant level (e.g. there's no requirement
> for per-user chargeback for the {instance}_user's API calls, mapping
> back to the original user's identity).
> 
> I'm not sure what the "seperate tenant" idea was aiming to achieve
> from a lock-down perspective, given that the limited-karma role
> would be associated with the user as the opposed the tenant. Anyway
> it seems that idea has fallen by the wayside ...

IIRC the idea was to separate the untrusted "instance" users from the
trusted "real" users. Sledgehammer/nut scenario ;)

Having had time to consider in more detail, I agree this is not the way to
go, too much complexity for probably very little real security advantage
(could actually be less secure given the "cross tenant" metric population
scheme which would be required)

Sorry if the heat-specifics have veered the thread OT a bit - hopefully we
have now converged on a sane interim solution pending further discussion
around the whole proxy-user and in-instance problem.

Steve