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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
