Yandex Cloud
Search
Contact UsGet started
  • Blog
  • Pricing
  • Documentation
  • All Services
  • System Status
    • Featured
    • Infrastructure & Network
    • Data Platform
    • Containers
    • Developer tools
    • Serverless
    • Security
    • Monitoring & Resources
    • ML & AI
    • Business tools
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Customer Stories
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Education and Science
    • Yandex Cloud Partner program
  • Blog
  • Pricing
  • Documentation
© 2025 Direct Cursus Technology L.L.C.
Yandex Application Load Balancer
  • Getting started
    • Overview
    • Configuring security groups
    • Working with service accounts
    • Creating and updating resources via Ingress controller configurations
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • L7 load balancer logs
  • Release notes
  1. Tools for Managed Service for Kubernetes
  2. Configuring security groups

Configuring security groups for Managed Service for Kubernetes Application Load Balancer tools

Written by
Yandex Cloud
Updated at May 19, 2025

To ensure proper operation of the ingress controller and Gateway API, you must configure appropriate security groups for your cluster, Yandex Managed Service for Kubernetes node groups, and load balancer.

We recommend using separate security groups for your cluster, node groups, and load balancer, although a shared group is also permitted.

Within each security group, you must configure:

  • All required security group rules documented in the relevant guides:
    • For cluster and node groups, see the Configuring security groups section of the Managed Service for Kubernetes documentation.
    • For the load balancer, see Security groups. The final outbound rule for backend VMs must allow connections to either the CIDR range of your cluster’s node group subnet or the security group associated with your node groups.
  • Backend health check rules, allowing:
    • The load balancer to send TCP traffic to port 10501 on cluster nodes, targeting either the node groups’ subnet CIDR ranges or their security groups.
    • Node groups to receive this traffic (traffic originates in the load balancer subnets or security group).

Security groups for both the cluster and node groups are specified in their respective configurations. For more information, see the guides below:

  • Creating and updating a cluster.
  • Creating and updating a node group.

Security group IDs are specified in the following configuration locations:

  • For the Ingress resource, in the ingress.alb.yc.io/security-groups annotation. A load balancer associated with multiple Ingress resources aggregates all security groups defined in their configurations.
  • For the Gateway resource, in the gateway.alb.yc.io/security-groups annotation.

Configuration exampleConfiguration example

Consider an example for the following conditions:

  • You need to deploy a load balancer with a public IP address to accept HTTPS traffic in three subnets with 10.128.0.0/24, 10.129.0.0/24, and 10.130.0.0/24 CIDR blocks ([B]).
  • The cluster’s CIDR block is 10.96.0.0/16 ([C]), and the service CIDR block is 10.112.0.0/16 ([S]).
  • The cluster's node group resides in a subnet with the CIDR block 10.140.0.0/24 ([Nod]).
  • SSH access to nodes and cluster management (via API, kubectl, etc.) are restricted to CIDR 203.0.113.0/24 ([Con]).

To meet these conditions, you need to create the following rules in the security groups:

  • Load balancer security group:

    Outgoing traffic
    Incoming traffic
    Port range Protocol Destination name CIDR blocks Description
    0-65535 TCP CIDR 10.140.0.0/24[Nod] For outgoing traffic to nodes, including status checks
    Port range Protocol Source CIDR blocks Description
    80 TCP CIDR 0.0.0.0/0 For receiving incoming HTTP traffic
    443 TCP CIDR 0.0.0.0/0 For receiving incoming HTTPS traffic
    30080 TCP Load balancer healthchecks — For load balancer node status checks
  • Node group’s security group for backend health checks:

    Incoming traffic
    Port range Protocol Source CIDR blocks Description
    10501 TCP CIDR 10.128.0.0/24[B]
    10.129.0.0/24[B]
    10.130.0.0/24[B]
    For backend health checks
  • Cluster and node group’s security group for control plane traffic:

    Outgoing traffic
    Incoming traffic
    Port range Protocol Destination name CIDR blocks Description
    0-65535 Any (Any) Security group Current (Self) For traffic between the control plane components and worker nodes
    Port range Protocol Source CIDR blocks Description
    0-65535 TCP Load balancer healthchecks — For a network load balancer
    0-65535 Any (Any) Security group Current (Self) For traffic between the control plane components and worker nodes
    0-65535 ICMPv6 CIDR 10.0.0.0/8
    192.168.0.0/16
    172.16.0.0/12
    For node health checks within Yandex Cloud subnets
  • Node group’s security group for control plane traffic:

    Outgoing traffic
    Incoming traffic
    Port range Protocol Destination name CIDR blocks Description
    0-65535 Any (Any) CIDR 0.0.0.0/0 For external resource access
    Port range Protocol Source CIDR blocks Description
    0-65535 Any (Any) CIDR 10.96.0.0/16[C]
    10.112.0.0/16[S]
    For pod to service communication
  • Cluster security group for control plane traffic:

    Outgoing traffic
    Incoming traffic
    Port range Protocol Destination name CIDR blocks Description
    4443 TCP CIDR 10.96.0.0/16[C] For traffic between the control plane components and metric-server pods
    Port range Protocol Destination name CIDR blocks Description
    443 TCP CIDR 203.0.113.0/24[Con] For Kubernetes API access
    6443 TCP CIDR 203.0.113.0/24[Con] For Kubernetes API access
  • Node group’s security group for internet service access:

    Incoming traffic
    Port range Protocol Source CIDR blocks Description
    30000-32767 TCP CIDR 0.0.0.0/0 For internet and Yandex Cloud access
  • Security group for SSH access to node group instances:

    Incoming traffic
    Port range Protocol Source CIDR blocks Description
    22 TCP CIDR 203.0.113.0/24[Con] For SSH access to nodes

For details on cluster and node group’s security groups, see the Configuring security groups section of the Managed Service for Kubernetes guides.

Was the article helpful?

Previous
Gateway API service
Next
Working with service accounts
© 2025 Direct Cursus Technology L.L.C.