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.


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to