Configuring security groups for Managed Service for Kubernetes Application Load Balancer tools
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:
Security group IDs are specified in the following configuration locations:
- For the
Ingress
resource, in theingress.alb.yc.io/security-groups
annotation. A load balancer associated with multipleIngress
resources aggregates all security groups defined in their configurations. - For the
Gateway
resource, in thegateway.alb.yc.io/security-groups
annotation.
Configuration 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
, and10.130.0.0/24
CIDR blocks ([B]). - The cluster’s CIDR block is
10.96.0.0/16
([C]), and the service CIDR block is10.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 CIDR203.0.113.0/24
([Con]).
To meet these conditions, you need to create the following rules in the security groups:
-
Outgoing trafficIncoming 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:
-
Cluster and node group’s security group for control plane traffic:
Outgoing trafficIncoming trafficPort 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:
-
Cluster security group for control plane traffic:
-
Node group’s security group for internet service access:
Incoming trafficPort 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 trafficPort 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.