> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Limiting Node Access
> Guidelines to harden Kubernetes by restricting node access through network controls, host firewalls, audited account management, least privilege, VPNs and authorized networks.
When hardening a Kubernetes cluster, minimizing direct access to the cluster nodes is a critical step in reducing your attack surface. This guide focuses on controlling access to the nodes themselves (as distinct from API-level access controls such as ABAC or RBAC).
Why restrict node access?
* Nodes run the container runtime, kubelet, and host services that, if compromised, can provide broad access to workloads and secrets.
* Limiting node access prevents lateral movement and reduces the blast radius of a compromised credential or host account.
* A layered approach (network controls + host controls + account controls) is more resilient than any single control.
Network-level controls
* Provision nodes in private networks when possible so they are not reachable from the public internet.
* Use a VPN into the private network to allow secure admin access.
* If VPNs are not possible, restrict source IPs with authorized networks (infrastructure-level firewall rules) to limit which IP ranges can reach node ports (e.g., SSH).
* Implement host-level firewalling (iptables, nftables, ufw, firewalld) to restrict traffic directly on each node.
Who should be allowed node access?
* System administrators and platform engineers who need to manage, upgrade, patch, and troubleshoot nodes.
* Avoid granting SSH or shell access to developers for production clusters unless there is an explicit, auditable reason.
Developers should generally not have SSH access to production nodes. Grant node access only on a strict need-to-know basis and follow the principle of least privilege.
Inspecting and managing Linux host accounts
Limiting who can log into nodes starts with understanding local accounts and how to audit them.
Linux account types
| Account type | Purpose | Typical characteristics |
| - | - | - |
| User accounts | Humans (admins, developers) | UID in regular user range; interactive shells |
| Superuser (root) | System-wide unrestricted privileges | UID 0 |
| System accounts | OS/service accounts for running system services | Lower UIDs; no interactive login |
| Service accounts | Created by installed software (e.g., `nginx` user) | Used by services, often restricted shell |
Audit who is accessing a host
| Command | Purpose |
| - | - |
| `id` | Show UID, GID, and supplementary groups for the current user or specified user |
| `who` | Show currently logged-in users and their terminals |
| `last -n ` | Show recent login history (replace `` with number of entries) |
Examples:
```bash theme={null}
$ id
uid=1000(michael) gid=1000(michael) groups=1000(michael),1010(admin)
$ who
michael pts/2 Apr 28 06:48 (172.16.238.187)
$ last -n 3
michael pts/2 172.16.238.187 Thu Apr 28 06:48 still logged in
```
Key system files for account management
* `/etc/passwd` — basic user info (username, UID, GID, home, shell). Does not contain password hashes.
* `/etc/shadow` — password hashes and account metadata (root-readable only).
* `/etc/group` — group definitions and member lists.
Use these files together with the audit commands to identify unused or over-privileged accounts.
Disabling and removing accounts
To enforce least privilege, disable interactive access for unused or service accounts, and delete unneeded accounts.
* Prevent interactive login by setting a no-login shell:
```bash theme={null}
# Set no-login shell for user 'michael'
sudo usermod -s /usr/sbin/nologin michael
```
* Remove an account (and its home directory and mail spool):
```bash theme={null}
# Delete user 'michael' and remove home directory and mail spool
sudo userdel -r michael
```
* Remove a user from a group (Debian/Ubuntu example):
```bash theme={null}
$ id michael
uid=1001(michael) gid=1001(michael) groups=1001(michael),1000(admin)
$ sudo deluser michael admin
Removing user `michael' from group `admin' ...
Done.
$ id michael
uid=1001(michael) gid=1001(michael) groups=1001(michael)
```
Note: If your environment uses centralized identity (LDAP, Active Directory, etc.), manage accounts and group membership through those systems rather than only on the node.
Best practices summary
* Use private networks + VPN or authorized network rules to prevent public exposure of control plane and nodes.
* Enforce host-level firewalling as an additional layer.
* Limit SSH and interactive access to a small set of administrators; follow least privilege and role-based assignment.
* Audit accounts and logins regularly; disable or remove unused accounts.
* Prefer centralized identity and just-in-time access controls where applicable.
Restrict node access at multiple layers: infrastructure firewall rules, VPN or authorized networks, and host-level account/firewall policies. Defense in depth reduces the risk of unauthorized node access.
Links and references
* [Kubernetes Architecture Overview](https://kubernetes.io/docs/concepts/overview/)
* [Kubernetes Security Best Practices](https://kubernetes.io/docs/concepts/security/overview/)
* [Using firewalls (iptables, nftables) on Linux](https://wiki.linuxfoundation.org/networking)
* [VPN concepts and best practices](https://www.cisco.com/c/en/us/solutions/enterprise-networks/remote-access-vpn/index.html)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.