[openstack-dev] [keystone] on-behalf-of proxy identities for applications running in-instance

Steven Hardy shardy at redhat.com
Thu Oct 11 12:08:19 UTC 2012


On Thu, Oct 11, 2012 at 07:15:31AM -0400, Eoghan Glynn wrote:
<snip>
> Wouldn't Heat need to map to both the instance *and* the original
> owner/tenant associated with the instance?

Not with our current implementation, no:
- Metric datapoints are associate with a "watch rule" in our DB
- A "watch rule" is associated with a stack
- A stack is associated with a particular tenant

So once a metric datapoint is published, it is implicitly mapped internally
to a specific stack, and hence the owning tenant (not the proxy/instance
user)

>
> 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

T1 will only have visibility (and hence be able to publish metric data for)
stacks owned by T1, so webserver_user, DB_user can only publish metric data
for Bobs stack(s)/instances, and vice-versa for T2
 
> - 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?)
>
Bob can only see watch rules (and hence metric-data) for stacks owned by T1,
so we query the DB and get results for webserver & DB (not mailserver as
it's owned by T2), which I think is what is expected.

That said, the current heat cloudwatch implementation doesn't support
query/filter by dimension, or GetMetricStatistics (yet), and we do need to
improve our DB schema to allow this to be done efficiently.  The basic
mapping describe above should remain the same though (maybe will get more
complex when we decouple heat orchestration and cloudwatch..)

Steve



More information about the OpenStack-dev mailing list