Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user
+1. Id like to see a similar thing for keystone validate user tokens. Thanks, Kevin From: Johannes Grassler Sent: Monday, July 04, 2016 2:43:47 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user 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? | 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. Cheers, Johannes -- Johannes Grassler, Cloud Developer SUSE Linux GmbH, HRB 21284 (AG Nürnberg) GF: Felix Imendörffer, Jane Smithard, Graham Norton Maxfeldstr. 5, 90409 Nürnberg, Germany __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user
Hello, Thanks for the exhaustive comment on the issue. Won't help much in the short term, but it's good to see there will eventually be a way to sort this out properly! On 07/04/2016 12:50 PM, Steven Hardy wrote: On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote: [Magnum's global stack-list versus Heat's 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. Ok, that's fair enough. | stacks:global_index: "role:service", [...] 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). Yes...also, it just shifts the problem as Pavlo pointed out: an admin user can just assign themselves the 'service' role in their own tenant. So that's no advantage over using role:admin :-) [...] 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. Indeed, that sounds a lot better. 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! Definitely does, thanks! Cheers, Johannes -- Johannes Grassler, Cloud Developer SUSE Linux GmbH, HRB 21284 (AG Nürnberg) GF: Felix Imendörffer, Jane Smithard, Graham Norton Maxfeldstr. 5, 90409 Nürnberg, Germany __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user
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/08/ 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user
Hi Johannes, this is still not too optimal, as AFAIK admin role is still global, so admin in tenant also means admin of whole OpenStack, thus it still can assign himself/whomever the 'service' role and get access to global stack list. Best solution would probably be to create a separate domain in Keystone, and a service user in it, and check in policy json the actual domain+tenant+some role or username in this tenant. This domain and tenant are completely controlled by Magnum service then (creds are in the magnum config) - all similar to how Heat is working. Cheers, Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com On Mon, Jul 4, 2016 at 12:43 PM, 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? > > | 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. > > Cheers, > > Johannes > > -- > Johannes Grassler, Cloud Developer > SUSE Linux GmbH, HRB 21284 (AG Nürnberg) > GF: Felix Imendörffer, Jane Smithard, Graham Norton > Maxfeldstr. 5, 90409 Nürnberg, Germany > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [magnum][heat] Global stack-list for Magnum service user
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? | 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. Cheers, Johannes -- Johannes Grassler, Cloud Developer SUSE Linux GmbH, HRB 21284 (AG Nürnberg) GF: Felix Imendörffer, Jane Smithard, Graham Norton Maxfeldstr. 5, 90409 Nürnberg, Germany __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev