RBAC Check in Middleware

RBAC Check in Middleware

Project logistics

Preferred past experience

Familiarity with the following is desirable:

Overview

Video Pitch from Adam Young

Role Based Access Control (RBAC) requires administration of both the roles assigned to users and the rules that determine what role can perform what action. To date, OpenStack has made role assignment fairly easy to use, but modification of policy files has been manual, decentralized, and inconsistent. The goals:

  • Allow operator assignment of the roles to operations
  • Provide a means to report what role is required for an operation
  • Allow users to delegation subsets of their roles, potentially allowing them to delegate the ability to perform individual operations
  • The authorization data associated with Keystone tokens contains a set of roles that can be used to enforce access control. This is a departure from the NIST definition of Role Based Access Control in that the role names are only part of the overall role; they are further scoped to the projects. A user assigned a role in one project would not have access to a resource in another project. Thus, we call this Scoped RBAC. Perform a role check in keystonemiddleware after the token validation by using a set of rules that map from VERB + URL Patterns to a small set of roles, and then expanding that to a full set of roles via the role inference rules. The RBAC check happens before keystonemiddleware passes control to the service specific code. Leave the current oslo-policy based access checks in place, using the existing policy.json files. This leads to a separation of concerns: Middleware enforces the role check, source code enforces the scope check.

    Some Technologies you will learn/use: