[RFE] Introduce a new rule with service user role in Neutron policy

Bug #1674349 reported by Pushkar Umaranikar
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Akihiro Motoki

Bug Description

When other services like Nova talks to the Neutron REST API, it uses an admin token, in some scenarios like setting the port binding on a port. In these cases, the admin token is used to ensure only Nova has access to the binding API, not the end user.

With the introduction of service token, we can use service token instead of admin token to perform metadata API services related operations which
currently uses admin token.

In Ocata, Nova started sending a service token along with the user token, so Neutron already knows it is Nova sending a request on behalf of the user.

We can make use new role added by keystoneauth.

"service_roles": "service:<service name>"

The above role can be used in policy to define level of access for an
action when service token is used along with user context. This allows to perform any actions for which we have added service role in policy configurations.

For example, if we want to perform "binding port to host id" operation with service token authentication, we will pass service token along with auth token to communicate with Neutron. In this case, Neutron policy should also allow performing this operation with "service_roles".

Spec in Nova:

tags: added: rfe
description: updated
description: updated
description: updated
Revision history for this message
Akihiro Motoki (amotoki) wrote :

It is mainly up to what parameters are passed to neutron context.
oslo.context supports parameters more than neutron(.auth) supports.
This RFE is completely worth supported.

I can support this RFE.

Changed in neutron:
status: New → Triaged
importance: Undecided → Wishlist
Akihiro Motoki (amotoki)
tags: added: api
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/448538

Changed in neutron:
assignee: nobody → Akihiro Motoki (amotoki)
status: Triaged → In Progress
Revision history for this message
Akihiro Motoki (amotoki) wrote :

To support this we need:
- Retrieve more attributes when constructing context object (use oslo_context.context.Context.from_environ())
- Update the default policy file to lookup service_roles.

The former is a requirement.
The latter can be optional if we update policy.json in devstack or something.

Note that the default value of nova [service_user] send_service_user_token is False now.

Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

- Update the default policy file to lookup service_roles.

I believe we should make our policy.json accept both admin and service roles, and allow nova to opt in that by default later.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Yes, we can add a policy rule like:

    "service_role": "service_roles:<role_name>"
    "update_port:binding:host_id": "rule:admin_only or rule:service_role"

At now, oslo.context provides several service_xxxx fields [1]. we can discuss what kind of default rules would be nice for nova (or other services).

[1] http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py#n281

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Set the status to Triaged as it is not approved as RFE.
IMO this can be handled as a normal bug.

Changed in neutron:
status: In Progress → Triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/448538
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=75c34838ef7132352a34b0c224c2536a5283b1d5
Submitter: Jenkins
Branch: master

commit 75c34838ef7132352a34b0c224c2536a5283b1d5
Author: Akihiro Motoki <email address hidden>
Date: Wed Mar 22 11:55:31 2017 +0000

    Use oslo.context class method to construct context object

    oslo_context.Context.from_environ provides a more generic way
    to contruct a context object from request environment.
    We can support more new attributes supported in keystonemiddleware
    without changing our code.

    Partial-Bug: #1674349
    Closes-Bug: #1621073

    In the unit test, context.tenant_name is replaced to context.project_name
    as it will be the recommended way to access project name now.
    Note that equivalency of project_name and tenant_name will be ensured
    by a depending neutron-lib patch [1], so this change affects nobody.

    [1] https://review.openstack.org/#/c/448537/

    Depends-On: Ieec57d9ea8d95e55499a17e2c04da5e3e78a1557
    Change-Id: Ie48aa843ca8c852b1e93e760d2e3e8aaa38aed56

Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

There is agreement it's a nice isolated enhancement. We don't need a blueprint or a spec for that.

Changed in neutron:
status: Triaged → In Progress
tags: added: rfe-approved
removed: rfe
Changed in neutron:
milestone: none → pike-1
Changed in neutron:
milestone: pike-1 → pike-2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers