Containers and Kubernetes: security is not an afterthought

The use of application containers is becoming increasingly popular due to their portability and support of modern development and architecture. Research conducted in 2020 by IBM Market Development & Insights showed 78% of those surveyed experienced improved application quality and faster response to changes in market segment and 76% experienced faster time to market.

What are containers?

For those new to application containers, here is a little background: containers are made possible due to operating system kernel features - specifically, namespaces (kernel level isolation of processes) and cgroups (used to control resource e.g., CPU, memory, network, disk I/O accessed / used by a process / set of processes).

A container is software unit, consisting of application code plus its required binaries and libraries. A container is created from a container image (which is a read-only template of the content just described). A container image is created from a configuration file known as a Dockerfile (or containerfile).

This configuration file describes the necessary base container image to use and then additional commands to run on top to make the container image. The container building tool (popular ones are Docker, Buildah and Kaniko) creates the container image from the configuration file.

Container runtime engines are used to run containers. They abstract the complexities of namespaces and cgroup creation and management from the end user and sit between the running containers and the host system.

Kubernetes, a container orchestration tool, comes into the mix because the next step in the journey is container orchestration - a system that can automate container deployment, scaling, and the management of containerised applications.

Kubernetes interacts with and utilises the container runtime engine to create containers. Crucially, it provides the ability to set scaling requirements, replace failed containers and schedule across a cluster of nodes amongst other functions.

Container technology risk areas

This technology is, however, not without risk. It is important to note that containers are lightweight and portable, due to the absence of requiring a full guest OS; instead, they share the OS of the underlying host. They do not have the isolation of the traditional virtual machine, which is provided by its hypervisor.

Therefore, to take advantage of all the benefits containers can offer (and in a safe manner) security must not be an afterthought. Kubernetes provides a means for securing container orchestration, but it doesn’t just happen: we must plan and act, otherwise shortcuts will be taken to ‘just make it work’ and unpalatable outcomes may be encountered.

Fortunately, there are numerous sources of container security guidance available, NIST Special Publication 800-190 is one of them. It highlights five key risk areas:

• image,
• registry,
• orchestrator,
• containers,
• host OS.

Educating development / engineering teams and IT architects designing systems is just as important as securing these risk areas. Our teams and colleagues must appreciate security for container-based systems is available, we must know what to secure, why we must secure it and how we must secure it.

Securing containers and container orchestration involves activities across the software development lifecycle (SDLC), including:

• planning so that the system and components are secure by design;
• developing code with best security practices built in;
• ensuring that the building of artefacts adequately tests the security of configurations and checks for vulnerable components;
• ensuring deployment controls are in place to prohibit compromised artefacts from reaching production;
• using runtime monitoring to visualise and track components and configurations to assess against a changing threat landscape and monitor for malicious activity requiring attention.

Prior to creating secure containers, we must ensure the orchestrator and the underlying OS hosting it are secure. Container-optimised OS distributions are available and they are designed for this specific use case. They provide a minimal OS image with only the tools required to run containers included, immutable filesystems and automated, atomic upgrades.

Orchestrator security

The security of the orchestrator has two areas of focus:

1. It needs to be installed securely (following hardening guides such as CIS Kubernetes Benchmark).
2. Security configurations, features and functionality need to be implemented.

The former (with a copy of a hardening guide on hand) is relatively self-explanatory. The latter requires knowledge of components of the Kubernetes architecture and the roles they play, along with consideration as to how we wish to utilise them.

Some key areas for consideration are:

• identity and access management, including human and programmatic accounts and the roles based access control (RBAC) model available;
• controlling the security and availability of container workloads through admission control, placement and resourcing policies;
• securing the orchestrator internal network and exposure to outside networks;
• secrets management;
• cluster auditing.

Kubernetes provides mechanisms for user authentication (via an external identity provider) and authorisation (via RBAC). Permissions assigned to users and groups must follow the rule of least privilege and several default roles are available.