Open Stack

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 <jgrassler at suse.de>
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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/97de97d1/attachment.html>