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