Bug 1468805

So, the problem that you're facing here can be overcome with a proper usage of the policies files and the usage of a great feature on Keystone called inherited role assignments that I'll explain it later.

First of all, I have to explain that the domains are an Identity API v3 entity and represent a collection of projects, groups and users that define administrative boundaries for managing OpenStack Identity entities.  i.e. besides Horizon, Keystone is the only service who knows what domains are. 

So, as we can see the domain admin should be responsible for actions like managing users, groups and projects, in another way the project admins for each project should be responsible for those actions like start/stop instances, creating flavors/networks.

For example, if you're using the default Nova policy in code in the Newton version (since this RFE was target for that release) you can verify that the default role for creating a service is to the current user be an Admin_or_Owner rule: https://github.com/openstack/nova/blob/stable/newton/nova/policies/servers.py#L32 which means that the user has the admin_role and their token was scoped for the same project that it was requested the action: https://github.com/openstack/nova/blob/stable/newton/nova/policies/base.py#L25.

So, the domain_admins can't create an instance in a project, since they can't get a token for it, i.e. to a domain_admin get a project scoped token for a project ABC, you should grant an admin role for the domain admin in the project ABC.

So, to make that access control easier, Keystone has an interesting function called inherited role assignments, which means that you can grant a specific role an user in a domain and when you check that assignment to be inherited, the user will have the same role assignment in every project inside that domain (even the projects created after that action)On this part of this talk, I explained how to use inherited roles assignments for a similar case when it's using a project hierarchy, you can just remove the parent flag for your case and it will fit better for you case. https://www.youtube.com/embed/KvKiAzKSVYs?start=441&end=634

So using that feature, which is enabled by default on Keystone, you can isolate the domain_admins on their own domains, and guarantee that the domain_admins will be able to access their resources inside their projects, and if you want to have Global admins, which means admins that can have access across all the domains, the Keystone policy suggests creating a specific domain for that special users as you can see in the Keystone v3 policy sample file: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L3

You can find more details about the OpenStack client usage for that operations here: https://docs.openstack.org/python-keystoneclient/latest/api/keystoneclient.v3.html#keystoneclient.v3.roles.RoleManager