Implement Keystone Policy Support
Specification for keystone policy support in ironic. Change-Id: I2efdfd99f553c6f448d3e4ab0fc16a260345ec87 Partial-bug: 1526752
This commit is contained in:
parent
226a752f9b
commit
e436e3f692
|
@ -0,0 +1,212 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
=======================
|
||||||
|
Keystone Policy Support
|
||||||
|
=======================
|
||||||
|
|
||||||
|
https://bugs.launchpad.net/ironic/+bug/1526752
|
||||||
|
|
||||||
|
Keystone and oslo.policy have support for restricting access based on
|
||||||
|
information about the user authenticating, allowing partial access to be
|
||||||
|
granted as configured by operators. This spec lays out how this support will
|
||||||
|
be implemented in ironic.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Ironic has traditionally operated on an "all-or-nothing" access system, only
|
||||||
|
restricting access to passwords. This model is significantly limited when
|
||||||
|
multiple people and groups with different trust levels want to interact with
|
||||||
|
ironic. For example, a hardware technician may need access to set or unset
|
||||||
|
maintenance on the node, but should not have access to provision nodes.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
* Ensure proper metadata, such as role, is derived from the auth_token when
|
||||||
|
authenticating by properly implementing KeystoneMiddleware.auth_token
|
||||||
|
support.
|
||||||
|
|
||||||
|
* Configure each API endpoint to verify a user is permitted by policy to
|
||||||
|
access it.
|
||||||
|
|
||||||
|
* Implement specific restrictions for sensitive information, including
|
||||||
|
configdrives and passwords.
|
||||||
|
|
||||||
|
* Define a simple, sane default policy in code [0]_ , with shipped roles
|
||||||
|
including an admin role with full access; an observer role with
|
||||||
|
read-only access to non-secret information; and a role designed for use
|
||||||
|
by the nova driver, with only access to endpoints required for ironic
|
||||||
|
integration with nova. Names for these roles will be determined during
|
||||||
|
implementation and will be configurable by deployers via policy.json [1]_ .
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
A deployer could implement ironic behind a reverse proxy and use another
|
||||||
|
authentication method to allow or disallow access based on path and HTTP
|
||||||
|
method. This is onerous, does not follow the pattern set by other OpenStack
|
||||||
|
services, and does not provide the granularity that properly implementing
|
||||||
|
policy support would.
|
||||||
|
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
|
||||||
|
State Machine Impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
Users may be restricted by policy from moving nodes within the state machine.
|
||||||
|
However, there are no direct state machine modifications.
|
||||||
|
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
A properly restricted user may receive a 403 error if they are unable to use
|
||||||
|
the method/endpoint combination requested. However, the REST API will not be
|
||||||
|
returning 403 in any case it could not today, for instance, an unauthorized
|
||||||
|
user may receive 403 today. This simply increases the granularity available
|
||||||
|
for configuring this authorization.
|
||||||
|
|
||||||
|
|
||||||
|
Client (CLI) impact
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
A CLI client user will need to have a properly authorized user to perform any
|
||||||
|
requested actions.
|
||||||
|
|
||||||
|
|
||||||
|
RPC API impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
|
||||||
|
Driver API impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Drivers can now enforce policy within any driver_vendor_passthru methods as
|
||||||
|
desired.
|
||||||
|
|
||||||
|
|
||||||
|
Nova driver impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Existing deployments can continue to use a full-admin user as required prior
|
||||||
|
to this feature. Once upgraded, a deployer could use a less-privileged user
|
||||||
|
for nova-ironic interactions.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
This change's primary impact is around improving the security of the system.
|
||||||
|
Deployers of ironic will no longer need to provide an admin credential to
|
||||||
|
manipulate only a small part of ironic's API.
|
||||||
|
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
|
||||||
|
Scalability impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Policy support is a minimal increase in overhead. Additionally, most policies
|
||||||
|
will be implemented early in the API layer, to prevent ironic from doing
|
||||||
|
excessive work before a user is deemed unauthorized.
|
||||||
|
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Deployers will now be able to configure policies, in the policy.json DSL [1]_ ,
|
||||||
|
to meet their specific needs.
|
||||||
|
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Whenever a developer implements a new API method, they will be required to
|
||||||
|
properly check policy and update default policy as necessary.
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
devananda
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
JayF
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Update devstack to configure users properly.
|
||||||
|
* Change configuration of nova in devstack to use new baremetal_driver role.
|
||||||
|
* Document how to utilize policy, including how to create users in keystone
|
||||||
|
and assign them to the baremetal project.
|
||||||
|
* Document any differences in how this impacts users of Keystone API v2 vs v3.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
* Grenade testing to ensure we do not break existing deployments.
|
||||||
|
* Unit testing to ensure policies are being properly enforced.
|
||||||
|
|
||||||
|
|
||||||
|
Upgrades and Backwards Compatibility
|
||||||
|
====================================
|
||||||
|
|
||||||
|
Existing deployers are required to use an admin user for all uses of ironic,
|
||||||
|
these users will continue to have full access to the ironic API, allowing for
|
||||||
|
backwards compatibility.
|
||||||
|
|
||||||
|
On upgrade, a user will be required to create a new project and new users to
|
||||||
|
take advantage of the new policy support.
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
* Default policies will need to be documented.
|
||||||
|
* Install guide will need to be updated with instructions on how to create
|
||||||
|
users with proper roles and project membership.
|
||||||
|
* Documentation must be written instructing users how to utilize the new policy
|
||||||
|
functionality on upgrade.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [0] Oslo Policy in Code
|
||||||
|
https://specs.openstack.org/openstack/oslo-specs/specs/newton/policy-in-code.html
|
||||||
|
.. [1] Policy JSON syntax
|
||||||
|
http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html
|
|
@ -0,0 +1 @@
|
||||||
|
../approved/keystone-policy-support.rst
|
Loading…
Reference in New Issue