Kubernetes is an incredible container management system. But with that power comes a great deal of responsibility on the behalf of the developers and admins. If you aren’t deploying secure containers on secure clusters, you’re fighting a losing battle from the beginning.

Fortunately, this is Linux we’re talking about, so there’s plenty you can do to help ensure the security of your deployments.

One very crucial task you can undertake is to prevent unwanted kernel modules from loading on your containers. You’d be surprised at how many modules load at boot—many of them you probably don’t need to be using within your containers.

But how do you stop them from loading? I’m going to show you.

SEE: Windows 10 security: A guide for business leaders (TechRepublic Premium)

What you’ll need

I will be demonstrating this using a container based on the latest Ubuntu Server image. I’ll be doing this by way of the Multipass tool. To learn more about how to install and use Multipass, check out my tutorial: How to use Multipass, a new tool for launching virtual machines.

If you’re not using Multipass, you can still take care of this, regardless of what container technology you are using, so long as your containers are Linux-based.

How to deploy and access the Ubuntu container

Let’s first deploy a new container with Multipass. We’ll deploy Ubuntu Daily 20.04 with the command:

multipass launch daily:20.04

Once the container has launched, you’ll be presented with the randomly-generated name for the deployment. If you miss that name, you can view it with the command:

multipass list

Now that the container has been deployed, access its shell with the command:

multipass shell NAME

Where NAME is the randomly-generated name for the container.

How to unload and blacklist modules

What we are going to do is blacklist the modules we don’t want loading in our containers. To do that, you must first know what modules are loading. To list out all of the currently loaded modules, issue the command:

lsmod

You will be presented with every module that is currently loaded into the kernel (Figure A).

Figure A

Comb through that list and find all of the modules you don’t want loading into the kernel of your container. Given containers generally have a very specific purpose, there’s probably quite a few we can blacklist.

Before we actually create a blacklist of modules we don’t want to load at boot, we have to unload them. Why? This is a container, not a virtual machine or a standard OS, so you can’t reboot. This is why we need to manually unload the modules. 

To manually unload a running module, issue the command:

sudo modprobe -r MODULENAME

Where MODULENAME is the name of the module.

If you issue the lsmod command, you should see that module is no longer loaded into the kernel.

Once you’ve compiled your list, open the blacklist file for editing with the command:

sudo nano /etc/modprobe.d/blacklist.conf

In that file, you’ll add all of the modules you want to prevent loading in the form of:

blacklist MODULENAME

Where MODULENAME is the name of the module. Say, for instance, you want to prevent the floppy kernel module from loading. To do that, the entry would be:

blacklist floppy

Note: You want to be careful to not blacklist modules that are crucial to either the running of the OS or whatever your container will depend on. So before you blacklist a module, make sure to do a bit of research into what that module does.

At this point you have manually removed all of the kernel modules you don’t want loaded and created a blacklist to prevent them from ever loading. You should be able to stop and start the container and see those blacklisted modules no longer loading.

If, however, you find the modules still loading, it means the image is still using the old copy of the initramfs that doesn’t contain your change. Rebuild the initramfs with the command:

sudo update-initramfs -u

The next time you stop and start your container, you’ll find the blacklisted modules will most certainly not load.

Not one-size-fits all

This is not a one-size-fits-all security measure for your Kubernetes containers. It is, however, something you should consider when developing your applications and services that depend on a Linux container. You do not want extraneous–and sometimes insecure–modules running on a container that could get by with the bare minimum.

Think of this process as one of many stepping stones you must cross, in order to deploy truly secure containers.

Cybersecurity Insider Newsletter

Strengthen your organization’s IT security defenses by keeping abreast of the latest cybersecurity news, solutions, and best practices. Delivered Tuesdays and Thursdays

Sign up today

Also see