PolicyAdministrationPoint

A Policy Administration Service for OpenStack

Overview

This document describes a model of a policy administrative point (PAP) service for Openstack clouds. The service could be a separate stand alone OpenStack service, or it could be integrated into Keystone. The PAP service will be responsible for keeping and updating authorisation policies, which are currently spread over the Openstack services (Nova, Cinder, Glance etc.).

The advantages of centralizing policy management include:

• Easy maintenance of policies.
• Allow policies to be dynamically modified and applied (either immediately or periodically).
• People and services can know what they are allowed to do, since the PAP will know all policies associated with each role.
• Enable the Openstack dashboard (Horizon) to adapt itself according to the roles of the users, only showing features available for them.
• Enable administrators to know which role is required to access a specific feature/service.

How it will work

Each Openstack module will continue to implement its own authorisation system, which includes a policy enforcement point (PEP) and a policy decision point (PDP). PEPs are responsible for enforcing the decisions returned by the PDPs on each request. The PDP will communicate with the PAP and Keystone as follows:

1. With Keystone as now, to retrieve the user’s attributes, roles or projects/tenants, based on the received token. In this case, Keystone acts as a PIP (Policy Information Point). It can also provide environmental and contextual information about the request.
2. With the PAP, to retrieve the latest authorisation policy. For performance purposes, policies should be kept cached by each service. A publish-subscribe mechanism will notify PDPs when policies are updated.

With the retrieved information, each PDP makes an authorisation decision for the request, which can be accept or decline, and return it to the PEP.

Proposal APIs

The PAP will have an interface where administrators can manage policies (CRUD operations). Policies can be written in the same format they are currently stored in policy.json file. This minimizes the changes on services that already use these files. Two types of query will be also available in the PAP service:

1. Horizon can customize user’s interfaces by querying the PAP which features are available to a given role.
2. Project administrators can easily obtain which role is needed in order to give access rights for a given action on a service.

These queries will be protected for security reasons, but can be easily implemented since the PAP will centralize policies from all Openstack services.

Outstanding issues

1. What to do about authorised tasks that are currently active, and the revised policy says the user is no longer authorised. Do we have a callback mechanism from the PDP to the PEP saying Terminate this task, or does the application shutdown and restart?
2. If the PDP code is within the scope of Keystone to write and distribute then we can change the model and mechanisms without affecting the services, as they will continue to call the PDP and behave accordingly. But is this the case today?

What about Congress?

This blueprint is complementary to the Congress project. Despite the fact that both the PAP and Congress have an interface for Administrators to create authorisation policies, they have different purposes:

• Congress aims to offer governance and compliance for cloud services. It will be able to dynamically create policies and send them to Openstack services, or modify existing policies, in order to ensure a high level policy is enforced.
• The PAP aims to improve the current policy mechanism, enabling policy exchange among federated clouds and Horizon´s dashboard.