Security groups

A security group is the main mechanism for access control in Yandex Cloud.

A security group (SG) is a resource created at the cloud network level. Once created, a security group can be used in Yandex Cloud services to control network access to an object it applies to.

A default security group (DSG) is created automatically while creating a new cloud network. The default security group has the following properties:

• It will allow any network traffic, both egress and ingress, in the new cloud network.
• It applies to traffic passing through all subnets in the network where the DSG is created.
• It is only used if no security group is explicitly assigned to the object yet.
• You cannot delete the DSG: it is deleted automatically when deleting the network.

You can combine security groups by assigning up to five groups per object.

Scope of use for security groupsScope of use for security groups

Security groups can be used in the following Yandex Cloud service objects:

Security group structureSecurity group structure

Security groups consist of a list of rules. A security group with no rules blocks any network traffic between objects it applies to. This happens because the list of security group rules always implicitly ends with the "prohibit all" rule.

Security group rules for ingress and egress traffic are set separately. One group may have up to 50 rules in total for ingress and egress traffic.

A new rule is always added at the end of the list. You cannot add a new rule to a specific position in the list in-between existing rules.

Description of security group rulesDescription of security group rules

Each rule in a security group has a fixed set of fields:

Self ruleSelf rule

A special security group named Self can act as a traffic source or target in a security group rule. It includes all IP addresses of objects this group will be applied to.

For example, you can create a vm_group_sg security group and describe it in Terraform as follows:

resource yandex_vpc_security_group vm_group_sg {
  ...  
  ingress {
      protocol          = "ANY"
      description       = "Allow incoming traffic from members of the same security group"
      from_port         = 0
      to_port           = 65535
      predefined_target = "self_security_group"
  }

  egress {
      protocol          = "ANY"
      description       = "Allow outgoing traffic to members of the same security group"
      from_port         = 0
      to_port           = 65535
      predefined_target = "self_security_group"
    }
}

Now, if you apply the vm_group_sg group to the network interfaces of two VMs connected to the same network, these VMs will be able to exchange traffic with no port restrictions. If you apply the same group to a third VM on the same network, all three of them will be able to exchange traffic.

Rule with a link to a security groupRule with a link to a security group

Security group rules allow you to use other security groups in the Source or Destination field.

Such rules will allow networking with the IP addresses of resources (VM interfaces) to which this security group already applies.

So you can refer to different types of objects in rules, such as:

• Managed Service for Kubernetes cluster worker nodes
• Managed DB cluster hosts
• VM instances in instance groups

Using reference rules in security groups helps maintain the consistency of network access rules during autoscaling of cloud resources.

Here is an example of a service that consists of two components:

• Instance group with web servers behind a load balancer
• Managed Service for PostgreSQL cluster

It is necessary to enable access from the DB cluster to a group of web servers the number of which may vary depending on the load.

To do this, create two security groups:

• web-sg: For the group of web servers
• db-sg: For the Managed Service for PostgreSQL cluster

resource "yandex_vpc_security_group" "web_sg" {
  name                = "web-sg"
  ...
  ingress {
    description       = "Allow HTTPS"
    protocol          = "TCP"
    port              = 443
  }

  ingress {
    description       = "Allow HTTP"
    protocol          = "TCP"
    port              = 80
  }

  egress {
    description       = "Permit ANY"
    protocol          = "ANY"
    v4_cidr_blocks    = ["0.0.0.0/0"]
  }
  ...
}

resource "yandex_vpc_security_group" "db_sg" {
  name                = "db-sg"
  ...
  ingress {
    description       = "Permit DB access to Web VM's"
    protocol          = "TCP"
    port              = 6432
    security_group_id = [ yandex_vpc_security_group.web_sg.id ]
  }
}

When new servers are added to the group, security group rules will automatically apply to them.

Security group specificsSecurity group specifics

Traffic directionTraffic direction

Security group rules describe ingress and egress traffic separately.

Stateful connectionsStateful connections

The state of network connections in security groups is tracked. If security group rules allow network traffic in one direction, it is not required to allow the reverse traffic.

Connection lifetimeConnection lifetime

Security groups automatically terminate idle TCP connections in 180 seconds. We do not recommend using session timeouts in applications for a longer period of time. See more about limits here.

Using security groups in rulesUsing security groups in rules

Rules may use existing security groups as traffic sources and targets.

Using multiple security groupsUsing multiple security groups

If multiple security groups apply to one object at the same time, their rules will be combined into a single list. Network traffic will be allowed if it matches a rule in at least one of the groups. If not, traffic will be prohibited.

Security groups and Network Load BalancerSecurity groups and Network Load Balancer

Please keep in mind that you cannot apply security groups to a network load balancer's traffic listener. For target group VMs hosted behind a load balancer, security groups can be applied to the VM network interfaces. Security groups of these VMs must include the Health Checks rule to allow health check traffic from the load balancer.

Security groups and services for DNS and VM metadataSecurity groups and services for DNS and VM metadata

For consistent and reliable operation of network services, you must explicitly allow the following network traffic in the outgoing rules of security groups:

• Requests to the VM metadata service at the 169.254.169.254 IP address over HTTP (tcp/80).
• Requests to the DNS service towards the second IP address in the subnet over DNS (udp/53).

Security groups and Managed Service for KubernetesSecurity groups and Managed Service for Kubernetes

To avoid network connectivity issues when deploying and using Managed Service for Kubernetes clusters, carefully follow this guide.

Security groups and Application Load Balancer tools for Managed Service for KubernetesSecurity groups and Application Load Balancer tools for Managed Service for Kubernetes

For proper operation of the ingress controller or Gateway API, configure security groups for the Managed Service for Kubernetes cluster and node groups, and for the Application Load Balancer L7 load balancer. For more information, see this guide.

Sample descriptions of security group rulesSample descriptions of security group rules

VM with a web serverVM with a web server

resource yandex_vpc_security_group vm_group_sg {
...
  ingress {
    description    = "Allow HTTP protocol from local subnets"
    protocol       = "TCP"
    port           = 80
    v4_cidr_blocks = ["192.168.10.0/24", "192.168.20.0/24"]
  }

  ingress {
    description    = "Allow HTTPS protocol from local subnets"
    protocol       = "TCP"
    port           = 443
    v4_cidr_blocks = ["192.168.10.0/24", "192.168.20.0/24"]
  }

  egress {
    description    = "Permit ANY"
    protocol       = "ANY"
    v4_cidr_blocks = ["0.0.0.0/0"]
  }
}

VM behind a network load balancerVM behind a network load balancer

resource yandex_vpc_security_group vm_group_sg {
...
  ingress {
    description    = "Allow HTTP protocol from local subnets"
    protocol       = "TCP"
    port           = "80"
    v4_cidr_blocks = ["192.168.10.0/24", "192.168.20.0/24"]
  }

  ingress {
    description    = "Allow HTTPS protocol from local subnets"
    protocol       = "TCP"
    port           = "443"
    v4_cidr_blocks = ["192.168.10.0/24", "192.168.20.0/24"]
  }

  ingress {
    description = "Health checks from NLB"
    protocol = "TCP"
    predefined_target = "loadbalancer_healthchecks" # [198.18.235.0/24, 198.18.248.0/24]
  }

  egress {
    description    = "Permit ANY"
    protocol       = "ANY"
    v4_cidr_blocks = ["0.0.0.0/0"]
  }
}

Tools for managing security groupsTools for managing security groups

In Yandex Cloud, you can work with security groups using:

• Management console
• Command line interface (CLI)
• Terraform:
  • Security Group
  • Security Group Rule
  • Default Security Group

Step-by-step guides for working with security groupsStep-by-step guides for working with security groups

Sample use cases for security groups in Yandex Cloud

Use casesUse cases

• Architecture and protection of a basic web service
• Connecting to a cloud network using OpenVPN
• Setting up a UserGate proxy server
• Creating a bastion host
• Configuring a network for Yandex Data Processing
• Implementing a secure high-availability network infrastructure with a dedicated DMZ based on the Check Point NGFW

ClickHouse® is a registered trademark of ClickHouse, Inc.