Module 03 · Lesson 01

Host OS Footprint

Remove what should not be running, and know how to find it first.

Hands-on
Learning objectives
  • Find what is listening and what is installed on a node.
  • Remove a service and a package, and prove they are gone.
  • Explain why hand-hardening a node is the wrong production answer.
Linux kubelet

Find it before you remove it

A Kubernetes node should run the kubelet, a container runtime, a CNI agent and very little else. Every extra listening port and installed package is attack surface on a machine that holds every credential of every pod scheduled to it.

terminal
$ss -tlnp
$ps -p <PID> -o pid,user,cmd
$systemctl list-units --type=service --state=running

Remove, then prove

terminal
$kill <PID>
$ss -tlnp | grep 8099 || echo "port 8099 is closed"
port 8099 is closed
$apt-get remove -y telnet
$dpkg -l telnet | tail -3
Killing a process is not removing a service

If something is managed by systemd, killing the process gets you a fresh one seconds later. Check whether a unit owns it and use systemctl disable --now, then confirm with ss rather than assuming.

Nobody does this by hand in production

A hand-tuned node is a snowflake: nothing records what was changed, and the next node to scale up does not have the change. The production answer is a minimal, immutable node image such as Bottlerocket, Container-Optimized OS or a hardened AMI, which never had telnet on it, and which you replace wholesale rather than patch.

You kill a process listening on an unexpected port and it reappears a minute later. What did you miss?

Why is removing telnet from a running node a poor production fix, even though it is correct here?

What makes a Kubernetes node a particularly valuable target compared with an ordinary server?

Recap

Find listeners with ss -tlnp, identify what owns them, disable rather than kill, and confirm. The real fix is an immutable minimal image rather than a hand-tuned node. Next: the kernel parameters underneath.