Notepad for OpenStack RBAC thoughts and discussion
The objective of this exercise it to try and figure out we want out of OpenStack and Role Based Access Control (RBAC). There are for sure going to be implementation details the inhibit being able to immediately adopt the perfect model, but let's define what we want the idea model to look like.
- Must adhere the principal of least privilege, users should have only the privileges they need to do their job and nothing more
- A user should be able to discover what they can do based on the role(s) he/she has
- Must be able to establish role hierarchies where privileges of a child role are accessible to a user given the parent role
- Must provide the ability for operators to override policy if they have their own definitions
- Operators need a way to know exactly what their policy is, including the operations they've overridden
What would it look like for each project to group privileges in ways that fit the following:
A user with a valid token should be able to do these things. These are operations that don't require a project scope. For example, so long as Morgan is a user in the system, he should be able to validate tokens, change his password, or list projects he has the ability to operate within.
Includes protected operations in addition to per-service non-destructive
operations. For example, giving Rick the cinder_observer role on Project A
allows him the ability to list volumes within Project A.
Each project will have their own definition of this role.
This role is a combination of all *_observer roles for each project.
Assigning this role to Machonne on Project B gives her the ability to list
all volumes, instances, networks within Project B.
This role inherits all privileges of the service-specific observer in addition
to permissions for a standard or regular user. For example, assigning Glenn the
nova_member role on Project C would all him the ability to list and create
instances in Project C.
This role is a combination of all service-specific member roles, in addition to
all service-specific observer roles. For example, assigning Eugene the member
role on Project D allows him the ability to create and view instances,
networks, volumes, etc.
This role inherits all privileges of the service-specific member role in
addition to all service-specific actions a domain owner should be able to do.
For example Domain Foo has two projects, development and staging. The
development project contains two instances called instance1 and
instance2 and staging contains an instance called deploy-node. Giving
Maggie the nova_domain_admin role on Domain Foo should give her the ability
to manage instance1, instance2, and deploy-node since all three are
within Domain Foo.
This role inherits all service-specific domain administrator roles. Assigning
Abraham the domain_admin role on Domain E will give him the ability to add
new federated identity providers so that users within his domain can
authenticate with their corporate credentials. At the same time, Abraham will
be able to manage all volumes within Domain E.
This role inherits all privileges of the service-specific domain administrator
role. This should be reserved for privileges that only administrators should be
able to do. For example, assigning Daryl the nova_admin role will allow him
to live migrate instances from a host that is about to undergo maintenance.
This role inherits from all service-specific administrator roles and allows
users the ability to administer the entire deployment. For example, granting
Carol the admin role will allow her to add new services and endpoints as well
as live migrate instances from hosts that are about to undergo maintenance.
There are two problems that inhibit upgrading to a better policy:
- Policies are super generic and elementary (i.e.
adminroles only) - Lack of better policy out of the box has pushed deployer to roll their own
- Move policy into code so that operators can use it to generate exact policy files
- Defining the various roles for each project (i.e.
*_observer,*_member,*_domain_admin,*_global_observer,*_admin)
This is going to need work, but ideally we need to be able to provide a series of steps that allows a deployment to get to better policy in with as little pain as possible. All steps would be taken as an operator or administrator performing the upgrade (note this is only taking into consideration the policy operations required, not the entire upgrade flow):
- Generate an updated policy file that includes overrides for each service
- Ensure all policy files are in place and being used
- Upgrade all the services, backwards-compat should be maintained because the policy files from step one are in place
- Create roles required for the new model, but don't assign them to any users or groups
- Assign users and groups new roles, so they should have all pre-existing roles from the last release and new roles for the new model (this is going to be a deployment wide assessment of permissions)
- Update each service and either remove or prune the various policy files, letting the new model take over where applicable
- Remove unused (old) role assignments from users and groups
- Delete old roles so long as they are not used in any policy files
Who can do What on a Thing?
{
'policies': [
{
'who': [*, user, group],
'what': [operation, role],
'thing': [*, domain, project, object]
}
]
}
{
'policies': [
{
'actor': [
{'user': 'eefd423f4f494c258dd4276dc07aaab7'}
{'group': '0644b4c0b0e8432a93e9295f493c40b6'}
],
'action': [
'os_compute_api:servers:create',
'os_compute_api:servers:delete',
'volume:create'
],
'resource': [
'project:b9f8b78e10fb4fe9b0a87bb6d60f0a15'
'domain:9de5d33310eb4d03a6269cf88ac81c70'
]
}
]
}