Description of problem: What problem/issue/behavior are you having trouble with? What do you expect to see? +++ I am a Red Hat Consultant on site with customer. +++ Due to the nature of this customer I can't send any logs I have deployed RHEL OSP10 for customer using Director. I have enabled lbaasv2 on their overcloud in line with our documentation ( https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/networking_guide/sec-lbaas ) As per the upstream documentation on using lbaasv2, you assign a security-group to the lbaas vip_port in neutron to control access to the loadbalancer (https://docs.openstack.org/newton/networking-guide/config-lbaas.html). What we are seeing is that the security group rules aren't being adhered to and so users can access ports which aren't included in the security group. The same security group applied to an instance exhibits the behaviour I expect i.e. only the listed ports are available. I am able to re-produce this on a fully patched OSP10 packstack install on my laptop as well. Is there some config I am missing? Is this a known issue with lbaasv2 and security groups? Version-Release number of selected component (if applicable): RPM versions: openstack-neutron-common-9.4.1-1.el7ost.noarch openstack-neutron-lbaas-9.2.1-4.el7ost.noarch openstack-neutron-lbaas-ui-1.0.0-1.el7ost.noarch openstack-neutron-ml2-9.4.1-1.el7ost.noarch openstack-neutron-9.4.1-1.el7ost.noarch openstack-neutron-openvswitch-9.4.1-1.el7ost.noarch openstack-neutron-metering-agent-9.4.1-1.el7ost.noarch How reproducible: 100% Steps to Reproduce: To re-produce the problem: 1) Create a security group with no ingress rules: openstack security group create lbaas-sg 2) Create loadbalancer neutron lbaas-loadbalancer-create --name test-lb internal-subnet 3) Associate floatingip to loadbalancer neutron floatingip-associate <floatingip_id> <port_id> 4) Update port security group neutron port-update --security-group lbaas-sg <lbaas_vip_port_id> 5) Create listener neutron lbaas-listener-create --name test-lb-listener --loadbalancer test-lb --protocol HTTP --protocol-port 80 At this point I can now ping the floating ip and connect to port 80 on it despite these not being in the security group. Actual results: can ping lbass port even when attached security group does not have rules for icmp allow Expected results: lbass port should be unpingalble Additional info: # neutron lbaas-loadbalancer-show test-lb +---------------------+------------------------------------------------+ | Field | Value | +---------------------+------------------------------------------------+ | admin_state_up | True | | description | | | id | 077ba5a5-0863-4833-a2db-970d293b28d3 | | listeners | {"id": "0a7c474e-967c-416b-bb70-2aef7ccac40d"} | | name | test-lb | | operating_status | OFFLINE | | pools | | | provider | haproxy | | provisioning_status | ACTIVE | | tenant_id | 983fd92bee4247038c9a4fab8c773f48 | | vip_address | 10.0.0.15 | | vip_port_id | 80d844a2-c5e7-42ef-8f9e-28f0767387cd | | vip_subnet_id | d854393e-467a-4742-93c3-34d657964d54 | +---------------------+------------------------------------------------+ # neutron port-show 80d844a2-c5e7-42ef-8f9e-28f0767387cd +-----------------------+----------------------------------------------------------------------------------+ | Field | Value | +-----------------------+----------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | packstack.example.com | | binding:profile | {} | | binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} | | binding:vif_type | ovs | | binding:vnic_type | normal | | created_at | 2017-10-09T14:05:34Z | | description | | | device_id | 077ba5a5-0863-4833-a2db-970d293b28d3 | | device_owner | neutron:LOADBALANCERV2 | | extra_dhcp_opts | | | fixed_ips | {"subnet_id": "d854393e-467a-4742-93c3-34d657964d54", "ip_address": "10.0.0.15"} | | id | 80d844a2-c5e7-42ef-8f9e-28f0767387cd | | mac_address | fa:16:3e:24:83:bb | | name | loadbalancer-077ba5a5-0863-4833-a2db-970d293b28d3 | | network_id | ff6dc7e5-9e55-4bd2-96c3-6837585c2634 | | project_id | 983fd92bee4247038c9a4fab8c773f48 | | revision_number | 15 | | security_groups | 666c1d5b-6150-4d95-8901-7a46a5334c61 | | status | ACTIVE | | tenant_id | 983fd92bee4247038c9a4fab8c773f48 | | updated_at | 2017-10-09T19:21:22Z | +-----------------------+----------------------------------------------------------------------------------+ # openstack security group show 666c1d5b-6150-4d95-8901-7a46a5334c61 +-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ | created_at | 2017-10-09T12:58:47Z | | description | lbaas-sg | | id | 666c1d5b-6150-4d95-8901-7a46a5334c61 | | name | lbaas-sg | | project_id | 983fd92bee4247038c9a4fab8c773f48 | | project_id | 983fd92bee4247038c9a4fab8c773f48 | | revision_number | 1 | | rules | created_at='2017-10-09T12:58:47Z', direction='egress', ethertype='IPv6', id='02053085-b885-4865-914f-78889758c968', | | | project_id='983fd92bee4247038c9a4fab8c773f48', revision_number='1', updated_at='2017-10-09T12:58:47Z' | | | created_at='2017-10-09T12:58:47Z', direction='egress', ethertype='IPv4', id='8f6e5ac1-e531-4d59-b1f4-7e2172036003', | | | project_id='983fd92bee4247038c9a4fab8c773f48', revision_number='1', updated_at='2017-10-09T12:58:47Z' | | updated_at | 2017-10-09T12:58:47Z | +-----------------+----------------------------------------------------------------------------------------------------------------------- # neutron security-group-rule-list +--------------------------------------+----------------+-----------+-----------+---------------+------------------+ | id | security_group | direction | ethertype | port/protocol | remote | +--------------------------------------+----------------+-----------+-----------+---------------+------------------+ | 02053085-b885-4865-914f-78889758c968 | lbaas-sg | egress | IPv6 | any | any | | 03927271-44d4-4bdf-b5bf-81fe0636ce51 | default | egress | IPv4 | any | any | | 1a1dad36-14ed-48f0-80f5-42a51b369f1f | default | ingress | IPv4 | 22/tcp | 0.0.0.0/0 (CIDR) | | 2d569a48-915c-4947-9ce7-d3d39a341eb1 | ssh | egress | IPv4 | any | any | | 5cb78243-c280-4d9a-9678-28036c1f2295 | default | ingress | IPv6 | any | default (group) | | 67ef015c-05ee-47d5-93d5-ed7daf46cd23 | default | ingress | IPv4 | any | default (group) | | 77c0c8f2-bcad-488d-acba-86e7214dd7fc | ssh | ingress | IPv4 | 22/tcp | 0.0.0.0/0 (CIDR) | | 7f00d01c-e861-4035-88ed-65ed08b500ac | default | egress | IPv6 | any | any | | 8f6e5ac1-e531-4d59-b1f4-7e2172036003 | lbaas-sg | egress | IPv4 | any | any | | ba80d9db-0220-48d3-8c74-450468804678 | ssh | egress | IPv6 | any | any | | cff7198e-6eb6-4fd8-a0b6-919654ce0ab2 | default | egress | IPv4 | any | any | | d5d6622e-a8c1-4295-938d-2b01bbe2c8b4 | default | egress | IPv6 | any | any | +--------------------------------------+----------------+-----------+-----------+---------------+------------------+
Assigned to Nir for triage.
Hi Jeremy, In short: Unfortunately, the document you attached is just wrong and needs fixing. I double checked that with the LBaaS upstream PTL. This is not supported (even in Queens, which would be OSP13) by the haproxy in namespace lbaas implementation, and actually, this is not how security groups are intended to work. The longer version: Security groups, which is a concept originated in Nova, were designed to restrict ingress/egress traffic for Nova instances. That has implications about how security groups were actually implemented and the thing to keep in mind here is that Nova instances connect to the main OVS bridge (br-int) through an intermediate Linux bridge (more details about this here[1]. that is where security group rules are being applied. That being said, the LBaaS VIP port (among other types of Neutron ports) is wired directly to the main OVS bridge (br-int) directly. Thus, no security group enforcement. That is actually a base assumption taken into account in the haproxy namespace driver implementation. Note the attached security group won't get updated when you add an LBaaS listener. If security groups were to be enforced, it *had* to add rules to it in order to have a functioning loadbalancer. IIRC, there were talks in the community to have some sort of ACLs mechanism in Octavia, but that's not relevant for OSP10 nor it got any actual work done in that field just yet. Let me know if you have any further questions. [1] https://www.rdoproject.org/networking/networking-in-too-much-detail/
As we are moving towards using Octavia as load balancing service, I'm closing this bug as WONTFIX. Octavia loadbalancers are implemented as regular instances and hence can have security groups implemented just like ordinary instances.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days