'openstack port list' should display ports only from current project

[Kiran Pawar]

When a network is shared between multiple projects, "openstack port list" command shows ports from all projects which have access to that network. This is a problem because each port actually has a “project_id“ property, and the port cannot be used for any instance outside of that project. When a user attempts to start an instance with a port from a different project, it fails like this: nova.exception.PortNotUsable

Steps to reproduce in horizon :-
===============================

1. create network and share network between 2 projects
2. from Project A, manually create a port “Test Port“ on the network
   note that the port will have the project_id for Project A
3. from Project B, open the Launch Instance workflow navigate to
   “Network Ports”
4. At this point, you will see “Test Port” in the list. If you use it
   for the instance from Project B, the instance will fail

Currently, User can use --project-id="xxxx" as option to "openstack port list" command to get desired result. But this needs to be taken care at every neutron client e.g. nova or manila or openstackclient or horizon.

Instead, ff we modify neutron itself to return only ports belonging to current project in 'openstack port list' command response (without specifying --project-id) (at least for non-admin users), it would be good improvement.

[OpenStack Infra (hudson-openstack)]

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

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

As commented in the patch, I don't think this is an issue in the Neutron code. The "port list" command is returning a valid list. The Nova compute service is rejecting this code because of a check [1] implemented 7 years ago. This check does not consider the existence of shared resources (network and their ports).

[1]https://github.com/openstack/nova/blob/2eb358cdcec36fcfe5388ce6982d2961ca949d0a/nova/network/neutron.py#L758-L760

[Darrick Horton (vmaccel)]

I believe this is an issue in Neutron. The check in Nova from 7 years ago is correct - users should not be able to use ports from other projects. Users may customize ports for their specific needs and workload, so we don't want any random person with access to the same network to be able to utilize a custom port created by a different user. Because of this, we should not show ports to users from other projects, even if they have access to the same network

If the concept of a "shared port" is desired, then that functionality should be made possible with a new RBAC policy. This way, users could share ports if they want to in the same manner they share Networks and Security Groups.

[Kiran Pawar (kpawar)]

User should be able to see all ports, at least network owners. I believe the command should work in below way :

Assume there are two project project1, project2 and share network is created by project1

commands for all users:
when logged in with project1 context
 1) openstack port list ---> should list ports owned by project1 in any network (currently also shows ports owned by other projects which are in networks owned by project1)
 2) openstack port list --project project1_id ---> should be the same as above (currently works)

So if project_id is not specified, it will take default project_id from context in consideration and only show ports owned by it.

commands for admins AND network owners:
 1) openstack port list --all-projects
    IF admin; then show all ports
    IF network_owner; then show all owned_ports AND all ports ON networks owned by network_owner

 2) openstack port list --project project2
    IF admin; then show all ports owned by project2
    IF network_owner; then show all ports owned by project2 ON networks owned by network_owner

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello:

Neutron currently doesn't provide a RBAC functionality on ports. As commented, the port is listed depending on (1) the network RBAC policies and (2) the policy rules.

When a network is created by project A, the user of this project is able, by default, to see all ports belonging to this network. If this user shared via RBAC this network with project B, this other project will be able to create ports on this network.

What we have here is the following:
* Project A user will be able to list all ports in the network because:
** The project owns the network
** By default, the "get_port" policy includes "rule:admin_owner_or_network_owner". That means all ports belonging to this network, regardless of the owner, will be shown.

* Project B user will be able to list all ports in this network **created by this project**. Project B user won't be able to list Project A ports (owner of the network).

The first case is what we have in this bug. This is the expected correct behaviour of Neutron.

Regarding to the interaction with other projects, as in this case Nova, this is a known issue that is also affecting for example the security groups retrieval. In this case Nova always rejects a port that doesn't belong to the same project ID executing the request. With the correct policies ('update_port:device_owner', 'update_port:binding:host_id' and 'update_port:binding:profile'), Nova should be able to bind a port. As commented before, this Nova check is something that needs to be discussed. Nova should be able, with the correct checks, to use ports belonging to other projects; but this RFE is out of scope in this bug.

If in your case you want to exclude the ports created by other projects in the "port list" command, you can use the correct Neutron policies. For example:
  "get_port": "rule:admin_or_owner"

I'll set the status of this bug to "Opinion" unless more information is provided.

Regards.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/864303
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.