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.

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

Default security groupDefault security group

The default security group (DSG) is created automatically when you create a new cloud network, and its rules apply to network traffic of objects that have no explicitly assigned custom security group.

The default security group allows:

• All outgoing (egress) network traffic.
• All incoming (ingress) network traffic.

You cannot manually delete a default security group. It is deleted automatically when you delete the respective network.

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. If security groups are applied to both the sender and the recipient, make sure to configure the sender’s group to allow egress traffic and the recipient’s group to allow ingress traffic for a new connection. An ingress connection can originate from your cloud network, another network, or the internet.

No separate rules are required for response traffic on an already allowed connection since security groups track connection state. For example, when a VM connects to an HTTPS server on the internet, you do not need to configure an ingress rule on the VM for the server’s response traffic.

If traffic goes through a jump host VM, such as a NAT instance, make sure its security group also allows the traffic. An egress rule on the sender does not replace an ingress rule on the NAT instance. For specific rule pairs, see our examples.

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.

Let’s consider a service which has 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 your ingress controller or Gateway API to operate correctly, configure security groups for the Managed Service for Kubernetes cluster and node groups, and for the L7 Application Load Balancer. For more information, see this guide.

Sample descriptions of security group rulesSample descriptions of security group rules

VM-to-VM connection and response trafficVM-to-VM connection and response traffic

The client VM located at 192.168.10.10 connects to the server VM located at 192.168.20.10 over SSH. Both VMs are in the same cloud network. The client-sg and server-sg security groups are applied to their network interfaces, respectively. To establish a new connection, configure the following two rules:

If the client sends a request from port 52000, the server responds from port 22 to the client’s port 52000. This response traffic is allowed automatically due to connection state tracking, so you do not need to add egress rules to server-sg or ingress rules to client-sg for the response. A server-initiated connection, however, requires its own allowing rules.

Managed Service for Kubernetes node access to the internet through a NAT instanceManaged Service for Kubernetes node access to the internet through a NAT instance

A Managed Service for Kubernetes node without a public IP address pulls an image from Container Registry at cr.yandex over HTTPS. The node is in the 192.168.10.0/24 subnet and uses the kubernetes-sg security group. The subnet is configured to route traffic for 0.0.0.0/0 through a NAT instance with the 192.168.20.10 private IP address, public IP address, and nat-sg security group.

This example assumes that the NAT instance is configured to forward traffic and that DNS queries and cluster service traffic are already allowed. For the HTTPS connection described here, you need to configure the following rules:

The first rule allows the packet to leave the node, the second one allows it to reach the NAT instance’s network interface, and the third one allows it to leave the NAT instance and reach the server. The NAT instance’s ingress rule checks the forwarded packet’s destination port: you do not need to run an HTTPS server on the NAT instance. Response traffic for this connection is allowed automatically.

The packet retains the IP address of cr.yandex as its destination, and the NAT instance’s address is used as the next hop. Therefore, you cannot replace the destination CIDR with the NAT instance’s IP address or security group in the node’s egress rule. In our example, 0.0.0.0/0 allows HTTPS traffic to any IPv4 address. Optionally, you can narrow the range to the IP addresses of the external resources you need to access.

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

The client VM at 192.168.10.10 connects to an internal Network Load Balancer at 192.168.30.10 on TCP port 443. The listener forwards traffic to port 8443 on the target VM at 192.168.20.10. The health check uses a separate TCP port, 8080, on the same VM. The client, load balancer, and target VM are all in the same cloud network.

Apply the client-sg group to the client’s network interface and the target-sg group to the target VM’s network interface. The Network Load Balancer listener does not have any security groups.

The first two rules allow client connections. Since the load balancer preserves the client’s IP address, the target VM’s ingress rule specifies the client’s IP address and destination port 8443. The third rule, which uses loadbalancer_healthchecks as the predefined source, allows health check nodes to connect directly to port 8080. If these checks are blocked, the resource will not enter the HEALTHY status, and the load balancer will not route client traffic to it.

Response traffic from the target VM to the client and health check nodes is allowed automatically. Therefore, you do not need to configure separate egress rules for this traffic in the target-sg security group.

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.