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