Security Groups

Security groups control network traffic to and from your VMs. Each security group contains one or more rules that specify which traffic is allowed. For example, a rule might allow all TCP traffic from a specific CIDR range, or UDP traffic from VMs in another security group.

Security groups use a default-deny model: any traffic not explicitly allowed by a rule is blocked. For example, if a security group has no rule allowing ICMP traffic, VMs in that group will not respond to ping.

How security groups work

A VM can belong to multiple security groups, and each security group can contain multiple VMs. When a VM belongs to multiple security groups, traffic is allowed if it matches any rule from any of the VM's security groups (union of all rules). You can add VMs to security groups when creating them or afterward. Changes to security group membership take effect immediately without requiring a VM restart.

VMs without explicitly assigned security groups are automatically placed in the default security group for the subnet (see below), which allows all outbound traffic and inbound traffic from other VMs in the same subnet, but blocks all other inbound traffic.

To allow inbound internet traffic to a VM with a Public IP, create custom security groups with rules that permit the desired traffic. Once you assign custom security groups to a VM, the default security group no longer applies.

Security group rules

Security group rules allow you to control traffic based on:

  • Direction (ingress or egress)
  • Protocol ("TCP", "UDP", "ICMP", or "All")
  • Port or port range (e.g. 80, 443, or 1000-1100)
    • Ports and port-range are only supported if the Protocol is "TCP" or "UDP" and are explicitly disallowed if the protocol is "All" or "ICMP".
  • The traffic's origin/destination (IP address, CIDR block, security group or subnet)

Additional considerations:

  • Security groups are stateful - they automatically allow return traffic for any connection allowed by a rule
  • Traffic between VMs in the same security group is not allowed by default. Add explicit rules to allow VM-to-VM communication within a security group

Default security groups

Each resource group includes two preconfigured security groups:

default-sto-1 (VMs may join automatically)

The default-sto-1 security group has the following rules:

  • Allows all outbound traffic from VMs to the internet
  • Allows all inbound traffic from other VMs in the same subnet (within the VPC)
  • Blocks all other inbound traffic from external sources

VMs are automatically added to this security group unless you specify different security groups when creating the VM. This security group can be edited, but modifying it may affect all VMs in your resource group that rely on the default rules.

default-sto-1-ssh (VMs must join explicitly)

The default-sto-1-ssh security group provides convenient SSH access with a single rule:

rules:
  - direction: Ingress
    name: allowSSH
    port: 22
    protocol: TCP
    remote:
      address:
        IPAddressOrCIDR: 0.0.0.0/0

This security group allows SSH access from any IP address. Unlike default-sto-1, it must be explicitly added to VMs that need SSH access from the internet. You can add it when creating a VM or update an existing VM to include it.

Protocol support

The evroc compute service supports all IP-based protocols, including "IP in IP" and "SCTP". To allow these protocols, use the protocol type "All" in your security group rules.

This is particularly important for overlay networks like Calico that use IP-in-IP encapsulation. If your security group rules only allow TCP and UDP, IP-in-IP traffic will be blocked.

Example: Multi-tier application

The following example shows how to configure security groups for a multi-tier application with these components:

  • Jumphost
  • Web tier
  • Application tier
  • Database tier

SSH (i.e. TCP 22) from the outside world is only allowed to the jumphost, but from the jumphost you can SSH to all the other tiers. The web tier is reachable from the outside world on HTTP(S) (i.e. TCP 80 and 443).

Internally, the web tier can speak to the application tier on TCP 8080, and the application tier can speak to the database tier on TCP 3306.

We can visualise this set-up as follows:

Security group example

This would correspond to the following security groups:

apiVersion: networking.evroclabs.net/v1alpha1
kind: SecurityGroup
metadata:
  name: jumphostSG
spec:
  rules:
  - direction: Ingress
    name: allowSSHInbound
    port: 22
    protocol: TCP
    remote:
      address:
        IPAddressOrCIDR: 0.0.0.0/0
  - direction: Egress
    name: allowSSHOutbound
    port: 22
    protocol: TCP
    remote:
      securityGroupRef:
        name: allowSSHFromJumphostSG
---
apiVersion: networking.evroclabs.net/v1alpha1
kind: SecurityGroup
metadata:
  name: webSG
spec:
  rules:
  - direction: Ingress
    name: allowHTTPInbound
    port: 80
    protocol: TCP
    remote:
      address:
        IPAddressOrCIDR: 0.0.0.0/0
  - direction: Ingress
    name: allowHTTPSInbound
    port: 443
    protocol: TCP
    remote:
      address:
        IPAddressOrCIDR: 0.0.0.0/0
  - direction: Egress
    name: allow8080AppOutbound
    port: 8080
    protocol: TCP
    remote:
      securityGroupRef:
        name: appSG
---
apiVersion: networking.evroclabs.net/v1alpha1
kind: SecurityGroup
metadata:
  name: appSG
spec:
  rules:
  - direction: Ingress
    name: allow8080WebInbound
    port: 8080
    protocol: TCP
    remote:
      securityGroupRef:
        name: webSG
  - direction: Egress
    name: allow3306DBOutbound
    port: 3306
    protocol: TCP
    remote:
      securityGroupRef:
        name: databaseSG
---
apiVersion: networking.evroclabs.net/v1alpha1
kind: SecurityGroup
metadata:
  name: databaseSG
spec:
  rules:
  - direction: Ingress
    name: allow3306AppInbound
    port: 3306
    protocol: TCP
    remote:
      securityGroupRef:
        name: appSG
---
apiVersion: networking.evroclabs.net/v1alpha1
kind: SecurityGroup
metadata:
  name: allowSSHFromJumphostSG
spec:
  rules:
  - direction: Ingress
    name: allowSSHInbound
    port: 22
    protocol: TCP
    remote:
      securityGroupRef:
        name: jumphostSG

Then, for VMs in each tier, we would ensure they were members of the following security groups:

apiVersion: compute.evroclabs.net/v1alpha1
kind: VirtualMachine
metadata:
  name: jumphost
spec:
  networking:
    securityGroups:
      securityGroupMemberships:
        - name: jumphostSG
---
apiVersion: compute.evroclabs.net/v1alpha1
kind: VirtualMachine
metadata:
  name: web
spec:
  networking:
    securityGroups:
      securityGroupMemberships:
        - name: webSG
        - name: allowSSHFromJumphostSG
---
apiVersion: compute.evroclabs.net/v1alpha1
kind: VirtualMachine
metadata:
  name: app
spec:
  networking:
    securityGroups:
      securityGroupMemberships:
        - name: appSG
        - name: allowSSHFromJumphostSG
---
apiVersion: compute.evroclabs.net/v1alpha1
kind: VirtualMachine
metadata:
  name: database
spec:
  networking:
    securityGroups:
      securityGroupMemberships:
        - name: databaseSG
        - name: allowSSHFromJumphostSG

Next steps