> On 30 Jan 2016, at 21:55, Adam Young <[email protected] > <mailto:[email protected]>> wrote: > > On 01/30/2016 04:14 PM, Henry Nash wrote: >> Hi Adam, >> >> Fully support this kind of approach. >> >> I am still concerned over the scope check, since we do have examples of when >> there is more than one (target) scope check, e.g.: an API that might operate >> on an object that maybe global, domain or project specific - in which case >> you need to “match up with scope checks with the object in question”, for >> example for a given API: >> >> If cloud admin, allow the API >> If domain admin and the object is domain or project specific, then allow the >> API >> If project admin and the object is project specific then allow the API >> >> Today we can (and do with keystone) encode this in policy rules. I’m not >> clear how the “scope check in code” will work in this kind of situation. > I originally favored an approach that a user would need to get a token scoped > to a resource in order to affect change on that resource, and admin users > could get tokens scoped to anything, but I know that makes things harder for > Administrators trying to fix broken deployments. So I backed off on that > approach. > > I think the right answer would be that the role check would set some value to > indicate it was an admin override. So long as the check does not need the > actual object from the database, t can perform whatever logic we like. > > The policy check deep in the code can be as strict or permissive as it > desires. If there is a need to re-check the role for an admin check there, > policy can still do so. A role check that passes at the Middleware level can > still be blocked at the in-code level. > > "If domain admin and the object is domain or project specific, then allow the > API" is trh tricky one, but I don't think we even have a solution for that > now. Domain1->p1->p2->p3 type hierarchies don't allow operations on p3 with > a token scoped to Domain1.
So we do actually support things like that, e.g. (from the domain specific role additions): ”identity:some_api": role:admin and project_domain_id:%(target.role.domain_id)s (which means I’m project admin and the domain specific role I am going to manipulate is specific to my domain) ….and although we don’t have this in our standard policy, you could also write ”identity:some_api": role:admin and domain_id:%(target.project.domain_id)s (which means I’m domain admin and I can do some operation on any project in my domain) > > I think that in those cases, I would still favor the user getting a token > from Keystone scoped to p3, and use the inherited-role-assignment approach. > > >> >> Henry >> >>> On 30 Jan 2016, at 17:44, Adam Young <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I'd like to bring people's attention to a Cross Project spec that has the >>> potential to really strengthen the security story for OpenStack in a >>> scalable way. >>> >>> "A common policy scenario across all projects" >>> https://review.openstack.org/#/c/245629/ >>> <https://review.openstack.org/#/c/245629/> >>> >>> The summary version is: >>> >>> Role name or pattern Explanation or example >>> -------------------------------------:-------------------------------------------------- >>> admin : Overall cloud admin >>> service : for service users only, not real >>> humans >>> {service_type}_admin : identity_admin, compute_admin, >>> network_admin etc. >>> {service_type}_{api_resource}_manager: identity_user_manager, >>> compute_server_manager, >>> network_subnet_manager >>> observer : read only access >>> {service_type}_observer : identity_observer, image_observer >>> >>> >>> Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph >>> Matthews just took it to the next level. It is worth a read. >>> >>> I think this is the way to go. There might be details on how to get there, >>> but the granularity is about right. >>> If we go with that approach, we might want to rethink about how we enforce >>> policy. Specifically, I think we should split the policy enforcement up >>> into two stages: >>> >>> 1. Role check. This only needs to know the service and the api resource. >>> As such, it could happen in middleware. >>> >>> 2. Scope check: for user or project ownership. This happens in the code >>> where it is currently called. Often, an object needs to be fetched from >>> the database >>> >>> The scope check is an engineering decision: Nova developers need to be >>> able to say where to find the scope on the virtual machine, Cinder >>> developers on the volume objects. >>> >>> Ideally, The python-*clients, Horizon and other tools would be able to >>> determine what capabilities a given token would provide based on the roles >>> included in the validation response. If the role check is based on the URL >>> as opposed to the current keys in the policy file, the client can determine >>> based on the request and the policy file whether the user would have any >>> chance of succeeding in a call. As an example, to create a user in >>> Keystone, the API is: >>> >>> POST https://hostname:port/v3/users <https://hostname:port/v3/users> >>> >>> Assuming the client has access to the appropriate policy file, if can >>> determine that a token with only the role "identity_observer" would not >>> have the ability to execute that command. Horizon could then modify the >>> users view to remove the "add user" form. >>> >>> For user management, we want to make role assignments as simple as possible >>> and no simpler. An admin should not have to assign all of the individual >>> roles that a user needs. Instead, assigning the role "Member" should imply >>> all of the subordinate roles that a user needs to perform the standard >>> workflows. Expanding out the implied roles can be done either when issuing >>> a token, or when evaluating the policy file, or both. >>> >>> I'd like to get the conversation on this started here on the mailing list, >>> and lead in to a really productive set of talks at the Austin summit. >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected] >>> <mailto:[email protected]>?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected] >> <mailto:[email protected]>?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected] > <mailto:[email protected]>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
