[Yahoo-eng-team] [Bug 1938788] Re: Validate if fixed_ip given for port isn't the same as subnet's gateway_ip
** Changed in: neutron Status: In Progress => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1938788 Title: Validate if fixed_ip given for port isn't the same as subnet's gateway_ip Status in neutron: Opinion Bug description: Currently when new port is created with fixed_ip given, neutron is not validating if that fixed_ip address isn't the same as subnet's gateway IP. That may cause problems, like e.g.: $ openstack subnet show | allocation_pools | 10.0.0.2-10.0.0.254 | cidr | 10.0.0.0/24 | enable_dhcp | True ... | gateway_ip| 10.0.0.1 $ nova boot --flavor test --image test --nic net-id=,v4-fixed-ip=10.0.0.1 test-vm1 The instance will be created successfully, but after that, network communication issue could be happened since the gateway ip conflict. So Neutron should forbid creation of the port with gateway's ip address if it is not router's port (device_owner isn't set for one of the router device owners). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1938788/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1939020] [NEW] nova-manage placement heal_allocations does not support instances with VGPU or Cyborg device profile request
Public bug reported: The nova-manage placement heal_allocations tool predates nested allocation support in nova. It gained explicit support for nested allocation only in case if the nested resources are coming from the port resource request [1]. If the resource request are coming from the flavor extra_specs (e.g. resources:VGPU=1) then the tool assumes that such resource can be fulfilled from the root resource provider[2][3]. This is obviously wrong for the VGPU resource that are provided on nested resource providers. Also [3] does not resolve cyborg device profiles to request groups so that request is also ignored. As --force flag allows recreating instance allocations even if the tool does not detect a missing allocation using the tool on VGPU and Cyborg instances could result in loosing otherwise correct resource allocations. Loosing such resource allocation can lead to physical resource over-allocation later. [1] https://github.com/openstack/nova/blob/2ffd9738602531e93495a1feca76bbb687c3e72c/nova/cmd/manage.py#L1814 [2] https://github.com/openstack/nova/blob/2ffd9738602531e93495a1feca76bbb687c3e72c/nova/cmd/manage.py#L1700 [3] https://github.com/openstack/nova/blob/2ffd9738602531e93495a1feca76bbb687c3e72c/nova/scheduler/utils.py#L607-L614 ** Affects: nova Importance: Wishlist Assignee: Sylvain Bauza (sylvain-bauza) Status: Confirmed ** Tags: nova-manage ** Tags added: nova-manage -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1939020 Title: nova-manage placement heal_allocations does not support instances with VGPU or Cyborg device profile request Status in OpenStack Compute (nova): Confirmed Bug description: The nova-manage placement heal_allocations tool predates nested allocation support in nova. It gained explicit support for nested allocation only in case if the nested resources are coming from the port resource request [1]. If the resource request are coming from the flavor extra_specs (e.g. resources:VGPU=1) then the tool assumes that such resource can be fulfilled from the root resource provider[2][3]. This is obviously wrong for the VGPU resource that are provided on nested resource providers. Also [3] does not resolve cyborg device profiles to request groups so that request is also ignored. As --force flag allows recreating instance allocations even if the tool does not detect a missing allocation using the tool on VGPU and Cyborg instances could result in loosing otherwise correct resource allocations. Loosing such resource allocation can lead to physical resource over-allocation later. [1] https://github.com/openstack/nova/blob/2ffd9738602531e93495a1feca76bbb687c3e72c/nova/cmd/manage.py#L1814 [2] https://github.com/openstack/nova/blob/2ffd9738602531e93495a1feca76bbb687c3e72c/nova/cmd/manage.py#L1700 [3] https://github.com/openstack/nova/blob/2ffd9738602531e93495a1feca76bbb687c3e72c/nova/scheduler/utils.py#L607-L614 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1939020/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1930597] Re: Doc for "Configuring SSL Support" outdated in glance
Reviewed: https://review.opendev.org/c/openstack/glance/+/802868 Committed: https://opendev.org/openstack/glance/commit/652780d0299d5734cbc6d21eea74c4fd11797cd1 Submitter: "Zuul (22348)" Branch:master commit 652780d0299d5734cbc6d21eea74c4fd11797cd1 Author: Erno Kuvaja Date: Thu Jul 29 13:02:20 2021 +0100 Remove SSL configuration section from docs Since supporting only PY3 (Ussuri) Glance has not been supporting termination of encrypted connection to the service [0]. The section was left behind on the configuring doc. [0] https://docs.openstack.org/releasenotes/glance/ussuri.html#security-issues Change-Id: I9356bceb914327f526da7b727fa58522ae18856e Closes-Bug: #1930597 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1930597 Title: Doc for "Configuring SSL Support" outdated in glance Status in Glance: Fix Released Status in Glance ussuri series: Triaged Status in Glance victoria series: Triaged Status in Glance wallaby series: Triaged Status in Glance xena series: Fix Released Bug description: The "Configuring SSL Support" states that `cert_file`, `key_file` and `ca_file` can be set to enable TLS. But on the [changelog of Ussuri](https://docs.openstack.org/releasenotes/glance/ussuri.html) it is mentioned that: > If upgrade is conducted from PY27 where ssl connections has been terminated into glance-api, the termination needs to happen externally from now on. So the `cert_file`, `key_file` and `ca_file` configuration options should be removed from the documentation. --- Release: 22.0.0.0rc2.dev2 on 2020-05-24 10:41:41 SHA: b5437773b20db3d6ef20d449a8a43171c8fc7f69 Source: https://opendev.org/openstack/glance/src/doc/source/configuration/configuring.rst URL: https://docs.openstack.org/glance/wallaby/configuration/configuring.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1930597/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1933269] Re: Project admin gets treated as Global Admin with Secure RBAC
After discussing, the Vulnerability Management Team members have
concluded that the in-progress but incomplete RBAC implementation in
various projects does not rise to the level of requiring a published
security advisory, particularly as this work is likely to take place
primarily in development branches and not be backported to supported
stable branches. Some clearer documentation on behalf of the
implementing projects is likely warranted in order to warn users of the
caveats and potential pitfalls of relying on RBAC in its current state,
but that's separate from whether or not we publish advisories about any
fixes which may merge to complete the implementation.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Tags added: security
** Information type changed from Public Security to Public
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1933269
Title:
Project admin gets treated as Global Admin with Secure RBAC
Status in Glance:
New
Status in Glance wallaby series:
New
Status in Glance xena series:
New
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
User that has been assigned admin role within their project gets
treated as de-fact admin in Glance even when project scoped "Secure
RBAC" feature is enabled.
Secure RBAC personas were introduced in Wallaby cycle creating project
scope. If user is granted admin rights within the project scope based
on the Secure RBAC roles model the user gets treated as admin in
Glance.
stack@ubnt-devstack:~/devstack$ openstack project create --enable
privilege-test
+-+--+
| Field | Value|
+-+--+
| description | |
| domain_id | default |
| enabled | True |
| id | ed7b2d168e444122b9700701834e8d97 |
| is_domain | False|
| name| privilege-test |
| options | {} |
| parent_id | default |
| tags| [] |
+-+--+
NOTE THE PROJECT ID.
stack@ubnt-devstack:~/devstack$ openstack user create --project
privilege-test --password --email priv-t...@example.com
--ignore-change-password-upon-first-use --disable-multi-factor-auth
--enable privtest
+-+-+
| Field | Value
|
+-+-+
| default_project_id | ed7b2d168e444122b9700701834e8d97
|
| domain_id | default
|
| email | priv-t...@example.com
|
| enabled | True
|
| id | eb0d6ce9c6bc42ee8962ad97849b38f7
|
| name| privtest
|
| options | {'ignore_change_password_upon_first_use': True,
'multi_factor_auth_enabled': False} |
| password_expires_at | None
|
+-+-+
stack@ubnt-devstack:~/devstack$ openstack role add --project
privilege-test --user privtest admin
stack@ubnt-devstack:~/devstack$ openstack role assignment list --names
+-+---+---++-++---+
| Role| User | Group | Project
| Domain | System | Inherited |
+-+---+---++-++---+
| admin | | admins@Default| admin@Default
| || False |
| anotherrole | alt_demo@Default | | alt_demo@Default
| || False |
| member | alt_demo@Default | | alt_demo@Default
| || False |
| anotherrole | | nonadmins@Default | alt_demo@Default
| || False |
| memb
[Yahoo-eng-team] [Bug 1784259] Re: Neutron RBAC not working for multiple extensions
After discussing, the Vulnerability Management Team members have concluded that the in-progress but incomplete RBAC implementation in various projects does not rise to the level of requiring a published security advisory, particularly as this work is likely to take place primarily in development branches and not be backported to supported stable branches. Some clearer documentation on behalf of the implementing projects is likely warranted in order to warn users of the caveats and potential pitfalls of relying on RBAC in its current state, but that's separate from whether or not we publish advisories about any fixes which may merge to complete the implementation. ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1784259 Title: Neutron RBAC not working for multiple extensions Status in neutron: Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: * Description * Using QA automation as well as manual CLI validation, it appears to me as though many Neutron extensions aren't enforcing RBAC at all. This is because the extensions lack the "enforce_policy": True key/value pair in the extension resource definition code. Example: https://review.openstack.org/#/c/584217/2/neutron/extensions/subnet_service_types.py This appears to be affecting many Neutron extensions. * Pre-conditions * 1) Enable neutron-trunk plugin in local.conf by adding: enable_service neutron-trunk 2) Set create_trunk to "rule:admin_only" in /etc/neutron/policy.json, i.e.: "create_trunk": "rule:admin_only" or even "create_trunk": "!" which should deny absolutely everyone. 3) source ~/devstack/openrc demo demo or even source ~/devstack/openrc admin admin after setting "create_trunk" with the "!" rule. * Reproduction Steps * 1) Run the following CLI commands: - openstack network create test-network - openstack port create --enable --network test-network test-port - openstack network trunk create --parent-port test-port --enable --project demo test-trunk * Expected Output * Expected result: trunk creation fails with a 403 Unauthorized. * Actual Output * Observed result: trunk creation succeeds. * Affected Plugins * As far as I can tell: - subnet service type - subnet segment_id - trunks - trunk subports Possibly many more. * Outstanding Patches * Outstanding patches that begin fixing these issues: - https://review.openstack.org/#/c/584217/ (subnet service type RBAC fix) - https://review.openstack.org/#/c/584601/ (subnet segment_id RBAC fix) Validation patches that identify some of these issues: - https://review.openstack.org/#/c/584424/ - https://review.openstack.org/#/c/582388/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1784259/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
