A common policy scenario across all projects
All projects should provide a policy file based around a more rich scenario than simply is a user the global admin or not. Change-Id: I6a0957f9c1437627c6310d36d652b2fb3cb63eb9
This commit is contained in:
Jamie Lennox
Adam Young
parent
70a7c6d7dd
commit
e301823d78
|
|
@ -0,0 +1,238 @@
|
|||
=====================
|
||||
Common Default Policy
|
||||
=====================
|
||||
|
||||
https://blueprints.launchpad.net/+spec/common-default-policy
|
||||
|
||||
Maintaining policy is hard for operators. As a side effect of keystone's V2
|
||||
roles and devstack's default roles most services simply assume a member or
|
||||
admin privilege separation for their service. This is really only sufficient
|
||||
for the most trivial of deployments.
|
||||
|
||||
As a community we need to develop a simple standard usage policy environment
|
||||
such that we incorporate some of the common deployment patterns of OpenStack
|
||||
and reduce the policy burdens on operators.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
For customizeability, roles in OpenStack are defined at runtime by
|
||||
administrators and stored in the keystone database. Keystone therefore does not
|
||||
ship with any roles by default. In contrast, sample policy files are static
|
||||
files that are typically shipped with the project defining what roles are
|
||||
required to access an endpoint.
|
||||
|
||||
This mismatch has meant that services using policy files must ship with default
|
||||
configuration files that may or may not reflect the actual roles that are
|
||||
present in a deployment. Most predominantly, deployers at the Tokyo summit
|
||||
reported adding custom "observer" roles for auditing (read-only) and
|
||||
service-specific "admin" roles to satisfy the principle of least privilege.
|
||||
|
||||
Largely as a side effect of keystone V2 initially having only an
|
||||
admin/non-admin role distinction and devstack testing a simple deployment
|
||||
schema by default most services ship a policy file consisting of only the
|
||||
admin/non-admin distinction using the admin role (Note that you must have some
|
||||
role on the project to be authenticated but there is no need to define this
|
||||
role by name). A result of this is the all powerful admin role that must be
|
||||
created in deployments and overly powerful service users.
|
||||
|
||||
Having shipped these policy files we then expect deployers to customize them to
|
||||
suit their needs. However, as these are security critical files that must be
|
||||
delicately updated and re-merged with every release, there is a general
|
||||
reluctance to modify these files, or at least very little. Once a revised
|
||||
policy file is ready for deployment, it can then be a configuration management
|
||||
challenge to synchronously deploy that policy across all API nodes.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Let us define a conventional schema that will be enabled and shipped as the
|
||||
default policy file for services. This schema will be backwards compatible with
|
||||
the current admin/non-admin that we currently have.
|
||||
|
||||
As individual services are not aware of all the roles in the deployment, there
|
||||
is no issue with defining roles in policy files that are not available in the
|
||||
deployment. These roles are never present in a token and therefore never match.
|
||||
This means that there is no danger in changing these policy files to use roles
|
||||
prior to them being available from the identity service.
|
||||
|
||||
The only chance of collision here is that we create a role with the same name
|
||||
but different meaning to one that exists in a deployment. For this to happen/be
|
||||
useful the deployment must already be modifying policy files and can therefore
|
||||
plan a migration to the new role names or continue to ship their custom policy
|
||||
files.
|
||||
|
||||
We do not expect to come up with a convention that solves problems for
|
||||
everyone. There will always be custom requirements that involve a more complex
|
||||
policy setup that are not relevant to the general community. The aim here is to
|
||||
create a scheme that will improve control for the deployers who do not wish to
|
||||
make their own policy modifications, and provide a base that we can improve on
|
||||
as required in future.
|
||||
|
||||
The roles
|
||||
---------
|
||||
|
||||
**admin**: Due to its prevalence today, we need to maintain the 'admin' role. A
|
||||
user with this role is all powerful and is expected to be able to do anything
|
||||
in OpenStack. Ideally this scope would only extend to the project the user has
|
||||
the role on (like all roles should), however there are circumstances today
|
||||
where the admin role implies having admin on the entire deployment and is
|
||||
capable of doing things in other projects. This role should be strictly
|
||||
controlled in any deployment.
|
||||
|
||||
**service**: The service role should only be given to service users, these are
|
||||
the users that are in auth_token middleware and are able to validate other
|
||||
user's tokens.
|
||||
|
||||
**{service_type}_admin**: A role that gives administrative access to one
|
||||
service. The service type here is the identifying service type that is
|
||||
available from the service catalog. For example there would be a
|
||||
*_compute_admin_* and an *_image_admin_* role and not a *nova_admin* or
|
||||
*glance_admin* role. In the same way as _admin_ these are ideally scoped to the
|
||||
project however they convey the ability to do operations that are across
|
||||
projects when required. Eg. The *identity_admin* role should be able to create
|
||||
new domains, something for which there is not an obvious project to scope to.
|
||||
|
||||
**observer**: The observer role allows a user to discover the resources
|
||||
available across OpenStack, regardless of tenancy, but have no access to
|
||||
create, modify, or delete resources. This has been termed variously the
|
||||
accountant, the auditor, viewer, or the observer role.
|
||||
|
||||
**{service_type}_observer**: A role allows a user to discover the resources
|
||||
available within a specific service, regardless of tenancy, but have no access
|
||||
to create, modify, or delete resources.
|
||||
|
||||
Note that there is an implied member role that is typically present in
|
||||
OpenStack as a user is part of a project if they have a role on that project.
|
||||
The name of this role is not important here because we don't test for it
|
||||
specifically for project membership, for most operations we just want to know a
|
||||
user has any role in a project.
|
||||
|
||||
Related Features
|
||||
----------------
|
||||
|
||||
There are a number of features from keystone that have tried to make roles and
|
||||
policy more approachable.
|
||||
|
||||
`Implied roles`_ provides a means within keystone to delegate multiple roles or
|
||||
capabilities with the assignment of a single role, to have one role imply
|
||||
others. This in future will simplify policy files because we are able to
|
||||
enforce access control based on the presence of a low level role but delegate
|
||||
permissions based on high level roles.
|
||||
|
||||
For example, reading an image from glance may require the ImageReader role,
|
||||
creating a volume in cinder may require VolumeCreator role. However a role
|
||||
called InstanceCreator to boot an instance in nova may be created that implies
|
||||
all other roles such as ImageReader and VolumeCreator may be delegated.
|
||||
|
||||
Additionally, and particularly valuable in combination with this spec, is the
|
||||
ability to formally structure roles and query the relationships between them.
|
||||
|
||||
`Admin Project`_ allows an administrator to specify a single administrative
|
||||
project in keystone within which all cross-project operations must be
|
||||
performed. If a user is authenticated within the specified admin project the
|
||||
is_admin_project flag is set within the user's token. Policy should then
|
||||
enforce that operations that are not project specific should be performed only
|
||||
with the is_admin_project flag.
|
||||
|
||||
This behaviour of cross project operations based on the presence of the flag
|
||||
will also be applied to the roles specified here such that
|
||||
*{service_type}_admin* etc should be granted within the admin project to
|
||||
perform cross project admin operations.
|
||||
|
||||
.. _Implied roles: https://review.openstack.org/#/c/125704/
|
||||
.. _Admin Project: https://review.openstack.org/#/c/242232/
|
||||
|
||||
Personas
|
||||
========
|
||||
|
||||
The proposed roles are specified in to align with the proposed and expected
|
||||
`OpenStack Personas`_ roles.
|
||||
|
||||
`Infrastructure Architect`_ and `Cloud ops`_ are represented by the
|
||||
traditional admin role in the administrative project. They have administrative
|
||||
access on the entire deployment at different points in the lifecycle.
|
||||
|
||||
`Service Admin`_ will be given the new service specific *{service_type}_admin*
|
||||
role for their service. For example the nova specialist would get the
|
||||
*compute_admin* role.
|
||||
|
||||
`Domain Ops`_ are provided the admin role on either a specific project or a
|
||||
specific domain. This lets them manage cloud resources.
|
||||
|
||||
`Dev Ops`_ are our typical cloud users and will receive a member role in a
|
||||
project.
|
||||
|
||||
In future there is discussion about requiring an Observer or Accountant Persona
|
||||
that is able to perform read only operations such as list all instances in a
|
||||
project or domain for accounting purposes. This user will be given the
|
||||
*observer* or *{service_type}* observer in the appropriate project or domain.
|
||||
Giving a user the *observer* role in the admin project conveys the ability to
|
||||
observe non-project resources like the number of active hypervisors.
|
||||
|
||||
.. _OpenStack Personas: https://wiki.openstack.org/wiki/OpenStack_Personas_2015
|
||||
.. _Infrastructure Architect: https://wiki.openstack.org/wiki/OpenStack_Personas_2015_Infrastructure_Architect
|
||||
.. _Service Admin: https://wiki.openstack.org/wiki/OpenStack_Personas_2015_Service_Admin
|
||||
.. _Domain Ops: https://wiki.openstack.org/wiki/OpenStack_Personas_2015_Domain_Ops
|
||||
.. _Dev Ops: https://wiki.openstack.org/wiki/OpenStack_Personas_2015_Dev_Ops
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
jamielennox
|
||||
|
||||
Though I expect to engage at least one core team member per service to actually
|
||||
determine which APIs should be accessible by individual roles. This is
|
||||
something that only someone with an understanding of the API should do.
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
The intention will be that the new schema is backwards compatible with the
|
||||
policy files that we are currently shipping with services. The admin/member
|
||||
distinction that is currently in use will still be available there will just be
|
||||
additional roles suggested in policies.
|
||||
|
||||
There is therefore not a strict ordering to any of the work items as the
|
||||
functionality will be available as services change their own policy files. I
|
||||
also expect a change like this to take time to filter across all of the
|
||||
services.
|
||||
|
||||
- Create a wiki/other document for describing the schema and roles available
|
||||
in the default policy. We never want the default policy to include all
|
||||
possible use cases but we want to be able to control and review additions to
|
||||
the default policy in future.
|
||||
|
||||
- Create additional roles in devstack for testing.
|
||||
|
||||
- Modify each individual service to provide a policy file that implements the
|
||||
above schema and make these policy rules the default.
|
||||
|
||||
- Ensure that horizon (as a consumer of policy files) is capable of correctly
|
||||
displaying available actions to users based on a more complex policy.
|
||||
|
||||
- Update installers/configuration management systems to create new roles.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Mitaka
|
||||
- Introduced
|
||||
|
||||
.. note::
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
Loading…
Reference in New Issue