Request #5226

Security Group implementation is partial / incomplete :(

Added by Florian Heigl almost 4 years ago. Updated almost 4 years ago.

Status:PendingStart date:07/11/2017
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Pull request:

Description

Hi,

I hadn't noticed this until recent, but it seems there's a some work left when comparing ONEs security groups with the ones on AWS.
It needs to be possible to name other security groups in a security group (as "from" or "to")
That's what makes it work smoothly and I feel that part is really missing in ONE.

History

#1 Updated by Ruben S. Montero almost 4 years ago

  • Tracker changed from Bug to Request

Hi Florian

I do not really get this "from - to" does not make sense to use a security group (i.e. a rule) it needs to be a origin/source destination in layer 3 (a security group is something like filter out connections to port TCP 22).

In fact in OpenNebula security group definition is really flexible, you can use IP networks (CIDR notation 10.0.0.0/24 for example) or even an OpenNebula network (that would generate multiple filter rules based on the address ranges of the network) for "to-from".

So I'd say OpenNebula security group definition is at least as flexible as that in AWS.

I'll move this to request, if there is something we do not get from your description.

Cheers

#2 Updated by Taavi K almost 4 years ago

Hi,

I'd like to propose idea that we could define also rules with NOT to network/destination.

So one could define security group with rules:

Allow outbound traffic to 192.168.20.0/24
Allow outbound traffic NOT to 192.168.0.0/16
Allow outbound traffic NOT to 172.16.0.0/12
Allow outbound traffic NOT to 10.0.0.0/8
Allow outbound traffic to ANY

So vm can access only 192.168.20.0/24 LAN and not any other private network range. Also any public network.

#3 Updated by Strahinja Kustudic almost 4 years ago

I asked via support about the same feature and the outcome was this issue being created https://dev.opennebula.org/issues/5317, so I guess one of these two is a duplicate.

Security groups are not as nearly as flexible as they are on AWS. Let me explain how SGs work on AWS. SGs in EC2 are something between firewall rules and networks. Here are the features they support besides allowing networks as src/dest and other static rules:
  • All the VMs in the same SG can communicate between each other (except if a special rule is created to disable that).
    • This means that a SG acts sort of like a special network which allows all machines in a SG to communicate with each other.
    • It also makes managing rules in a SG much easier, because VMs in a SG can talk to each other, so no additional rules for that.
  • You can put a different SG as a src/dest in a SG rules
    • This is the real magic because it allows you for example to create two SGs: sg-app-worker and sg-app-mysql; then in sg-app-mysql you can just add one rule which would allow SRC: sg-app-worker to connect on TCP port 3306, which would allow all the VMs in the sg-app-worker to connect to the MySQL database.
    • What is great about this is that you don't need to care in what networks VMs are, nor what IPs they have, nor how many app-worker VMs will you have in the future, just add them to the correct SG and it will always work, which is extremely flexible.
    • To be able to do something like this in OpenNebula currently you need to:
      • Create a virtual network app-worker-network (which can be a reservation of IPs).
      • This means that you need to plan how big this network should be for future growth (this isn't a problem for local IPs, because you have a lot of them and can make the network very big, but it is problematic with limited public IPs). The thing is why should I care how many host will be there in the future and what IPs do my VMs have, if I don't have to.
      • Create a SG sg-app-mysql which allows all hosts in network app-worker-network to connect to 3306
      • Add rules if the VMs in the same security group need to talk to each other (the same for app-worker).

Also available in: Atom PDF