Security groups are not added correctly on amphorae

[Sherif Abdelwahab]

When adding a new member, the amphora cannot talk it. The security group of the tenant network is not added to the amphorae instances, and need to be added manually.

Example: https://gist.github.com/abdelwas/d61b6fdeca6b35c2689f

[Brandon Logan (brandon-logan)]

If I am understanding this correctly, I don't think this is a bug. If the member needs to accept traffic from a protocol on a specific port, then I don't think that should be Octavia's job. If a user wants that traffic on that port using that protocol accepted, then that user should add a security group rule to their member's neutron port (or server). We're not always guaranteed that the IP and subnet combination they provide is even associated to a nova server or even a neutron port (publicly accessible IPs).

 Let me know if I'm misunderstanding the bug.

[Sherif Abdelwahab (selgohari)]

I agree that diverse security approaches will create a burden on Octavia to add security groups to the amphorae.

So in the example shown, the loadbalancer security groups needed to be:
(default, lb-5cfd45c7-e12b-4dd7-8be3-f2c31ac110a5, lb-mgmt-sec-grp), instead of only
(lb-5cfd45c7-e12b-4dd7-8be3-f2c31ac110a5, lb-mgmt-sec-grp), for traffic to pass from the amphorae to the server.

This shouldn't be required, to my understanding, as the lb-5cf** group already allows HTTP traffic (listener port), and the amphorae have traffic interfaces on the same tenant subnet of the server.

But in some situations, traffic does not pass from the amphorae to the servers, and I added the default security group manually (bad thing I know) to the loadbalancer to work.

[Brandon Logan (brandon-logan)]

hmm, I'm sure its too late but is there anyway you know what the security group rules were for each of those security groups? The reason I ask is because the lb-5c... should have security group rules only for TCP and all the listener's protocol ports for ingress. All egress connections should be allowed, so the amphora sending traffic to the members should not be blocked by any of the security groups on the amphora, unless the lb-5c.... was misconfigured, which would be a bug.

The default security group does not have any security group rules in place on a clean stack, so the node1 server would not allow any ingress traffic unless that protocol/port was setup. Were those security group rules in place and this still happened?

[Sherif Abdelwahab (selgohari)]

It is kinda late, but I will try to reproduce the problem and update the bug. I will confirm with more tests.

[Brandon Logan (brandon-logan)]

I may have reproduced what you are talking about. It only happened when the vip and member are on different subnets. What the problem is the default security group was not added to the vip port, so egress connections were in fact not allowed. I was assuming the default was being added but it was not. I'll put a bug fix in for this soon.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/218754
Committed: https://git.openstack.org/cgit/openstack/octavia/commit/?id=acc8883c549ef2f8eb449cf38fcd1561e65c8074
Submitter: Jenkins
Branch: master

commit acc8883c549ef2f8eb449cf38fcd1561e65c8074
Author: Brandon Logan <email address hidden>
Date: Mon Aug 31 02:53:56 2015 -0500

    Do not remove egress sec group rules on plug vip

    When a vip is plugged or a listener is added, all security group rules that
    did not have the current configuration of ports were deleted. This included
    the egress rules that by default allow all protocols and ports. Now, egress
    rules are ignored and maintained so connection to amphorae can be preserved.

    Change-Id: I9ff2772f9c3e12a5099b7b57cd64f74da5aa35ae
    Closes-Bug: #1488281