Restricting Node External Network Access
The node's listening ports are only a finding once you prove what answers on them. This guide probes two of them from another machine, finds one that authenticates and one that does not, closes the second with a single scoped rule, and puts it back.
System Hardening Guide 16 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 18 min
The demonstration adds one nftables rule in a table of its own so kube-proxy's and Cilium's chains are untouched, and deletes that table afterwards. ufw is installed and inactive on these nodes.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA7001 | 192.168.0.51 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA7001-NODE01 | 192.168.0.52 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a node's open ports have to become a finding you can act on. This matters because a listening port is only a problem once you prove what answers on it from somewhere else - and the host firewall is frequently not running at all.
- listing the listeners, and the firewall that turns out not to be running
- proving the exposure from another machine, on two separate ports
- closing it at the host with one nftables rule, in a table of its own
- putting it back, and saying what the real fix would actually be
Before you start
- guide 14 - where these ports came from.
-
The surface, and what is guarding it
-
Prove the exposure from another machine
-
Close it at the host, and measure again
-
Put it back, and say what the real fix is