This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1468805 - [RFE] lock down domain admins identity v3 [NEEDINFO]
[RFE] lock down domain admins identity v3
Status: NEW
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
10.0 (Newton)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: John Dennis
nlevinki
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-08 03:51 EDT by Siggy Sigwald
Modified: 2017-10-19 12:38 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
hrybacki: needinfo? (ssigwald)


Attachments (Terms of Use)

  None (edit)
Description Siggy Sigwald 2017-07-08 03:51:53 EDT
I would like to prevent the domain admin from being able to make global changes or affect resources outside of it's domain. Right now i can start and stop instances from other domains, create global flavors and networks. I would like to prevent this.

for Verizon to move forward with using identity v3 it is required that domain admins  behave as expected. It would seem to be an issue if an admin of one domain can stop and start vms from another domain. I know they cannot list the instances but if they happen to have the id they can stop and start them. We don't want them to create global networks either. they should also not be able to create global flavors. basically we would like for the domain admin to be limited to their domain. Global networks and flavors should only be created by the cloud_admin. Host aggregates and availability zones should also be made only by cloud_admin.
Comment 2 Raildo Mascena de Sousa Filho 2017-08-23 12:11:19 EDT
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

Note You need to log in before you can comment on or make changes to this bug.