Out of the box, when Keystone issues a project scoped token, it returns all known service endpoints regardless of whether users have access to them or not. This is neither efficient nor secure. In the Havana release, an endpoint filter extension was created. Unfortunately this offers limited filtering capabilities and furthermore is difficult to manage service endpoints. The purpose of this specification is to outline an improved endpoint filtering solution.
bp multi-attribute-endpoint-grouping
At present with the Endpoint Filtering extension in Keystone, we are able to associate endpoints with projects, thereby limiting the service endpoints that appear in a catalog for a project scoped token. However, anyone who belongs to a given project can see all the project scoped service endpoints. From a Security perspective this clearly violates the principle of ‘Least Privilege’. For instance, a Glance Administrator on the US West Coast should not see Glance or for that matter any other service endpoints on the US East Coast or any other region for that matter. Therefore there is a strong need to be able to offer more fine grained capabilities for filtering service endpoints returned in the service catalog. In particular, we should be able to filter service endpoints according to service (e.g. Nova, Swift, etc) or interface type (e.g. admin, internal, etc) or region or any combination thereof.
In addition, with the present Endpoint Filtering extension, managing service endpoints is a challenge due to the static nature of the relationship between a service endpoint and a project. For example, currently you must explicitly create a project association for every new service endpoint which is a management headache. Essentially the current solution provides a static group of endpoints associated with a given project.
Multi-Attribute Endpoint Grouping essentially builds upon and extends the capabilities offered by the Endpoint Filtering extension by introducing a dynamic endpoint attribute filtering capability that is directly associated with a project.
The underlying idea of Multi-Attribute Endpoint Grouping is to provide a key-value based filtering strategy that groups service endpoints having the same characteristics (e.g. service, type, region).
The benefits of Multi-Attribute Endpoint Grouping are as follows:
An alternative solution to Multi-Attribute Endpoint Grouping is to be able to define fine-grained rules in the policy file that dictate which service endpoints be included in the catalog for a given project scoped token. At the moment, such fine-grained dynamic rules are not feasible, in part, because both the policy language and Keystone’s interpretation are insufficient but also due to the static nature of policy configuration, limits dynamically adding new service endpoints at runtime.
This extension is not intended to provide additional security. Instead, endpoints are simply omitted from the user’s service catalog. This behavior does not prevent users from communicating with an endpoint.
The benefit of this proposal is that we offer more fine grained control over what service endpoints are returned to the user in the underlying service catalog.
None
None
Generally speaking this change should reduce the size of the service catalog included in project scoped tokens since we are filtering service endpoints. Each project scoped token request will require an additional SQL query to find all endpoint groups associated with the target project. And then one SQL query per associated endpoint group. This additional querying should add minimal performance impact and by default filtering is not enabled.
Deployers will need to enable the endpoint filter extension and create the endpoint filter extension tables. This information will be documented in keystone\doc\source\extensions.
None.
Create Documentation including setup and configuration
None