3 Ways to Minimize Your Host OS Footprint: From the System Hardening Domain

As you continue your CKS certification journey, you will inevitably come across the system hardening domain. The “system” in this case is the worker nodes on your cluster — more specifically access to them and the safe management of the hosted operating systems. While that makes sense from a 1,000 feet perspective, things get vaguer once you are in the weeds.

For instance, the Certified Kubernetes Security Specialist (CKS) syllabus discusses the necessity to minimize the host OS Foot Print. At a higher level (say, a 500-foot level) it means reducing the cluster’s attack surface, thereby mitigating the chance a hacker will attempt access. In this article, we will discuss three ways to minimize your host OS footprint. 

Need Kubernetes Training?

If you haven’t used Kubernetes before or are new to the platform, CBT Nuggets has got you covered. You’ll find a variety of Kubernetes training to help you get up to speed, whether you are an administrator or developer. Check out our Kubernetes training — and then sign up for a 7-day free trial to start learning how to leverage the power of Kubernetes!

1. Limit Node Access To Users

Least-privileged access has been, and always will be, a bedrock principle of IT security. This is true with Kubernetes nodes as well. It is important that only authorized users can access containers created by a pod. 

In order to limit access for users, we need to determine the user list location. Traditionally, this is located in the passwd file on a Linux box. Let’s discuss how to get there.

First, log onto the existing container using kubectl. This can be done with the command kubectl exec —it <pod-name> — sh.

Once you have shelled into the box, navigate to the etc folder. Next, view the passwd file. This can be done by typing cat passwd, or using a text editor, like VIM. The passwd file is formatted to show one user per line. The first user in the list will probably be looking something like this:

root:x:0:0:root:/root:/bin/bash

It is colon-delimited. The first value is the username. The second value is an encrypted password. The actual password is usually kept in etc/shadow. The third value is the UserID, and the fourth is the GroupID. The fifth value is a comments section. It allows you to add metadata about the user: his or her address, phone number, et cetera. The sixth value is the directory the user will be in when they log in. The seventh and last value is the shell the user logs in with.

As a CKS candidate, this is pertinent information you should be familiar with. Now, in order to remove access to a user, scan this list and delete the user from the passwd list. This can be accomplished with the userdel command.

2. Do Not Run Containers as Root

When creating a pod in Kubernetes, the developer has the option to run a container with privileges. The YAML to do so looks like this:

apiVersion: v1

kind: Pod

metadata:

  name: privileged

spec:

  containers:

    - name: pause

      image: k8s.gcr.io/pause

      securityContext:

        privileged: true <——This is bad!

A privileged container is given access to devices on a host. Creating the container with privileged access opens up a wide range of possible attacks. Running a container in privileged mode is only useful if the container needs to use some device or access the network stack. If neither of these fits your case, don’t do it! There is a good chance the CKS exam may involve editing a container to no longer possess privileged mode.

3. Remove Bloatware from your Pods.

The containers inside of pods are built from base images. Often times the base images will have applications installed on them that your container isn’t going to need. For example, base images commonly contain a widely-used caching proxy server called Squid. 

Squid can easily be used by a malicious actor to gain information about the cluster and its node. This application may be a good candidate for removal entirely if you know for a fact it won’t be used on the particular worker node. Removing a program in a Linux environment would look like this:

systemctl stop squid

systemctl disable squid

# uninstall

apt remove squid

Final Thoughts

In this article, we covered three different ways to minimize your host OS footprint. The first one is to prune the passwd file. Only provide access to users who actually need access. Second, we discussed the importance of privileged access. A pod should never be created with privileged access unless there is a very specific need to do so. Lastly, we talked about the importance of removing unnecessary software. Software that is not needed can become deprecated and become a security vulnerability. Worse yet, an attacker could use it in a malicious manner.

Bear in mind that this is just a small sample of strategies to reduce the OS Security footprint, but each one of these practices will prepare you for the CKS certification exam and/or harden the security at your organization.