[Neutron] [train] Horizon port security group management fails

Radomir Dopieralski rdopiera at redhat.com
Thu Sep 15 13:56:21 UTC 2022 

It's a known problem and there is a patch for it in review for quite some
time: https://review.opendev.org/c/openstack/horizon/+/810224

On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard <bshephar at redhat.com>
wrote:

> Hey all,
>
> I think we might be onto something here. With the help of @Sean Mooney
> <smooney at redhat.com> ++ and @Takashi Kajinami <tkajinam at redhat.com> ++.
> It appears the API request when sent from Horizon contains additional
> fields that don't require update. But when the request comes from
> openstackcli, it is just updating the security group field only.
>
> openstackcli:
> REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT
> https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda
> -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0
> keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H
> "X-Auth-Token:
> {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87"
> -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f",
> "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}'
> https://openstack.bne-home.net:13696 "PUT
> /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002
>
>
> Horizon API call to Neutron:
> 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i
> https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda
> -X PUT -H "X-Auth-Token:
> {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1"
> -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "",
> "admin_state_up": true, "port_security_enabled": true, "security_groups":
> [], "binding:vnic_type": "normal"}}\''
>
> So when Neutron receives that request from Horizon, we get blocked because
> we (as members) are not permitted to update the port_security_enabled
> field. Even though it's already set to true in this case.
>
> Given that information, the bug is probably back on Horizon here to not
> include fields that don't require update.
>
> 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 10:46 PM Albert Braden <ozzzo at yahoo.com> wrote:
>
>> If I add/remove security groups from an instance in Horizon, it works.
>> It's when I add/remove security groups from a port that the error occurs.
>> One way to reproduce is to click on the instance and then go to the
>> "Interfaces" tab, and click "Update Security Groups" on the right.
>> On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard <
>> bshephar at redhat.com> wrote:
>>
>>
>> Hey,
>>
>> I'm doing it from the instances one:
>>
>> https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/
>>
>> But for what it's worth. I get the same error if I do it from:
>>
>> https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail
>>
>> Interesting that it worked for you there. Be good to confirm with
>> @ozzzo at yahoo.com <ozzzo at yahoo.com> as well as to exactly where in
>> Horizon he is trying to modify the security groups. Just so we're all
>> trying to do the exact same thing.
>>
>> My environment is also deployed from the latest tripleo packages, so I'll
>> also test on that internal lab you referenced Sean. That would be more
>> representative of Alberts issue since he is using RHOSP.
>>
>> 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 10:12 PM Sean Mooney <smooney at redhat.com> wrote:
>>
>> 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?
>> > > > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>>
>>

-- 
Radomir Dopieralski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220915/1bbdc043/attachment-0001.htm>

More information about the openstack-discuss mailing list