Security groups

This section addresses the use of ‘Security groups’ as one of the tools for managing and organising network security and providing access to project instances. In this section we will consider:

  • the definition of the concept of a ‘security group’;
  • managing and configuring the rules of security groups;
  • assigning the required security groups when launching instances;
  • organising network access to an instance or configuring networking between instances of the project.

About security groups

Security groups - are a set of rules for IP filtering that are applied to an instance, or more precisely, are assigned to the network interfaces of the instance. Each security group is unique and performs its functions only within the project in which it was created. The functionality of security groups enables IPv4 and IPv6 protocol network traffic to be allowed to pass or restricted.

Management functions of security groups

The following management functions of security groups are available to project users:

  • Changing the group, the management interfaces allow the addition of new rules or the removal of existing ones;
  • Security groups support the option of creating permissive rules with an ‘inheritance’ function that allows access to the IP addresses of instances to which a given security group has been assigned;
  • Creating new groups;
  • Editing user groups, i.e. changing the name and description of a security group, with the exception that the ‘default’ group does not permit editing;
  • Assigning one or several security groups to an instance;

Note

When using a combination of multiple security groups it is important to understand that the groups that will be matched together in a single instance or instance port must comply with the following norms:

  • The rules that are maintained in each security group must not conflict with one another;
  • If mutually exclusive rules are present in the groups, they cannot be used in this combination. In this case we recommend that one of the groups shall be expanded with additional rules, of which there were insufficient to enable the necessary access;
  • The rules of each group must complement each other; only in this way can the necessary level of security, reliability and stable operation of the network infrastructure be achieved.
  • Disabling all groups or specific groups for a given instance;
  • Assigning a security group to a specific port of the instance;
  • Disabling a security group from the port (network interface) of an instance.
  • Removal of security groups (all except the default);

Warning

Attempts to delete the default group will result in an error message: ‘Deletion of the default security group is forbidden’.

Configuring security groups

The rules determine which traffic is permitted to the instances to which the security group is assigned. A security group rule consists of three basic components:

Rule: the settings allow the user to set the desired rule template or to use configurable rules by means of the ‘Configurable TCP rule’, ‘Configurable UDP rule’ or ‘Configurable ICMP rule’ options.

Port/port range enabled: For TCP a UDP rules, it is possible to enable a specific port or range of ports. Choosing the ‘Port Range’ option provides a dialog in which to enter the first and last port in the range. For ICMP rules, it will be necessary to specify the ICMP type and code in the dialog that appears.

Remote side: here you must specify the source of traffic that will be permitted by this rule. You can specify a block of IP addresses (CIDR) or a security group. Selecting a security group will allow access to all machines from the group specified to all machines to which this rule is applied. The ‘inheritance’ function simplifies the process of creating permissive rules where there are a large number of project addresses for which access must be enabled. We recommend that you create separate security groups for each group of instances with the same functionality; this may be, say, a cluster of web servers, database servers, mail servers, etc, for which the security groups themselves should be given names with defined meanings, thereby enabling their purpose to be understood faster and more clearly.

By using group inheritance, it is possible to open access between an instance and a group of instances, via the necessary protocol or port, without the need to list each group host (to which this security group was assigned) or external instance (that uses this same group). It is sufficient to specify the service security group in the ‘Remote address’ field, since one and the same security group is assigned to the whole group of instances. In other words, the rule with security group inheritance will use IP addresses of project instances to which this group has been assigned.

In the following additions or removals of instances from the conditional service group of the project, the rules will be automatically inherited. Here there is no need for additional settings, which makes configuring the network infrastructure in the cloud simpler and more efficient.

Note

The number of rules in a security group is determined by the secgroup-rules quota, while the number of security groups accessible to a project is controlled by the secgroups quota. Default quotas are described in the section Limitations

Assigning security groups to an instance

All projects have a “default” security group that is applied to all instances for which no other security group is defined. For so long as it is not changed, this security group rejects all incoming traffic.

Note

To organise the security of the project, when creating each new port (network interface) of an instance, this is assigned the default security group. If multiple security groups are assigned to an instance but the necessary permissive rules are not described in the default group but are instead contained in another alternative group, the latter group must be reassigned for this instance or the required security group must be assigned to a new port.

This answers the question of why, having created an instance, many users run into the problem of lack of access to that instance, and also aids understanding of why instances are not accessible one to another within the same project without additional security group settings.

Below is a table representation of the default security group:

Direction Network type IP protoco Port range Remote IP prefix Remote security group
Incoming traffic IPv6 Any Any
default
Incoming traffic IPv4 Any Any
default
Outgoing traffic IPv6 Any Any ::/0
Outgoing traffic IPv4 Any Any 0.0.0.0/0

To enable access to an instance it is necessary to edit the already existing default security group, adding the required permissive rule for incoming traffic with defined attributes, or to create a new security group with the necessary rules for managing outgoing and incoming traffic. Bear in mind that even if two different instances have ports that are connected to the same network, network access between them will only function if the corresponding permissive rules are present on both ports.

Assigning security groups to a port

The OpenStack platform, on which the SIM-Cloud service is offered, allows security groups to be assigned to different ports of the same instance. This operation can be performed either via a cloud web interface or via other management interfaces: OpenStackClient or API. This possibility of assigning different rules to different ports enables more flexible management of outgoing and incoming network traffic while maintaining the same levels of security and ease of control of the project.

Note that the key approach to the management of security groups is to assign the necessary group specifically to the port of the instance, but you should remember that by assigning the group to the instance, you apply the rules to all ports of the virtual machine, which is not always expedient if there is a large number of network interfaces.

More detailed information on the processes of using, changing and assigning security groups can be found in this article.