Open Stack

On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote:
> Hello,
> 
> Magnum has a periodic task that checks the state of the Heat stacks it creates
> for its bays. It does this across all users/tenants that have Magnum bays.
> Currently it uses a global stack-list operation to query these Heat stacks:
> 
> https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83
> 
> Now the Magnum service user does not normally have permission to perform this operation,
> hence the Magnum documentation currently suggests the following change to
> Heat's policy.json:
> 
> | stacks:global_index: "role:admin",
> 
> This is less than optimal since it allows any tenant's admin user to perform a
> global stack-list. Would it be an option to have something like this in Heat's
> default policy.json?

Yes, this sort of problem is the reason we disabled global_index by
default[1] - because of the somewhat notorious keystone bug #968696[2], we
could not create a default rule which correctly communicated that this
should be a cloud-admin only action.

So, instead of creating an insecure-by-default rule, we disabled it for
everybody, so that deployers could make an explicit choice about how to
enable access to this potentially sensitive API.

> | stacks:global_index: "role:service",
> 
> That way the global stack-list would be restricted to service users and seting
> Magnum (or other services that use Heat internally) wouldn't need a change to
> Heat's policy.json.
> 
> If that kind of approach is feasible I'd be happy to submit a change.

I don't think this is feasible, because it implies a level of admin-ness
for service users that I think isn't desirable (even it if may be the
status-quo, I don't personally think trusting all services to have global
access to heat by default is a good model from a security isolation
perspective).

This topic was discussed[3] recently in the context of another RFE bug[4] that
wanted additional global-admin capabilities, and the outcome of that
discussion was a reccomendation that we use the new "is_admin_project"
capability added to keystone[5] in order to fix bug #968696.

The net result of this is a redefinition of "is_admin" in our context to
look like:

"role:admin and auth_token_info.token.is_admin_project:True",

However ref https://review.openstack.org/#/c/333308/ there are problems
with backwards compatibility when accessing this directly from the
token_info, so we need https://review.openstack.org/#/c/331916/ which will
enable access of this attribute in a backwards compatible way.

I assume the net result will be that anyone not configuring an admin
project in keystone will get the old buggy #968696 behaviour, but at least
then we won't have codified any assumptions around admin scope inside heat,
and that access can be controlled centrally for all services via keystone
in a consistent way.

So, in summary, I think we should fix our integration with the new keystone
is_admin_project stuff, then potentially switch the global_index to use the
is_admin rule as defined by our policy.json.

Then, you'd just need to add the magnum service user to whatever project is
defined in keystone as being the admin project, but it would not require
exposing this API to every other service by default.

Hope that helps!

Steve

[1] https://github.com/openstack/heat/blob/master/etc/heat/policy.json#L47
[2] https://bugs.launchpad.net/keystone/+bug/968696
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079006.html
[4] https://bugs.launchpad.net/heat/+bug/1466694
[5] https://review.openstack.org/#/c/240719/