RBAC support in Craton

Registered by Jim Baker

Implement RBAC in Craton. This should optionally integrate with Keystone, but principals (aka subjects, these include users and workflows) can be fully defined in Craton's object model. Solution should include using oslo.policy (and policy.json) to define rules to connect targets (roles, permissions) with principals. Roles include inventory (region, cell, labels, presumably specific hosts), as well as top-level keys.

Blueprint information

Not started
Sulochan Acharya
Jim Baker
Needs approval
Jim Baker
Series goal:
Milestone target:
milestone icon ocata-r-3

Related branches



User stories for RBAC in Craton include the following:

* An operator can configure parts of the cloud in one region, including defining new devices/resources. But she cannot do so in another region, even though it is in the same project.

* A developer should be able to define a workflow, and run it in a test environment. But to preserve separation of duties, the developer cannot run the workflow against the production cloud.

* An adminstrator should be able to approve, then configure a workflow such that it can run in a specified production cloud, along with any necessary variables, for certain regions.

* An operator can run an audit workflow against devices in regions the workflow is permitted to run in. Another operator may be delegated to run a remediation workflow to correct the audit problems.

* Reading and writing configuration can be controlled by the name of the key, including both a prefix and an arbitrary regex pattern.

The above stories expect a separation of duties can be supported as desired; a user may wear all three of the developer, admin, and op hats in the above stories, but these may also be apply to different users, and different parts of a given cloud.

To support the stories, let's start with (more or less) traditional RBAC. We have the following definitions:

**Principals** include users and workflows. Users may be defined by Keystone, or by Craton directly.

**Resources** includes inventory, workflows definitions, and principals, as well as any configuration variables. (Targets in oslo.policy; but targets are also used in defining rules...)

**Roles** represent the various ways Craton is used, including inventory configuration; defining workflows; and running workflows. All such roles in Craton use the ``fleet:`` kind, for direct integration with Oslo policy management. (This is a bit of abuse of terminology, given that oslo.policy calls these targets in defining rules... but see above.)

A **role assignment** is the triple (resource, principal, role).

In addition, Craton will define a number of stock rules in its ``policy.json`` to combine Keystone roles with Craton's roles, as desired; as well as other productions necessary to get the desired logic with respect to any authorization checks as ultimately called by the ``authorize`` method on ``Enforcer`` objects.

With that in mind, we have the following implicit requirement:

*Implementation should not require duplication of the fleet management hierarchy outside of the Craton SQL database, and especially not into a text file. Naively, we can readily model the above usage of the hierarchy scope through suitable production rules in ``policy.json``.*

However, this naive approach is useful for understanding how Craton can combine its approach with oslo.policy as well as other sources of roles, including Keystone: what is stored in the database is for a given resource is exactly what we could have stored in a text file.

To support these stories, and the above requirement, Craton will use the following:

**Scoped role assignments**. Roles can be assigned to a given resource; and any resource in its scope also gets this role. The combination of such roles is performed by a union-all operation. Such scoped roles resemble Microsoft Active Directory's regular scoped roles.

**Specific roles for Craton**. These include standard managing CRUD ops (list, create, get, delete, update), as well as specifics for running workflows (audit, remediate).

**Regex roles**. Rather than fully specifying a role, it can match resources by their name using a regex. (Effectively such roles are really the enumeration of all regex productions...) Something like the following should work: ``fleet:set_/^some-prefix/``, where we are using the standard forward slashes to mark regex literals.

**Label roles**. Example: having the role ``fleet:audit_label_service:compute`` enables running an audit workflow on devices labeled ``service:compute``. This can be considered a further refinement of the scoping provided, and can possibly implement what Active Directory calls exclusive scoped roles, in conjunction with additional production rules.

A preliminary implementation of the SQLAlchemy modeling of scoped role assignments, including the implementation of the union-all algorithm for scoping via an object's ``resolution_order``, can be found in https://gist.github.com/jimbaker/6a4fd7e07a16a318a45d7d1d96819040


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.