Open Stack

> Any pointers to examples of this sort of configuration via
> policy.json would be appreciated ;)

The basic syntax is covered here:

  http://docs.openstack.org/trunk/openstack-compute/install/content/keystone-concepts.html

Note also this recently merged patch providing additional syntax
to support finer-grained policy decisions:

  https://review.openstack.org/#/c/14245/

as discussed on the ML here:

  http://lists.openstack.org/pipermail/openstack-dev/2012-October/001566.html

Cheers,
Eoghan

> >  
> > > Ideally we need to lock down the access such that INSTANCE_USER
> > > can
> > > only
> > > perform a subset of API actions on a subset of the keystone
> > > authenticated
> > > APIs, is there any method for doing this with the policy.json?
> > >
> > > If not then we can track the "instance users" inside heat and
> > > reject
> > > API
> > > requests for non-whitelisted API actions (e.g we want ability to
> > > send
> > > Cloudwatch metrics, but not to query them or manipulate alarms)
> > > 
> > > Adam - previously you mentioned putting the "instance users" in a
> > > separate
> > > tenant (managed by heat), do you still see this as a good
> > > solution,
> > > or do
> > > you think there is a viable way to lock down INSTANCE_USER inside
> > > the
> > > same
> > > tenant as USER?
> > 
> > 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..
> 
> 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
> 
>