port can't be created/updated with different tenant's security-group

[Itsuro Oda]

It is available in icehouse.

0. assume admin user executes
1. $ neutron security-group-create --tenant-id tenant1 sec1
2. $ neutron port-create --tenant-id tenant2 --security-groutp <uuid of sec1> net1
  success

But current system (juno and later):
port-create fails with "Security group <uuid of sec1> does not exist".

This is reported by my customer who uses icehouse currently and plans to upgrade to recent release.
This is real use case though above example is simplified a lot.

 This is cased by the following fix:
 https://review.openstack.org/#/c/123187/
I think incompatibility was introduced unintentionally by the fix.

[Gary Kotton (garyk)]

Can you please clarify why the admin user is creating the security group for tenant1 and then creating a port for tenant2 using this security group.
Why are they doing that?

[Itsuro Oda (oda-g)]

It is used to control the communication between a certain group consisting of multiple tenants on a shared network.
Their orchestration system (the admin user) makes a securitygroup which allows the communication between the same securitygroup, and set it to ports which the orchestrator allows to communicate mutually.

Does it make sense ?

Anyway, it is a problem that a possible thing in the past becomes impossible.

[Hirofumi Ichihara (ichihara-hirofumi)]

I can understand orchestration system wants to do. However, I have a question. Can tenant2's user look tenant1's security group? Generally, it's NO. Even if admin assigns tenant1's security group to tenant2's port, tenant2's user cannot look it(that is, what does port-show command show as security-group? empty column?). I think that we should add security group to RBAC objects so that some tenants share a security group.

[Armando Migliaccio (armando-migliaccio)]

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Srijani Das (srijani)]

Hi Itsuro Oda,

Please find the detail analysis for the Bug you have reported (Please find the attachment of the CLI results captured after the testing in my local testbed).

As per the analysis we are able to under the following behavior for the Security Group Rules (with admin and non-admin credentials):

-> Security rules creation with tenant-1(project : admin) on private network-1 : Successfull
-> Security rules creation with tenant-2(project: non-admin) on private network-2 : Successfull
-> Port creation with Security Rules on network-1 : Successfull (Project : Admin)
-> Port creation with Security Rules on network-2: Successfull (Project: non-admin)
-> Port update with the Security group-id(created by Tenant-2) on network-1 (project: Admin) ----> Successfull
-> Port update with the Security group-id(created by Tenant-1) on network-2 (project: non-admin) ----> Not possible because the port created with non-admin privileges.

[Itsuro Oda (oda-g)]

Srijani,

Thank you for following up this.

But it is an old bug report and I am not very interested in it. I am sorry.

The followings are some comments from me.

* Because fixing this changes API behavior, you should consult Neutron cores in charge of API about the right behavior and how to fix this.
* RBAC is now available. It is OK if original motivation (see comment #2) is satisfied by using RBAC.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]