Self-Paced Policy Evolution in OpenStack

During the OpenStack Victoria Project Team's Gathering we discussed the advantage of self-paced policy evolution.

Context

To date, keystone and nova support scope-checking and default roles (e.g., admin, member, reader). Both projects are currently carrying deprecated policies that allows for compatibility with legacy RBAC implementations. We, as service developers, want to know if we can remove the deprecated policies across services at different times or if we need to wait for each service to adopt the new concepts. For example, can nova and keystone remove their old, deprecated policies in Victoria before neutron, cinder, and glance fully implement system-scope and default roles?

Allowing each project to evolve their policies at their own pace simplifies the overall effort because it requires less coordination across projects. We want to know what ramifications a self-paced process will have on operators. The goal of this document is to define how to answer that question and report the results of the investigation. The findings should clearly tell us if a self-paced approach to policy evolution is feasible for operators and users.

Investigation Assumptions & Criteria

The following assumptions and criteria determine if we've successfully reached our goal:

• We assume operators will audit end-users' role assignments as necessary through the migration
• We assume operators will educate end-users about authoritative changes, where applicable
• We assume operators are using default policies in each service regardless of scope-checking adoption or default roles
• We don't expect end-users to have their authorization accidentally escalated as a side-effect of the migration
• We expect to know how new personas, like system-admin or project-reader affect deployments throughout the migration

Process