Open Stack

> > I'm struggling with the separate tenant idea, as there doesn't seem
> > to be
> > a way of recovering the original identity (which presumably you
> > would
> > need when querying the metrics in you use-case, or just
> > auditing/billing
> > etc. in the general case).
> 
> So I can see this being a problem generally, but within the limited
> heat use-case, we simply have to enforce one INSTACE_USER for every
> instance, and map the INSTANCE_USER to the actual instance resource
> internally. Non-ideal though..


Wouldn't Heat need to map to both the instance *and* the original
owner/tenant associated with the instance?

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

- Alice has a single instance, mailserver of type m1.medium

- Bob and Alice are associated with different tenants

- Heat creates 3 new proxy users, webserver_user, DB_user &
  mailserver_user

- cfn-push-stats assumes the identity of {instance}_user when
  reporting metrics from within each instance

- Bob calls GetMetricStatistics with his original identity,
  requesting dimension InstanceType=m1.medium 

- we expect only the metrics for webserver & DB to be aggregated,
  but not mailserver (or?)

Cheers,
Eoghan
 

> The main thing seems to be having INSTANCE_USERs in a separate tenant
> probably adds a lot of internal management complexity, for some
> percieved additional separation/security.
> 
> Then you also have the risk of contamination between INSTANCE_USERs
> (e.g due
> to bugs in our internal mapping code etc), so overall I'm reaching
> the
> conclusion that sticking to a single tenant will be best overall,
> with
> INSTANCE_USERs restricted by role/policy and possibly some whitelist
> sanity
> logic in the WSGI code.
> 
> Steve
> 
>