External Policy Decision Point

bp external-pdp-for-keystone

Keystone, together with Oslo_policy, provides a native authorization policy engine for OpenStack. There are several defaults about the solution:

  • based on a file: policy.yaml (or policy.json) owned by each OpenStack component (Nova, Glance, Neutron, …)

  • hard to understand

  • not flexible to configure

  • based only on one authorization (access control) model

As OpenStack may be deployed by different users with different requirements, a generic yet flexible approach is needed through which users may define, apply and manage their own authorization policy. External PDP (Policy Decision Point) disables the default way and delegates authorization to an external authorization policy engine.

Existing works [Fortress, Moon] show the feasibility of this approach with the Fortress and Moon policy engines. This specification proposes a generic hook which will re-direct authorization requests to an external PDP instead of using the native one. Each policy engine stores and manages related information of their policy, grants or denies requests based on these information and their own rules.

Problem Description

Currently, if a user wants to modify the authorization policy for his/her OpenStack platform, he/she must update the policy.yaml file for each component (Nova, Glance, Neutron, …).

The only authorization model allowed is based on a RBAC model (Role Based Access Control) and the operator cannot modify this model. But in some case, he/she may want to add new information like membership and authorize actions in his/her platform based on his membership, e.g. MLS (Multi-Level Security) is widely used for information flow access control.

The policy modification must be done on all component with the risk of error appearing. The policy modification is not centralized.

Proposed Change

This change proposes to allow users to chose their PDP (Policy Decision Point). User will be able to choose between:

  • standard local policy.yaml file

  • external Fortress policy engine platform

  • external Moon policy engine platform

  • …

The switch between those PDP can be configured and done through the modification of policy.json/yaml. For each rule, a URL need to be set. Thus every components that use Oslo_Policy can benefit from this improvement. For example in Glance policy.json file:

{
    "context_is_admin":  "role:admin",
    "default": "role:admin",
    ...
    "get_images": "http://external_pdp_server:8080/{name}s",
    ...
}

To be able to communicate with one of those PDP, the hook is based on HTTP_Check of Oslo_Policy. This API can be as simple as:

POST /authz

Where the body of POST includes:

  • target request-related information

  • credentials user authentication information

  • rule this is the new data that we need to add in HTTP_Check function which identify requested operation

For example, here are some possible requests:

POST /authz/

The response can just be an HTTP Code return:

  • 200 when the request is authorized

  • 403 when the request is not authorized

Alternatives

The original spec https://review.openstack.org/491565 was submitted to the keystone project. Due to the scope responsability, a new spec (this one) is proposed here.

Through this spec/feature, we could add configuration options to oslo.policy to tell it to bypass its default rule evaluation system and use an external PDP system. Doing that would simplify deployer configuration, because they would only need to specify the location of the PDP system. It would make the library implementation more complicated, though, so we are going to use this simpler approach to start.

Security Impact

As it deals with authorization process, such a change can be a risk for the security. User data is not modify because data like user ID, object ID and so on are only used in reading mode. But if the PDP is external, data could be listen or tampered by malicious network sniffers. Those connections must be highly secured in order to assured that the response of the request can be truly accepted.

The only data which could be listened by malicious sniffers will be :

  • the Keystone project ID

  • the user ID

  • the object targeted by the action

  • the action of the user on the object

Tokens, keys and other sensitive data will not be exposed. No API change is required by this change.

This change can lead to a denial of service attack. Specifically if the PDP is external. If an attacker is able to send a lot of requests through the external interface of the PDP, he can slow down the authorization computing in the PDP and then slow down the end user because the end user depends on this authorization process. To remediate this problem, the external PDP must be place in the network architecture so that it cannot be accessed by the end user or by a malicious user. Once OpenStack is configured to use the external PDP and the external PDP is down, no OpenStack operations will be possible.

Notifications Impact

TODO: None

Please specify any changes to notifications. Be that an extra notification, changes to an existing notification, or removing a notification.

Other End User Impact

The end user will not interact with this change, on the other hand, the operator will have to configure this. In particular, he/she must select the internal/external PDP and select some configuration items including:

  • URL of the external PDP

  • username to connect to the external PDP (if needed)

  • password to connect to the external PDP (if needed)

Performance Impact

Because the authorization process is called every time and because this authorization process can request an external server, it may have performance impact. Preliminary tests show that in the Moon platform a authorization process can take up from 0.2 to 1 second.

Other Deployer Impact

This change forces to update the code of Oslo_Policy which is used by a lot of OpenStack component. But the choice must always allow the operator to use the good old internal PDP (ie the policy.yaml file). In that case, no change will be visible for him/her. But if a deployer wants to use this new feature, one external PDP (like the Fortress or Moon platform) must be ready. He/she only needs to add the URL of his/her external PDP for the corresponding rules in policy.json files.

Developer Impact

None

Implementation

Assignee(s)

Primary assignee:

  • Ruan He

  • Thomas Duval

Work Items

  1. specify the configuration options needed to use an external PDP

  2. modify the Oslo_Policy code by updating the HTTP_Check class to pass rule name being evaluated

  3. test the solution, we only need to use the exsting tests for HTTP_Check.

Dependencies

In order to make the external PDP understand POST data from the HTTP_Check function:

  1. a HTTP proxy has been contributed to Moon for the interpretation work as a PoC

Documentation Impact

The specific configuration for external PDP must be documented.

References