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
