OpenNebula

Alternate implementation

The issue here is two fold:

1. Q. Why would any want to remove the default SG from a network ? A. The default security group includes an ACCEPT all for in/out. This is a terminal rule so when the firewall rules are assembled and the default security group iptables rules get placed above the other rules for the NIC the other rules are not applied.

2. Fundamentally the functionality should still work -- anti-spoofing doesn't indicate that it will be related to security group, it's surprising when it does not work

But that is the intended behaviour. When we added the SG feature, we didn't want the users to go through the trouble of defining outbound and inbound rules for their VMs to get to work, that's why the default security group has two rules, one that allows all outbound traffic and another one that allows all inbound traffic.

In the documentation [1] we mention (right at the top) that:

By default, the default security group is applied to new VMs, which allows all OUTBOUND traffic but blocks any INBOUND traffic. Modify the default security group to allow all INBOUND connections or to define any rules you might want.

Meaning, if a user doesn't care about SG, everything will work, but if he wants SGs to make any sense, he must change the rules of the default SG to be more restrictive, as the default rules permit everything

Does this make sense?

[1] http://docs.opennebula.org/4.14/administration/networking/security_groups.html

I just realised that text is wrong, no wonder it doesn't make sense. The default rules are:

TYPE PROTOCOL ICMP_TYPE NETWORK RANGE
OUTBOUND ALL Any
INBOUND ALL Any

Meaning, everything is allowed. I just added a banner to the documentation fixing that text and making it more visual and obvious.

Does it make more sense now? If you want to use Security Groups, you need to change the default rules.

The issue is that there can really be no good rules there for the default security group.

Since ACCEPT/DROP rules are terminal and are placed before rules in other security groups in some cases placing ANY rules in the default security group can lead to unexpected results for users. There are two options here:
1. Create no rules in the default security group (i.e., empty set)
2. Do not apply the Default security group to anything the users cannot remove it from (VNETs)

The problem with #1 is that there is a default DROP for in/out added at the end of the iptables chain if there are any security groups. So if a user doesn't select any security group and only the default security group is used then all traffic is dropped.

Users can't change the rules in the Default security group, only the administrator can -- user's only option is to not use it.

Since the user also may not be able to manage the VNET, and there can be no good rules for it (except empty), I don't apply the Default security group to any VNETs. The end result being that if the user doesn't apply any security groups to a NIC they almost always end up with no security groups. This breaks anti-spoofing.

The alternate implementation above is really short and just adds the security ID 0 to any NICs with an empty set of security groups -- this is the implementation I'm using now. If the user ends up not selecting any security groups at all they get SGID 0, if they do select any security groups (either at the VNET or NIC level) then those security groups are used and the SGID 0 is not added.

OK, I think I understand what you are saying:

- A user in your cloud cannot manage the networks.
- A user should be able to have everything working without adding SGs.
- If a user wants to add a SG they can.

It makes sense, but I think that asking them to always create SGs is not unreasonable, I think it's actually a good practice.

The alternate implementation above is really short and just adds the security ID 0 to any NICs with an empty set of security groups -- this is the implementation I'm using now. If the user ends up not selecting any security groups at all they get SGID 0, if they do select any security groups (either at the VNET or NIC level) then those security groups are used and the SGID 0 is not added.

A minor problem with the patch is that if the Virtual Machine does not reference any SGs explicitely when you create it (which is the scenario we're discussing), it will not include the SECURITY_GROUP_RULEs [1] into the VM XML, and the driver will not apply any rules, therefore no networking will work (unless I'm mistaken)

Even if that worked, that would be confusing if the admin has changed the Default SG, since it would apply some filtering, completely unknown to the user and you would not be able to figure out what's going on even with onevm show -x.

In order to fix both things I hardcoded the Default SG rules into the driver, and it does work.

Let me discuss all of this with the team. I guess it's down to deciding whether it's reasonable to ask the user to create a SG always for Clouds implementing your workflow/use-case. Being flexible is great but giving many alternatives to accomplish the same things confuses the users.

[1] https://gist.github.com/jmelis/f053f938097864bd06d680f01eb46234#file-onevm-xml-L113