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

[Pushkar Umaranikar]

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.
https://review.openstack.org/#/c/410394/

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:
https://review.openstack.org/#/c/439890/

[Akihiro Motoki (amotoki)]

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.

[OpenStack Infra (hudson-openstack)]

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

[Akihiro Motoki (amotoki)]

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.

[Ihar Hrachyshka (ihar-hrachyshka)]

- 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.

[Akihiro Motoki (amotoki)]

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

[Akihiro Motoki (amotoki)]

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

[OpenStack Infra (hudson-openstack)]

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

[Ihar Hrachyshka (ihar-hrachyshka)]

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