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.
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.
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.
Users may be restricted by policy from moving nodes within the state machine. However, there are no direct state machine modifications.
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.
The 403 response body shall indicate which resource access was denied to.
A CLI client user will need to have a properly authorized user to perform any requested actions.
Drivers can now enforce policy within any driver_vendor_passthru methods as desired.
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.
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.
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.
Deployers will now be able to configure policies, in the policy.json DSL  , to meet their specific needs.
Whenever a developer implements a new API method, they will be required to add a new policy rule to represent that API endpoint or method, define the default rule, enforce the policy appropriately, and update default policy as necessary.
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, an operator must define new keystone roles and assign these to users in order to take advantage of the new policy support. The names for these roles will be determined during implementation.
The operator may choose to customize the policy settings for their deployment.
|||Oslo Policy in Code https://specs.openstack.org/openstack/oslo-specs/specs/newton/policy-in-code.html|
|||(1, 2) Policy JSON syntax http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html|