Introduction to Security Groups
A security group (SG) is an easy to create, manage, simplistic virtual firewall that controls the traffic for one or more virtual resources, including virtual machines (VMs), virtual load balancers (LBs) and Network Connectors.
Each SG consists of a number of SG rules that allow traffic to or from the virtual resources assigned to that SG.
SGs actually perform packet filtering on the ports connected to the virtual resources network card (NIC), unlike the Firewall service that sets packet filters on the virtual router. This means that security groups need to be managed and applied for each individual NIC within the virtual resource. When deploying a VM with multiple NICs via the portal, all NICs will be assigned the same Security Groups you specified on the “Access and Security” tab of the wizard.
SGs use a white-list policy where packets from white-listed addresses and ports are accepted, but everything else is denied. In other words, if the communication does not appear on the whitelist, then it is rejected.
All rules can be deleted from a SG, effectively not allowing ANY access.
The scope of each SG is limited to a project, and spans an Availability Zone (AZ), meaning that virtual resources from either K5 AZ can be added to a SG.
On K5 you can have up to 20 SGs per project, with a total of 100 rules across all SGs, although these limits can be increased by raising a service request with Fujitsu.
Like other K5 objects, each SG is uniquely identified via an ID number, rather than its name. For this reason, it is possible to create multiple SGs with the same name, with each having different rules. Therefore care needs to be taken in multi administrator environments, to ensure the intended SG is assigned, as someone else may have created a group with the same name, but different rules.
The “Default” Security Group
Each new project is created with a default Security Group called “default” with a description of “default”. This cannot be deleted, and neither the name nor description can be amended either.
The default SG contains the following default rules:
- Allow all inbound traffic from other members of the default security group (the security group specifies itself as a source security group in its inbound rules)
- Allow all unrestricted outbound traffic from each member.
These rules can be added to or deleted as appropriate.
Although the default rules show IPv6, only IPv4 is currently supported by K5
When creating a new VM, the default SG is ticked by default, but this can be unticked as long as another SG is selected, as membership of at least on SG is mandatory.
The K5 VM creation process for both Windows Server and Linux VMs, requires that the VM has outbound access to 169.254.169.254 on port TCP 80 (HTTP). If the default Security Group or default rules that allow unrestricted outbound traffic are deleted or not applied to a VM, then a new alternative rule must be created to allow this traffic during its creation. Otherwise, it will not be possible to authenticate with and log into the VM post creation. The rule can later be removed once you have successfully logged into the VM once.
Custom Security Groups
When you create a security group, you must provide it with a name and a description. The name and description of the SG can be amended post creation. Each new SG is created with a default rule to allow all outgoing traffic. Although the default rules show IPv6, only IPv4 is currently supported by K5
A SG cannot be deleted whilst it still assigned to virtual resources, so the assignment either needs to be amended first or the actual virtual resources deleted, prior to the deletion of the SG.
When you associate multiple SG with a virtual resource, the rules from each SG are effectively aggregated to create one set of rules. (I’ve not yet hit a limit on the number of SG that can be added to a virtual resource)
Security Group Rules
Security group rules are always permissive; i.e. you can’t create rules that deny access.
Security groups are stateful — i.e. if you send a request from your VM, then the response to that traffic is allowed to flow in regardless of the defined inbound security group rules
You can add and remove rules at any time, with changes automatically applied to all members of the SG.
Each rule has either an IP Address/CIDR or another Security Group (from within the project) as its source (receive from) or destination (send to) location
Specifying a SG in a rule is the same as saying “all virtual resources” within this group. A rule can also contain the name of the SG it belongs to, meaning the rule is applied to all virtual resources within the owning SG. E.g. to allow each VM within the SG to send or receive to one another. (Note: this allows the internal IP Address of the VMs, not any public IP Address assigned to a VM)
Use CIDR address 0.0.0.0/0 to represent everyone, e.g. for inbound HTML requests to a website
For a specific IP address, enter /32, e.g. for inbound RDP or SSH
If there is more than one rule for a specific port, then the most permissive rule is applied. For example, if you have a rule that allows access to TCP port 3389 (RDP) from IP address 22.214.171.124 and another rule that allows access to TCP port 3389 from everyone, everyone has access to TCP port 22.