Open Stack

There are a few Keystone features that are coming together for Kilo.  
Endpoint binding of tokens is one, and I think can be handled completely 
in keystonemiddelware.auth_token.  Another, though, is based on a few 
requests we've had to be able to have policy performed against a 
specific object or API based on what is in the token.

The token would have a new section 'constraints', parallel to 'scope'.  
It will contain one or more of the following.

   `endpoints` : a list with each of the endpoint ids explcitly enumerated.
   `operations` : a list of the APIs as definied in the policy rules file.
   `entities`:  a list of the object identifiers.

If any section is not explicitly set, there are no constraints of that kind.

For example, if all three were specified, the token would contain 
something like:


constraints: {
     endpoints: ['novaepid', 'glanceepid'],
     operations: ["compute:create","compute:start", 
"network:associate","network:get_floating_ip",
                         "image:get_image","network:update_port" ],
     entities:['imageid1','networkport2']
}

Since the nova server would not have created the instance yet, there 
would be no restriction on the create call.  Only the specified image 
with id 'imageid1' would be accessible from glance, and only the 
"get_image" API would be allowed on glance.  Only access to 
'networkport2' would be granted from Neutron.


To enforce the 'operations' constraint, we can modify the policy 
enforcer  here:

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/policy.py#n290

A check like:

if creds.token.get('constraints',{}).get('operations') and rule not in 
creds.token.constraint.operations:
        raise PolicyNotAuthorized(rule)


I'm not, however, certain how to standardize the "entities" portion of 
it.  Any suggestions?


For endpoint binding, an endpoint will have to know its own id. So the 
endpoint_id will be recorded in the config file.  This means that the 
endpoint should be created in keystone before bringing up the server.  
Since we already require workflow like this to create the service users, 
this should not be too big a burden.  Then that becomes a check here:

http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n863

which looks like :

if|data['access']['token'].get('constrains',{}).get('endpoints') and 
CONF.endpoint_id not in |
|data['access']['token']['constrains']['endpoints']|:
|raise InvalidToken('Endpoint constraint not met')|

The WIP spec is here: https://review.openstack.org/#/c/123726/

please provide feedback on content.  I'll deal with formatting once it 
is roughed out.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/170bfdb8/attachment.html>