Open Stack

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.