[Yandex Cloud documentation](../../index.md) > [Yandex Virtual Private Cloud](../index.md) > [Concepts](index.md) > Security groups # Security groups A security group is the main mechanism for access control in Yandex Cloud. {% note info %} Currently, you can only use IPv4 in Yandex Cloud networks. IPv6 is not supported, so security groups can only work with IPv4 traffic. {% endnote %} A *security group* (SG) is a resource created at the [cloud network](network.md#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. {% note alert %} Security groups are not designed to protect against DDoS attacks. To filter out large volumes of unsolicited network traffic, use [Yandex DDoS Protection](../ddos-protection/index.md). {% endnote %} ## Default security group {#default-security-group} The *default security group* (DSG) is created automatically when you create a [new cloud network](network.md#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 from objects within the same security group ([self](#self-rule) rule). * All incoming network traffic over `ICMP`. * Incoming network traffic over `TCP` and `UDP` on port `22` (`SSH`). * Incoming network traffic over `TCP` and `UDP` on port `3389` (`RDP`). All other traffic in the security group is denied by default. You cannot manually delete a default security group. It is deleted automatically when you delete the respective network. ## Scope of use for security groups {#security-groups-apply} Security groups can be used in the following Yandex Cloud service objects: | Service name | Service objects | |-----------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| | [Compute Cloud](../../compute/index.md) | [VM interface](../../compute/concepts/network.md), [instance group template](../../compute/concepts/instance-groups/instance-template.md#network) | | [Managed Service for Kubernetes](../../managed-kubernetes/index.md) | [Cluster](../../managed-kubernetes/concepts/index.md#kubernetes-cluster), [node group](../../managed-kubernetes/concepts/index.md#node-group) | | [Application Load Balancer](../../application-load-balancer/index.md) | [Load balancer](../../application-load-balancer/concepts/application-load-balancer.md#security-groups) | | [Managed Service for PostgreSQL](../../managed-postgresql/index.md) | [Cluster](../../managed-postgresql/concepts/network.md#security-groups) | | [Managed Service for ClickHouse®](../../managed-clickhouse/index.md) | [Cluster](../../managed-clickhouse/concepts/network.md#security-groups) | | [Yandex MPP Analytics for PostgreSQL](../../managed-greenplum/index.md) | [Cluster](../../managed-greenplum/concepts/network.md#security-groups) | | [Managed Service for MySQL®](../../managed-mysql/index.md) | [Cluster](../../managed-mysql/concepts/network.md#security-groups) | | [Yandex Managed Service for Valkey™](../../managed-valkey/index.md) | [Cluster](../../managed-valkey/concepts/network.md#security-groups) | | [Yandex StoreDoc](../../storedoc/index.md) | [Cluster](../../storedoc/concepts/network.md#security-groups) | | [Managed Service for Apache Kafka®](../../managed-kafka/index.md) | [Cluster](../../managed-kafka/concepts/network.md#security-groups) | | [Managed Service for OpenSearch](../../managed-opensearch/index.md) | [Cluster](../../managed-opensearch/concepts/network.md#security-groups) | | [Managed Service for Trino](../../managed-trino/index.md) | [Cluster](../../managed-trino/concepts/network.md#security-groups) | | [Yandex Data Processing](../../data-proc/index.md) | [Cluster](../../data-proc/concepts/network.md#security-groups) | | [Data Transfer](../../data-transfer/index.md) | [Endpoint](../../data-transfer/concepts/network.md#security-groups) | | [Managed Service for GitLab](../../managed-gitlab/index.md) | [Instance](../../managed-gitlab/operations/configure-security-group.md) | {% note info %} For more information about using security groups in a specific Yandex Cloud service, see the relevant documentation. {% endnote %} ## Security group structure {#security-groups-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](limits.md#vpc-limits) 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 rules {#security-groups-rules} Each rule in a security group has a fixed set of fields: | Argument | Description | | --- | --- | | **Description** | Brief description of the rule. You can also describe metadata in this field. | **Protocol** | Specifies the [network protocol](https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1) to be used for this rule.
You can use the following protocols for security group rules: | **Port range** | Range of ports for the network protocol selected in the rule.
You can only specify a continuous port range. You cannot list arbitrary comma-separated ports. | **Source**
For incoming traffic only | Traffic source IP addresses.
You can use the following methods to specify traffic source IP adresses: | **Target**
For outgoing traffic only | Traffic target IP addresses.
You can use the following methods to specify traffic target IP addresses: ### Self rule {#self-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: ```hcl 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. {% note alert %} Note that the `Self` rule only affects traffic going directly through the VM network interface that the security group is applied to. In the case of a VM with a public IP address, the `Self` rule does not apply to egress traffic to the internet that goes through this network interface in the [one-to-one NAT](address.md#public-addresses) direction. {% endnote %} ### Rule with a link to a security group {#reference-rule} 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](../../compute/concepts/instance-groups/index.md) with web servers behind a load balancer * [Managed Service for PostgreSQL](../../managed-postgresql/index.md) 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 ```hcl 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 specifics {#security-groups-notes} #### Traffic direction {#traffic-destination} Security group rules describe ingress and egress traffic separately. #### Stateful connections {#stateful} 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 lifetime {#ttl} 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](limits.md#vpc-limits). #### Using security groups in rules {#security-groups-in-rules} Rules may use existing security groups as traffic sources and targets. #### Using multiple security groups {#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 Balancer {#security-groups-and-network-load-balancer} Please keep in mind that you cannot apply security groups to a network load balancer's [traffic listener](../../network-load-balancer/concepts/listener.md). For [target group](../../network-load-balancer/concepts/target-resources.md) 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](../../network-load-balancer/concepts/health-check.md#target-statuses) traffic from the load balancer. #### Security groups and services for DNS and VM metadata {#security-groups-and-metadata-dns} 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](../../compute/concepts/vm-metadata.md) 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](network.md#subnet) over DNS `(udp/53)`. #### Security groups and Managed Service for Kubernetes {#security-groups-and-k8s} To avoid network connectivity issues when deploying and using Managed Service for Kubernetes clusters, carefully follow [this guide](../../managed-kubernetes/operations/connect/security-groups.md). #### Security groups and Application Load Balancer tools for Managed Service for Kubernetes {#security-groups-and-alb-for-k8s} For proper operation of the [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) or [Gateway API](https://github.com/kubernetes-sigs/gateway-api), configure security groups for the Managed Service for Kubernetes [cluster](../../managed-kubernetes/concepts/index.md#kubernetes-cluster) and [node groups](../../managed-kubernetes/concepts/index.md#node-group), and for the Application Load Balancer [L7 load balancer](../../application-load-balancer/concepts/application-load-balancer.md). For more information, see [this guide](../../application-load-balancer/tools/k8s-ingress-controller/security-groups.md). {% note alert %} Yandex Cloud supports automatic [filtering of egress SMTP traffic](limits.md#vpc-egress-traffic-filter). {% endnote %} ## Sample descriptions of security group rules {#security-groups-examples} ### VM with a web server {#security-group-vm-web} ```hcl 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 balancer {#security-group-vm-nlb} ```hcl 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 groups {#security-groups-tools} In Yandex Cloud, you can work with security groups using: * [Management console](https://console.yandex.cloud/folders/{folder-id}/vpc/security-groups/) * [Command line interface (CLI)](../../cli/cli-ref/vpc/cli-ref/security-group/index.md) * Terraform: * [Security Group](../../terraform/resources/vpc_security_group.md) * [Security Group Rule](../../terraform/resources/vpc_security_group_rule.md) * [Default Security Group](../../terraform/resources/vpc_default_security_group.md) ## Step-by-step guides for working with security groups {#security-group-howto} [Sample use cases for security groups](../operations/index.md#security-groups) in Yandex Cloud ## Use cases {#examples} * [Architecture and protection of a basic web service](../tutorials/web-service.md) * [Connecting to a cloud network using OpenVPN](../tutorials/openvpn.md) * [Setting up a UserGate proxy server](../tutorials/usergate-proxy.md) * [Creating a bastion host](../tutorials/bastion.md) * [Configuring a network for Yandex Data Processing](../tutorials/data-processing-nat-instance.md) * [Implementing a secure high-availability network infrastructure with a dedicated DMZ based on the Check Point NGFW](../tutorials/high-accessible-dmz.md) _ClickHouse® is a registered trademark of [ClickHouse, Inc](https://clickhouse.com)._