yahoo-eng-team team mailing list archive

[Brendan Shephard <1989627@xxxxxxxxxxxxxxxxxx>]

Hey Miguel,

I think we narrowed down the issue to the Horizon side. This is from the
email I tried to send to openstack-discuss but it was blocked for being
too large. Should provide the insights to what is happening here though:

"""
Thanks for your input. I did indeed find that patch and used it to patch my env. In this case though, it didn’t seem to change the API request sent to Neutron.

If I log the data variable at this point after applying the patch. It
contains all of the fields:

2022-09-16 00:01:55,046 35 INFO
openstack_dashboard.dashboards.project.networks.ports.workflows bshephar
- Data variable = {'port_id': '4df563ce-5464-4f7d-8aaf-c5496cdaefda',
'network_id': 'acefae53-b4d5-422f-bcca-dc32a0785d21', 'name': '',
'admin_state': True, 'target_tenant_id':
'3ff28fc7abf742a6b7a0d016771dee49', 'binding__vnic_type': 'normal',
'port_security_enabled': True, 'instance_id':
'ccb72b14-3694-40fa-9b3b-ec1a8d7ef046', 'mac_state': None,
'wanted_groups': ['a3ae6e20-67df-4a72-9d5b-cc21ad87464f']}

 So checking this
         if data['port_security_enabled'] is not None:
            params['port_security_enabled'] = data['port_security_enabled']

This is still True, so we’re setting the param to the data value and
using that in our API call to Neutron.

I’m really not familiar at all with the Horizon code base. So let me
know if I’m misunderstanding the intention of the patch you referenced.
But I think the idea would be to check our params against the actual
value returned from neutron.port_get() and only have fields that are
changed in our params. So when we call the port_update() here:

At least in the case we’re discussing here, that resolves the issue.
This is just rudimentary hackery to see what works, but this fixes the
issue for me (Ignore the LOG line obviously):

❯ diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py
411c411
<         params = self._construct_parameters(data)
---
>         params = self._construct_parameters(request, data)
420c420
<     def _construct_parameters(self, data):
---
>     def _construct_parameters(self, request, data):
424a425,426
>         LOG.info("bshephar - Data variable = %s", data)
>         initial = api.neutron.port_get(request, self.context['port_id'])
431c433,434
<         if data['port_security_enabled'] is not None:
---
>         if (data['port_security_enabled'] is not None and data['port_security_enabled']
>             != initial['port_security_enabled']):

The API call after this change looks like this:

2022-09-16 00:17:49,147 31 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}65efff6982c871ae21a157ab46e4e2bebf69fc8619e8a1512d7ce0dd96b94369"
-H "User-Agent: python-neutronclient" -d \'{"port": {"name": "",
"admin_state_up": true, "security_groups":
["a3ae6e20-67df-4a72-9d5b-cc21ad87464f"], "binding:vnic_type":
"normal"}}\''

And subsequently is accepted by Neutron. So I’m not too sure about the
approach within your existing Horizon framework.


"""


So the problem is that Horizon is always including port_security_enabled: True in the API call. Even though this wouldn't actually change the current state of that parameter. It is blocked by the Oslo policy. I believe the solution is to fix the API request that gets sent from Horizon in this case. We should compare the params we're sending in the request against the current state of the port and only update fields that would be different. This would eliminate the inclusion of port_security_enabled in the request.

I verified that it works as described as well. So I have updated the
component to Horizon for this bug.


** Project changed: neutron => horizon

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1989627

Title:
  Policy enforcement variance between openstackcli and Horizon

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Summary
  Neutron enforces Policy different between Horizon and the openstackcli

  High Level Description
  If a user without admin permission tried to modify security groups on a port via Horizon, they are denied via policy enforcement in line with the defaults from oslopolicy. But the same user is able to modify the port security groups via the CLI.

  Reproduce:
  1. Create a new non-admin user:
  ❯ openstack user create --project bne-home --password-prompt test
  ❯ openstack role add --project bne-home --user test member

  2. Add user to clouds.yaml
    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'

  3. Try to add/remove security group from port using the openstackcli:
  ❯ 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)

  We can see this works. Let's try the same from Horizon. We need to
  login, select Instances > Interfaces > "Edit Security Groups"

  This will deny the request. The error from Horizon is:
  2022-09-14 22:23:13,612 65 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

  Which seems consistent with:
  [root@overcloud-controller-0 horizon]# 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:network_owner or rule:admin_only"

  
  From the Neutron logs for both requests we can see:

  https://paste.opendev.org/show/bn6zKrSXW5321hpJChvd/


  Environment:
  TripleO (current-tripleo)

  Version:
  # podman exec -it neutron_api rpm -q openstack-neutron
  openstack-neutron-20.1.0-0.20220907082912.b4beddd.el9.noarch

  [root@overcloud-controller-0 ~]# podman inspect neutron_api | jq '.[] | "image=\(.Image), image_url=\(.ImageName)"'
  "image=7cf0c193041e437c39fe231c5eb39dc7f3f34229187de8e3d675cda28bdf1525, image_url=quay.io/tripleomastercentos9/openstack-neutron-server:current-tripleo"

  
  Note that this is also an issue for RHOSP16.x:
  https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030468.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1989627/+subscriptions