Firewall Rules for K8s Clusters
The minimum firewall rules required for Kubernetes clusters, including port-level access requirements.
Kubernetes clusters provisioned through Hyperstack rely on well-defined internal and external communication paths to support secure access, orchestration, and networking across cluster nodes. This document defines the minimum required firewall rules for both full and standard deployment configurations, including the port-level access requirements for bastion, load balancer, master, and worker nodes. It also highlights when specific ports must be publicly accessible and offers guidance for managing firewall customizations safely.
Overview
Each virtual machine in a Kubernetes cluster deployed through Hyperstack can have its firewall rules customized. However, care must be taken to avoid blocking essential traffic. Certain port ranges must remain open to ensure proper functioning of Kubernetes components, reconciliation processes, and node communication.
By default, clusters are configured to allow unrestricted communication between nodes and outbound traffic to any destination. These default rules support full functionality out of the box. If you do not modify any firewall settings, no further configuration is needed.
However, if you want to restrict the default permissive traffic behavior by customizing firewall rules, you must explicitly allow all critical traffic flows to maintain functionality. The rules in this guide represent the minimum required firewall rules to support proper cluster operations when custom restrictions are introduced.
Modifying these settings without understanding the required traffic flows may result in cluster degradation, failed deployments, or unreachable workloads.
General Guidelines
- Public access is only required for the following ports:
- SSH (port 22): To the bastion node in full deployment configuration, or to
master-0in standard deployment configuration. - HTTP/HTTPS (ports 80/443): To the load balancer node in full deployment configuration only.
- NodePort services (30000–32767): Only if users explicitly expose workloads on NodePort and want them to be externally accessible. Access should be restricted to the load balancer node or trusted source IPs.
- Kubernetes API (port 6443): Only if users need external access to the API server (e.g., using
kubectlwithout VPN or tunneling). In full deployment configuration, this should be exposed via the load balancer. In standard deployment configuration, it may be exposed directly onmaster-0.
- SSH (port 22): To the bastion node in full deployment configuration, or to
- All other ports and services operate over the private network.
- Node-to-node communication: Required for intra-cluster functionality. All nodes must be able to reach each other over required internal ports. Allow established/related traffic and ICMP between nodes.
To ensure reliable cluster behavior, if you override the default firewall configuration, Hyperstack strongly recommends implementing the rules defined in the Required Firewall Rules for Clusters section. Only deviate from these rules if you have thoroughly validated that customizations will not disrupt core cluster operations.
Impacts of Misconfigured Firewall Rules
- Blocking port range 22 from the bastion (or
master-0) to other nodes will cause reconciliation and scaling operations to fail. - Blocking Kubernetes API or kubelet communication port ranges will result in node unavailability, control plane failure, or workload scheduling errors.
- Blocking ICMP, UDP port 4789 (VXLAN), IPIP (protocol 4), or related/established traffic between nodes may break Kubernetes overlay networking and pod communication.
Required Firewall Rules for Clusters
Hyperstack supports two cluster deployment configurations: Full Deployment Configuration and Standard Deployment Configuration. Each uses a different set of node types, which impacts the firewall rules required for proper operation. See deployment modes for more details.
Full Deployment Configuration
In full deployment configuration, the cluster provisions bastion, load balancer, master, and worker nodes. These nodes must be able to communicate across both internal and external networks depending on their role.
- The bastion node serves as the secure entry point and must allow external SSH access.
- The load balancer node serves HTTP/HTTPS traffic and optionally routes to the Kubernetes API.
- All other traffic, including inter-node coordination and kubelet communication, remains internal to the cluster network.
The following rules apply for each node type in a full deployment configuration:
Bastion Node
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 22 | Allows SSH access from external clients. |
Load Balancer Node
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 80, 443 | Accepts external HTTP/HTTPS ingress traffic. |
| TCP | Inbound | 6443 | Optional: Allows external access to Kubernetes API server. |
| TCP | Inbound | 22 | Allows SSH access from the bastion node. |
Master Nodes
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 22 | Allows SSH access from bastion node. |
| TCP | Inbound | 6443 | Kubernetes API server (internal access). |
| TCP | Inbound | 2379-2380 | etcd cluster communication. |
| TCP | Inbound | 10250 | Kubelet API access. |
| TCP | Inbound | 10257 | Controller manager connections. |
| TCP | Inbound | 10259 | Scheduler component connections. |
Worker Nodes
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 22 | Allows SSH access from bastion node. |
| TCP | Inbound | 10250 | Kubelet API access. |
| TCP | Inbound | 10256 | Communication with kube-proxy. |
| TCP/UDP | Inbound | 30000-32767 | NodePort services (only if publicly exposed). Restrict to load balancer or trusted source IPs. |
Standard Deployment Configuration
In standard deployment configuration, only master and worker nodes are provisioned. The node named master-0, the control plane node with bastion responsibilities, is assigned a public IP address and serves both as the Kubernetes control plane and the SSH access point.
master-0must allow both external SSH and optionally external control plane access on port 6443.- HTTP/HTTPS ingress is not supported in this mode (no load balancer node).
The following rules apply for each node type in a standard deployment configuration:
Master nodes with bastion responsibilities (name ending in master-0)
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 22 | Allows SSH access from public internet. |
| TCP | Inbound | 6443 | Optional: Allows external access to Kubernetes control plane. |
| TCP | Inbound | 2379-2380 | etcd cluster communication. |
| TCP | Inbound | 10250 | Kubelet API access. |
| TCP | Inbound | 10257 | Controller manager connections. |
| TCP | Inbound | 10259 | Scheduler component connections. |
Other Master Nodes
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 22 | SSH access from master-0. |
| TCP | Inbound | 6443 | Kubernetes control plane. |
| TCP | Inbound | 2379-2380 | etcd cluster communication. |
| TCP | Inbound | 10250 | Kubelet API access. |
| TCP | Inbound | 10257 | Controller manager connections. |
| TCP | Inbound | 10259 | Scheduler component connections. |
Worker Nodes
| Protocol | Direction | Port Range | Purpose |
|---|---|---|---|
| TCP | Inbound | 22 | SSH access from master-0. |
| TCP | Inbound | 10250 | Kubelet API access. |
| TCP | Inbound | 10256 | Communication with kube-proxy. |
| TCP/UDP | Inbound | 30000-32767 | NodePort services (only if publicly exposed). Restrict to load balancer or trusted source IPs. |
Managing Firewall Rules for Clusters
This section describes the available options for managing firewall rules within a cluster, including applying rules across all worker nodes in a node group or configuring them individually per worker node.
Manage Firewall Rules by Node Group
In Hyperstack, you can manage firewall rules for all worker nodes within a node group, applying a consistent set of rules across those nodes. Any updates are automatically applied to every node in the group.
To manage firewall rules for a node group:
- Navigate to the Kubernetes page in Hyperstack.
- Click the cluster name to open details.
- Open the Firewalls tab to view the firewall rules for each node group within the cluster.
- To edit the firewall rules for all nodes within a node group, click Manage Firewalls.
- Add or delete rules, which will be applied to all nodes in the selected node group. Click here to learn how.
Manage Firewall Rules for Individual Nodes
To manage firewall rules for individual worker nodes in the cluster:
- Navigate to the Kubernetes page in Hyperstack.
- Click the cluster name to open details.
- Go to the Nodes tab.
- Select a node and open the Firewall tab.
- Add or delete rules in the Direct Firewall Rules section. Click here to learn how.