[RBAC] User is not allowed to create port with fixed IP on shared network via RBAC

Bug #1833455 reported by Mauro Oddi
32
This bug affects 7 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Slawek Kaplonski

Bug Description

 1. Create tenant1 with user1 and tenant2 with user 2, assign testrole to both

 2, Change the default policy.json to allow creation of ports with fixed IP address in a shared network:

        ()[root@controller-2 /]# diff /etc/neutron/policy.json /etc/neutron/policy.json.bkp
        78c78
        < "create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner or rule:shared",
        ---
        > "create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner",

 3. As user1 create a network and share it via RBAC to tenant2:

        user1 (overcloud) [stack@undercloud-0 ~]$ openstack network create rbacnet1
        +---------------------------+--------------------------------------+
        | Field | Value |
        +---------------------------+--------------------------------------+
        | admin_state_up | UP |
        | availability_zone_hints | |
        | availability_zones | |
        | created_at | 2019-06-19T18:01:01Z |
        | description | |
        | dns_domain | None |
        | id | 8961329b-08a2-4c7c-88cf-b5cca43ca678 |
        | ipv4_address_scope | None |
        | ipv6_address_scope | None |
        | is_default | False |
        | is_vlan_transparent | None |
        | mtu | 1450 |
        | name | rbacnet1 |
        | port_security_enabled | True |
        | project_id | 4ff7e3db6d64429db1b39f993bb99411 |
        | provider:network_type | None |
        | provider:physical_network | None |
        | provider:segmentation_id | None |
        | qos_policy_id | None |
        | revision_number | 2 |
        | router:external | Internal |
        | segments | None |
        | shared | False |
        | status | ACTIVE |
        | subnets | |
        | tags | |
        | updated_at | 2019-06-19T18:01:02Z |
        +---------------------------+--------------------------------------+
        user1 (overcloud) [stack@undercloud-0 ~]$ openstack network list
        +--------------------------------------+----------+--------------------------------------+
        | ID | Name | Subnets |
        +--------------------------------------+----------+--------------------------------------+
        | 8961329b-08a2-4c7c-88cf-b5cca43ca678 | rbacnet1 | |
        | d6540930-acb2-48f9-8451-da3c5c7622aa | public | 2b59541a-8e12-499f-88d6-7c79c56fcfe9 |
        +--------------------------------------+----------+--------------------------------------+
        user1 (overcloud) [stack@undercloud-0 ~]$ openstack network rbac create --type network --action access_as_shared --target-project ba08ccc271614bf1add0902f73690bac rbacnet1
        +-------------------+--------------------------------------+
        | Field | Value |
        +-------------------+--------------------------------------+
        | action | access_as_shared |
        | id | e377033b-f374-4fd5-8015-9a7426681d7e |
        | name | None |
        | object_id | 8961329b-08a2-4c7c-88cf-b5cca43ca678 |
        | object_type | network |
        | project_id | 4ff7e3db6d64429db1b39f993bb99411 |
        | target_project_id | ba08ccc271614bf1add0902f73690bac |
        +-------------------+--------------------------------------+
        user1 (overcloud) [stack@undercloud-0 ~]$ openstack subnet create --network rbacnet1 --subnet-range 10.0.100.0/24 --dhcp rbacsubnet1
        +-------------------+--------------------------------------+
        | Field | Value |
        +-------------------+--------------------------------------+
        | allocation_pools | 10.0.100.2-10.0.100.254 |
        | cidr | 10.0.100.0/24 |
        | created_at | 2019-06-19T18:10:50Z |
        | description | |
        | dns_nameservers | |
        | enable_dhcp | True |
        | gateway_ip | 10.0.100.1 |
        | host_routes | |
        | id | c00f565b-e4eb-4bf5-852c-8a22b95911fa |
        | ip_version | 4 |
        | ipv6_address_mode | None |
        | ipv6_ra_mode | None |
        | name | rbacsubnet1 |
        | network_id | 8961329b-08a2-4c7c-88cf-b5cca43ca678 |
        | project_id | 4ff7e3db6d64429db1b39f993bb99411 |
        | revision_number | 0 |
        | segment_id | None |
        | service_types | |
        | subnetpool_id | None |
        | tags | |
        | updated_at | 2019-06-19T18:10:50Z |
        +-------------------+--------------------------------------+

 4. As user2 try to create a port with a fixed IP

        user2 (overcloud) [stack@undercloud-0 ~]$ . user2_rc
        user2 (overcloud) [stack@undercloud-0 ~]$ openstack network list
        +--------------------------------------+----------+--------------------------------------+
        | ID | Name | Subnets |
        +--------------------------------------+----------+--------------------------------------+
        | 8961329b-08a2-4c7c-88cf-b5cca43ca678 | rbacnet1 | c00f565b-e4eb-4bf5-852c-8a22b95911fa |
        | d6540930-acb2-48f9-8451-da3c5c7622aa | public | 2b59541a-8e12-499f-88d6-7c79c56fcfe9 |
        +--------------------------------------+----------+--------------------------------------+
        user2 (overcloud) [stack@undercloud-0 ~]$ openstack network show rbacnet1 | grep shared
        | shared | True |

        user2 (overcloud) [stack@undercloud-0 ~]$ openstack port create portx10 --network rbacnet1 --fixed-ip subnet=rbacsubnet1,ip-address=10.0.100.123
        HttpException: 403: Client Error for url: http://10.0.0.112:9696/v2.0/ports, {"NeutronError": {"message": "(rule:create_port and rule:create_port:fixed_ips) is disallowed by policy", "type": "PolicyNotAuthorized", "detail": ""}}

 5. Creating the port without fixed IP works fine

        user2 (overcloud) [stack@undercloud-0 ~]$ openstack port create portx11 --network rbacnet1
        +-----------------------+----------------------------------------------------------------------------+
        | Field | Value |
        +-----------------------+----------------------------------------------------------------------------+
        | admin_state_up | UP |
        | allowed_address_pairs | |
        | binding_host_id | None |
        | binding_profile | None |
        | binding_vif_details | None |
        | binding_vif_type | None |
        | binding_vnic_type | normal |
        | created_at | 2019-06-19T18:28:49Z |
        | data_plane_status | None |
        | description | |
        | device_id | |
        | device_owner | |
        | dns_assignment | None |
        | dns_domain | None |
        | dns_name | None |
        | extra_dhcp_opts | |
        | fixed_ips | ip_address='10.0.100.15', subnet_id='c00f565b-e4eb-4bf5-852c-8a22b95911fa' |
        | id | 7fe12e20-0e2c-4801-9742-da2eeef63f43 |
        | mac_address | fa:16:3e:99:6e:6b |
        | name | portx11 |
        | network_id | 8961329b-08a2-4c7c-88cf-b5cca43ca678 |
        | port_security_enabled | True |
        | project_id | ba08ccc271614bf1add0902f73690bac |
        | qos_policy_id | None |
        | revision_number | 2 |
        | security_group_ids | 063f4f88-24f8-442d-b1b4-d0f9e5bc4f9b |
        | status | DOWN |
        | tags | |
        | trunk_details | None |
        | updated_at | 2019-06-19T18:28:49Z |
        +-----------------------+----------------------------------------------------------------------------+

Expected result is that the port with fixed IP should be created following the policy.
Even though rule:shared should be honored, the policy is intepreted within an admin context where the network looks like shared = False.

Description is similar to an older bug:
  - https://bugs.launchpad.net/neutron/+bug/1543756

Changed in neutron:
importance: Undecided → Medium
status: New → Confirmed
assignee: nobody → Slawek Kaplonski (slaweq)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.opendev.org/666816

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

Reviewed: https://review.opendev.org/666816
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d5edb080b080bc5d5221f8586fc6ffdca7ab8b67
Submitter: Zuul
Branch: master

commit d5edb080b080bc5d5221f8586fc6ffdca7ab8b67
Author: Slawek Kaplonski <email address hidden>
Date: Fri Jun 21 13:09:05 2019 +0200

    Treat networks shared by RBAC in same way as shared with all tenants

    In patch [1] handle of networks with "shared" flag set to True was
    fixed and it is now possible to use "rule:shared" in API policy in
    actions related e.g. to ports or subnets.
    But network can be shared with some specific tenant only by doing it
    with RBAC mechanism and in such case it didn't work with [1] only.
    It was like that because context.get_admin_context() was used to get
    network so this returned network had got shared=False set even if
    request comes from tenant for which network was shared through RBAC.

    Now network will be always get with context which have got set proper
    tenant_id so "shared" flag will be set properly even in case if it's
    shared through RBAC.

    [1] https://review.opendev.org/#/c/652636/

    Change-Id: I38615c0d18bb5a1f22f3e7865ce24615a540aa9a
    Closes-Bug: #1833455

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/stein)

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/668089

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/rocky)

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/668090

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/queens)

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/668091

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/stein)

Reviewed: https://review.opendev.org/668089
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fc278a925129d19ca1ce0bd0c39523a6c3288363
Submitter: Zuul
Branch: stable/stein

commit fc278a925129d19ca1ce0bd0c39523a6c3288363
Author: Slawek Kaplonski <email address hidden>
Date: Fri Jun 21 13:09:05 2019 +0200

    Treat networks shared by RBAC in same way as shared with all tenants

    In patch [1] handle of networks with "shared" flag set to True was
    fixed and it is now possible to use "rule:shared" in API policy in
    actions related e.g. to ports or subnets.
    But network can be shared with some specific tenant only by doing it
    with RBAC mechanism and in such case it didn't work with [1] only.
    It was like that because context.get_admin_context() was used to get
    network so this returned network had got shared=False set even if
    request comes from tenant for which network was shared through RBAC.

    Now network will be always get with context which have got set proper
    tenant_id so "shared" flag will be set properly even in case if it's
    shared through RBAC.

    [1] https://review.opendev.org/#/c/652636/

    Change-Id: I38615c0d18bb5a1f22f3e7865ce24615a540aa9a
    Closes-Bug: #1833455
    (cherry picked from commit d5edb080b080bc5d5221f8586fc6ffdca7ab8b67)

tags: added: in-stable-stein
tags: added: in-stable-rocky
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/rocky)

Reviewed: https://review.opendev.org/668090
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9b7ba672d2d952f166c872e2acf609ff2006666b
Submitter: Zuul
Branch: stable/rocky

commit 9b7ba672d2d952f166c872e2acf609ff2006666b
Author: Slawek Kaplonski <email address hidden>
Date: Fri Jun 21 13:09:05 2019 +0200

    Treat networks shared by RBAC in same way as shared with all tenants

    In patch [1] handle of networks with "shared" flag set to True was
    fixed and it is now possible to use "rule:shared" in API policy in
    actions related e.g. to ports or subnets.
    But network can be shared with some specific tenant only by doing it
    with RBAC mechanism and in such case it didn't work with [1] only.
    It was like that because context.get_admin_context() was used to get
    network so this returned network had got shared=False set even if
    request comes from tenant for which network was shared through RBAC.

    Now network will be always get with context which have got set proper
    tenant_id so "shared" flag will be set properly even in case if it's
    shared through RBAC.

    [1] https://review.opendev.org/#/c/652636/

    Change-Id: I38615c0d18bb5a1f22f3e7865ce24615a540aa9a
    Closes-Bug: #1833455
    (cherry picked from commit d5edb080b080bc5d5221f8586fc6ffdca7ab8b67)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/queens)

Reviewed: https://review.opendev.org/668091
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9dc82e90670e289759442cf4919b9fd0655f3c43
Submitter: Zuul
Branch: stable/queens

commit 9dc82e90670e289759442cf4919b9fd0655f3c43
Author: Slawek Kaplonski <email address hidden>
Date: Fri Jun 21 13:09:05 2019 +0200

    Treat networks shared by RBAC in same way as shared with all tenants

    In patch [1] handle of networks with "shared" flag set to True was
    fixed and it is now possible to use "rule:shared" in API policy in
    actions related e.g. to ports or subnets.
    But network can be shared with some specific tenant only by doing it
    with RBAC mechanism and in such case it didn't work with [1] only.
    It was like that because context.get_admin_context() was used to get
    network so this returned network had got shared=False set even if
    request comes from tenant for which network was shared through RBAC.

    Now network will be always get with context which have got set proper
    tenant_id so "shared" flag will be set properly even in case if it's
    shared through RBAC.

    [1] https://review.opendev.org/#/c/652636/

    Change-Id: I38615c0d18bb5a1f22f3e7865ce24615a540aa9a
    Closes-Bug: #1833455
    (cherry picked from commit d5edb080b080bc5d5221f8586fc6ffdca7ab8b67)

tags: added: in-stable-queens
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 15.0.0.0b1

This issue was fixed in the openstack/neutron 15.0.0.0b1 development milestone.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 14.0.3

This issue was fixed in the openstack/neutron 14.0.3 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 13.0.5

This issue was fixed in the openstack/neutron 13.0.5 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 12.1.1

This issue was fixed in the openstack/neutron 12.1.1 release.

Revision history for this message
Krzysztof Pawlowski (krzysztof.pawlowski) wrote :

It's not working on rocky and stein release because default policy contains:

    "create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner",
    "update_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner",

But it should be

    "create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner or rule:shared",
    "update_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:admin_or_network_owner or rule:shared",

The same bug exists in the stein, train and ussuri release with policy in the code.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/886214

Revision history for this message
Satish Patel (satish-txt) wrote :

What is the status of this BUG. We are still seeing this on Zed release.

Following flags not working and getting error.

"create_port:fixed_ips": "rule:context_is_advsvc or rule:network_owner or rule:admin_only or rule:shared"
"create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:network_owner or rule:admin_only or rule:shared"
"create_port:fixed_ips:subnet_id": "rule:context_is_advsvc or rule:network_owner or rule:admin_only or rule:shared"

Error:

"create_port:fixed_ips": "rule:context_is_advsvc or rule:network_owner or rule:admin_only or rule:shared"
"create_port:fixed_ips:ip_address": "rule:context_is_advsvc or rule:network_owner or rule:admin_only or rule:shared"
"create_port:fixed_ips:subnet_id": "rule:context_is_advsvc or rule:network_owner or rule:admin_only or rule:shared"

Revision history for this message
Andrew Bogott (andrewbogott) wrote :

> What is the status of this BUG. We are still seeing this on Zed release.

My patch (https://review.opendev.org/c/openstack/neutron/+/886214) is stuck in limbo, I think because of a chicken/egg issue with the tempest tests. I would welcome help on this!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/886214
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron-tempest-plugin (master)

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/890248
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Can You maybe elaborate more why You need to change default policy in such way? I'm not sure if we should do it like that really.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.