[Neutron] [train] Horizon port security group management fails
Sean Mooney
smooney at redhat.com
Thu Sep 15 12:12:28 UTC 2022
On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote:
> Hey Sean,
>
> Thanks for the reply.
>
> For reference, I have all the steps to reproduce along with the relevant
> debug logs attached to this LP:
> https://bugs.launchpad.net/neutron/+bug/1989627
>
> But, to summarize. If I go to any random instance in Horizon as a member
> user - not a admin. Then try to remove any Security Group at all from any
> of the ports it fails with the policy violation (I attached a screenshot of
> where I'm making that change in Horizon). But doing it with the same user
> from the cli works fine. Since I'm editing individual interfaces there,
> rather than the instance itself. I assumed these would all be API calls to
> Neutron from Horizon rather than from Horizon to Nova.
updating the instance securty group will not affect any exsitng ports
when you want to add or remvoe security groups form a port in horizont
you do not do that via the instace secutity group you do it via the port edit dialog
in the port detail view under the network
https://<your cloud goes here>/dashboard/project/networks/ports/<port uuid>/detail
i just did that now on a train cloud we have internally and was able to add and remove a security group on a port.
>
> I just run server list --all to demonstrate I was indeed using a member
> user and not a admin since an admin would have seen VM's from all projects.
>
> I agree with you in principle. It should be exactly the same whether it
> comes from openstackclient or from Horizon. In fact, I was 98% positive I
> would be able to demonstrate the wrong user was being used in this case.
> But unfortunately, my efforts to reproduce it demonstrated that the two are
> indeed handled differently.
what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at
https://<cloud>/dashboard/project/instances/<instance uuid>/
it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud.
specificly this is the redhat internal shared cloud i was testing on.
>
> I believe anyone should be able to reproduce it using the steps I outlined
> on the LP.
>
> Brendan Shephard
>
> Senior Software Engineer
>
> Red Hat APAC <https://www.redhat.com>
>
> 193 N Quay
>
> Brisbane City QLD 4000
> @RedHat <https://twitter.com/redhat> Red Hat
> <https://www.linkedin.com/company/red-hat> Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://red.ht/sig>
> <https://redhat.com/summit>
>
>
> On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney <smooney at redhat.com> wrote:
>
> > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote:
> > > Hey Albert,
> > >
> > > The policy is the default Neutron policy in OpenStack Train. These can
> > indeed be changed and customised, but my assumption is that you haven’t
> > created any custom policies. Horizon uses the default for each service
> > unless it’s been overwritten.
> > policy is defiend server side not client side so it applie equially to all
> > users of the api
> > so the behavior will be the same for horizon or the cli
> > if you ever find a delta because horizon say used a differnt token to make
> > the request that is a securty vulnerablity in horizon and should be
> > reported privatly to the horizon core team :)
> >
> > >
> > > If I create a non-admin user and try to change security groups I also
> > get the same error:
> > > 2022-09-14 22:01:33,370 64 INFO
> > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to
> > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and
> > rule:update_port:binding:vnic_type) and
> > rule:update_port:port_security_enabled) is disallowed by policy
> > >
> > > And I can reproduce your same scenario ff I try via the CLI using these
> > steps:
> > > 1. Add entry for new user to clouds.yaml file:
> > > bne-home-test:
> > > auth:
> > > auth_url: https://openstack.bne-home.net:13000
> > > password: "test"
> > > project_domain_name: Default
> > > project_name: bne-home
> > > user_domain_name: Default
> > > username: test
> > > cacert: ~/.certs/overcloud-cacert.pem
> > > identity_api_version: '3'
> > > region_name: regionOne
> > > volume_api_version: ‘3'
> > >
> > > 2. export OS_CLOUD=bne-home-test
> > >
> > > 3. Try to remove security group from port:
> > > ❯ openstack server show test-lb-net -c security_groups -c addresses -f
> > yaml
> > > addresses:
> > > lb-mgmt-net:
> > > - 172.24.0.90
> > > vlan4-infra:
> > > - 172.20.13.175
> > > security_groups:
> > > - name: management-bne
> > the security group listed in nova is the default security group that will
> > be used by all port create by nova.
> > it only applie to ports created by nova and not ones that are passed in
> > using the uuid of a precreate port.
> >
> > you shoudl in general not mix managing security groups via nova and
> > neutron.
> > horizon shoudl prefer to manage security groups only via neutron if it can.
> > >
> > > ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
> > -c port_security_enabled -c security_group_ids -f yaml
> > > fixed_ips:
> > > - ip_address: 172.20.13.175
> > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
> > > port_security_enabled: true
> > > security_group_ids:
> > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f
> > >
> > > ❯ openstack port unset --security-group
> > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
> > > ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
> > -c port_security_enabled -c security_group_ids -f yaml
> > > fixed_ips:
> > > - ip_address: 172.20.13.175
> > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
> > > port_security_enabled: true
> > > security_group_ids: []
> > >
> > >
> > > Verify that I’m definitely not a admin user:
> > > ❯ openstack server list --all
> > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
> > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
> > >
> > >
> > > I don’t think this user should be allowed to do that via the CLI either.
> > So that could be a bug there. The request in the Neutron server.log when I
> > do it via the CLI:
> > >
> > >
> > user can add or remove security groups without being and admin including
> > removing all securtiy groups thats intended behavior and should not require
> > admin.
> >
> > are you implying that horizon is doing "openstack server list --all" --all
> > is short for --all-tenants.
> > outside of the admin tab in horizon horizon would never pass the equivlent
> > of --all to the nova api.
> > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
> > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a
> > 3ff28fc7abf742a6b7a0d016771dee49 - - default default]
> > 192.168.1.17,172.16.2.85 "PUT
> > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200
> > len: 1102 time: 0.4449480
> > >
> > > VS Horizon:
> > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
> > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a
> > 3ff28fc7abf742a6b7a0d016771dee49 - - default default]
> > 172.20.10.25,172.16.2.85 "PUT
> > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403
> > len: 386 time: 0.2209103
> > >
> > > I have raised a upstream bug for this since I can still reproduce it on
> > the latest version of OpenStack:
> > > https://bugs.launchpad.net/neutron/+bug/1989627
> > > Bug #1989627 “Policy enforcement variance between openstackcli a...” :
> > Bugs : neutron
> > > bugs.launchpad.net
> > policy is enfoced on the nova/neutron api it cant behave differntly for
> > horizon unless horizon is useing the wrong token.
> > i.e. not he users token.
> > >
> > >
> > > Brendan Shephard
> > > Senior Software Engineer
> > > Brisbane, Australia
> > >
> > >
> > >
> > > > On 15 Sep 2022, at 2:25 am, Albert Braden <ozzzo at yahoo.com> wrote:
> > > >
> > > > Hi Brendan, thanks for offering to help! I'll contact you privately
> > with info about some languishing cases.
> > > >
> > > > Here's the policy line:
> > > > "update_port:port_security_enabled": "rule:context_is_advsvc or
> > rule:admin_or_network_owner"
> > > >
> > > > Does this policy only affect Horizon? I'm using the same non-admin
> > user for both CLI and Horizon, on a project where that user is a member.
> > The network was created by the admin user.
> > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
> > bshephar at redhat.com> wrote:
> > > >
> > > >
> > > > Hi Albert,
> > > >
> > > > While I may not be the best person to address your Horizon concern. I
> > can probably help you with your Red Hat support concerns. If you had any
> > issues you wanted addressed, or feedback you wanted to provide. Feel free
> > to give me a yell.
> > > >
> > > > Looking at your Horizon issue though. It seems the default policy file
> > is what prevents you from updating that port. We can see the default policy
> > like this for example:
> > > >
> > > > [root at controller-2 ~]# podman exec -it neutron_api
> > oslopolicy-policy-generator --namespace neutron | grep
> > "update_port:port_security_enabled"
> > > > "update_port:port_security_enabled": "rule:context_is_advsvc or
> > rule:admin_or_network_owner"
> > > >
> > > > When you execute the command via the CLI, which user are you using?
> > Are you just sourcing the overcloudrc file, or using export
> > OS_CLOUD=overcloud. If that’s the case then you would be using the admin
> > user on the CLI, but probably a different user when logging into Horizon.
> > > >
> > > > I too would suggest opening a support case. It sounds like you have
> > previously had a negative experience with that. If you want to open a new
> > one and share the case number with me, I can follow up on that for you. As
> > someone who personally knows a lot of the RHOSP Technical Support team from
> > around the world. I’m confident we can right whatever wrong may have
> > occurred there.
> > > >
> > > > Let me know if I can help in any way.
> > > >
> > > > Regards,
> > > >
> > > > Brendan Shephard
> > > > Senior Software Engineer
> > > > Brisbane, Australia
> > > >
> > > >
> > > >
> > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden <ozzzo at yahoo.com> wrote:
> > > > >
> > > > > On CLI I can type "openstack port set --no-security-group <ID>" to
> > remove all security groups. In Horizon, the equivalent operation would be
> > using the - button to remove all groups and then clicking "Update." Using
> > the + button would be the equivalent of typing "openstack port set
> > --security-group <group ID>". There doesn't seem to be a way to remove a
> > single security group via CLI; I think the only way would be to set
> > --no-security-group and then add back the desired groups.
> > > > >
> > > > > I can successfully add security groups to a port via CLI, or I can
> > remove all security groups. If I go into Horizon and try these operations
> > then I get the error when I click "Update." So it appears that security
> > groups can be added and removed, with port security set, via CLI. We only
> > see the failure when we try to do it via Horizon.
> > > > >
> > > > > Regarding RHOSP support; I assume that you are joking, or maybe
> > haven't experienced the support that they offer.
> > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
> > laurentfdumont at gmail.com> wrote:
> > > > >
> > > > >
> > > > > If you are running RHOSP, you might have a support contract with Red
> > Hat?
> > > > >
> > > > > Are you trying to remove all the security groups from a port that
> > has port_security enabled?
> > > > >
> > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo at yahoo.com
> > <mailto:ozzzo at yahoo.com>> wrote:
> > > > > Unfortunately we are running RHOSP in which Train is the latest and
> > greatest. This is what we see in horizon.log:
> > > > >
> > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
> > 139683266553600] [remote 10.232.233.11:57498 <http://10.232.233.11:57498/>]
> > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac:
> > ((rule:update_port and rule:update_port:binding:vnic_type) and
> > rule:update_port:port_security_enabled) is disallowed by policy
> > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
> > pierre at stackhpc.com <mailto:pierre at stackhpc.com>> wrote:
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > This is more likely to be a Horizon bug than an issue with Kolla
> > itself, since Kolla doesn't change much from the default configuration.
> > > > >
> > > > > You should check Horizon logs in /var/log/kolla/horizon to find the
> > error. I would also encourage you to upgrade to a more recent release,
> > since Train has been marked as End of Life in Kolla recently.
> > > > >
> > > > > Cheers,
> > > > > Pierre Riteau (priteau)
> > > > >
> > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo at yahoo.com
> > <mailto:ozzzo at yahoo.com>> wrote:
> > > > > We're running kolla train and we're seeing an apparent bug when we
> > try to add or remove security groups on a port. We see error "Failed to
> > update port <ID>". It works fine in CLI; we only see this in Horizon. Is
> > this a known bug, or are we doing something wrong?
> > > > >
> > > >
> > >
> > > Hey Albert,
> > >
> > > The policy is the default Neutron policy in OpenStack Train. These can
> > indeed be changed and customised, but my assumption is that you haven’t
> > created any custom policies. Horizon uses the default for each service
> > unless it’s been overwritten.
> > >
> > > If I create a non-admin user and try to change security groups I also
> > get the same error:
> > > 2022-09-14 22:01:33,370 64 INFO
> > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to
> > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and
> > rule:update_port:binding:vnic_type) and
> > rule:update_port:port_security_enabled) is disallowed by policy
> > >
> > > And I can reproduce your same scenario ff I try via the CLI using these
> > steps:
> > > 1. Add entry for new user to clouds.yaml file:
> > > bne-home-test:
> > > auth:
> > > auth_url: https://openstack.bne-home.net:13000
> > > password: "test"
> > > project_domain_name: Default
> > > project_name: bne-home
> > > user_domain_name: Default
> > > username: test
> > > cacert: ~/.certs/overcloud-cacert.pem
> > > identity_api_version: '3'
> > > region_name: regionOne
> > > volume_api_version: ‘3'
> > >
> > > 2. export OS_CLOUD=bne-home-test
> > >
> > > 3. Try to remove security group from port:
> > > ❯ openstack server show test-lb-net -c security_groups -c addresses -f
> > yaml
> > > addresses:
> > > lb-mgmt-net:
> > > - 172.24.0.90
> > > vlan4-infra:
> > > - 172.20.13.175
> > > security_groups:
> > > - name: management-bne
> > >
> > > ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
> > -c port_security_enabled -c security_group_ids -f yaml
> > > fixed_ips:
> > > - ip_address: 172.20.13.175
> > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
> > > port_security_enabled: true
> > > security_group_ids:
> > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f
> > >
> > > ❯ openstack port unset --security-group
> > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda
> > > ❯ openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips
> > -c port_security_enabled -c security_group_ids -f yaml
> > > fixed_ips:
> > > - ip_address: 172.20.13.175
> > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713
> > > port_security_enabled: true
> > > security_group_ids: []
> > >
> > >
> > > Verify that I’m definitely not a admin user:
> > > ❯ openstack server list --all
> > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be
> > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8)
> > >
> > >
> > > I don’t think this user should be allowed to do that via the CLI either.
> > So that could be a bug there. The request in the Neutron server.log when I
> > do it via the CLI:
> > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None
> > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a
> > 3ff28fc7abf742a6b7a0d016771dee49 - - default default]
> > 192.168.1.17,172.16.2.85 "PUT
> > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200
> > len: 1102 time: 0.4449480
> > >
> > > VS Horizon:
> > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None
> > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a
> > 3ff28fc7abf742a6b7a0d016771dee49 - - default default]
> > 172.20.10.25,172.16.2.85 "PUT
> > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403
> > len: 386 time: 0.2209103
> > >
> > > I have raised a upstream bug for this since I can still reproduce it on
> > the latest version of OpenStack:
> > > launchpad-og-image.pngBug #1989627 “Policy enforcement variance between
> > openstackcli a...” : Bugs : neutron
> > > bugs.launchpad.net
> > >
> > >
> > >
> > > Brendan Shephard
> > > Senior Software Engineer
> > > Brisbane, Australia
> > >
> > >
> > >
> > > > On 15 Sep 2022, at 2:25 am, Albert Braden <ozzzo at yahoo.com> wrote:
> > > >
> > > > Hi Brendan, thanks for offering to help! I'll contact you privately
> > with info about some languishing cases.
> > > >
> > > > Here's the policy line:
> > > > "update_port:port_security_enabled": "rule:context_is_advsvc or
> > rule:admin_or_network_owner"
> > > >
> > > > Does this policy only affect Horizon? I'm using the same non-admin
> > user for both CLI and Horizon, on a project where that user is a member.
> > The network was created by the admin user.
> > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard <
> > bshephar at redhat.com> wrote:
> > > >
> > > >
> > > > Hi Albert,
> > > >
> > > > While I may not be the best person to address your Horizon concern. I
> > can probably help you with your Red Hat support concerns. If you had any
> > issues you wanted addressed, or feedback you wanted to provide. Feel free
> > to give me a yell.
> > > >
> > > > Looking at your Horizon issue though. It seems the default policy file
> > is what prevents you from updating that port. We can see the default policy
> > like this for example:
> > > >
> > > > [root at controller-2 ~]# podman exec -it neutron_api
> > oslopolicy-policy-generator --namespace neutron | grep
> > "update_port:port_security_enabled"
> > > > "update_port:port_security_enabled": "rule:context_is_advsvc or
> > rule:admin_or_network_owner"
> > > >
> > > > When you execute the command via the CLI, which user are you using?
> > Are you just sourcing the overcloudrc file, or using export
> > OS_CLOUD=overcloud. If that’s the case then you would be using the admin
> > user on the CLI, but probably a different user when logging into Horizon.
> > > >
> > > > I too would suggest opening a support case. It sounds like you have
> > previously had a negative experience with that. If you want to open a new
> > one and share the case number with me, I can follow up on that for you. As
> > someone who personally knows a lot of the RHOSP Technical Support team from
> > around the world. I’m confident we can right whatever wrong may have
> > occurred there.
> > > >
> > > > Let me know if I can help in any way.
> > > >
> > > > Regards,
> > > >
> > > > Brendan Shephard
> > > > Senior Software Engineer
> > > > Brisbane, Australia
> > > >
> > > >
> > > >
> > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden <ozzzo at yahoo.com> wrote:
> > > > >
> > > > > On CLI I can type "openstack port set --no-security-group <ID>" to
> > remove all security groups. In Horizon, the equivalent operation would be
> > using the - button to remove all groups and then clicking "Update." Using
> > the + button would be the equivalent of typing "openstack port set
> > --security-group <group ID>". There doesn't seem to be a way to remove a
> > single security group via CLI; I think the only way would be to set
> > --no-security-group and then add back the desired groups.
> > > > >
> > > > > I can successfully add security groups to a port via CLI, or I can
> > remove all security groups. If I go into Horizon and try these operations
> > then I get the error when I click "Update." So it appears that security
> > groups can be added and removed, with port security set, via CLI. We only
> > see the failure when we try to do it via Horizon.
> > > > >
> > > > > Regarding RHOSP support; I assume that you are joking, or maybe
> > haven't experienced the support that they offer.
> > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont <
> > laurentfdumont at gmail.com> wrote:
> > > > >
> > > > >
> > > > > If you are running RHOSP, you might have a support contract with Red
> > Hat?
> > > > >
> > > > > Are you trying to remove all the security groups from a port that
> > has port_security enabled?
> > > > >
> > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden <ozzzo at yahoo.com>
> > wrote:
> > > > > > Unfortunately we are running RHOSP in which Train is the latest
> > and greatest. This is what we see in horizon.log:
> > > > > >
> > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid
> > 139683266553600] [remote 10.232.233.11:57498] Failed to update port
> > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and
> > rule:update_port:binding:vnic_type) and
> > rule:update_port:port_security_enabled) is disallowed by policy
> > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau <
> > pierre at stackhpc.com> wrote:
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > This is more likely to be a Horizon bug than an issue with Kolla
> > itself, since Kolla doesn't change much from the default configuration.
> > > > > >
> > > > > > You should check Horizon logs in /var/log/kolla/horizon to find
> > the error. I would also encourage you to upgrade to a more recent release,
> > since Train has been marked as End of Life in Kolla recently.
> > > > > >
> > > > > > Cheers,
> > > > > > Pierre Riteau (priteau)
> > > > > >
> > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden <ozzzo at yahoo.com>
> > wrote:
> > > > > > > We're running kolla train and we're seeing an apparent bug when
> > we try to add or remove security groups on a port. We see error "Failed to
> > update port <ID>". It works fine in CLI; we only see this in Horizon. Is
> > this a known bug, or are we doing something wrong?
> > > > > > >
> > > >
> > >
> >
> >
More information about the openstack-discuss
mailing list