Containers and Kubernetes: Security is not an afterthought

The use of application containers is becoming increasingly popular due to their portability and support for modern development and architecture. Research conducted in 2020 by IBM Market Development and Information showed that 78% of respondents saw improved application quality and faster response to market segment changes and 76% saw faster time to market.

What are containers?

For those new to application containers, here’s a little rundown: Containers are made possible by the functionality of the operating system kernel – in particular, namespaces (kernel-level isolation of processes) and groups. control (used to control resources, for example, processor, memory, network, disk I / O accessed / used by a process / set of processes).

A container is a unit of software, made up of application code along with 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 called Dockerfile (or container file).

This configuration file describes the necessary base container image to use, and then additional commands to run on top of it to create the container image. The container builder tool (the most popular are Docker, Buildah, and Kaniko) creates the container image from the config file.

Container runtime engines are used to run containers. They ignore the complexity of namespaces and creating and managing end-user cgroups, and sit between running containers and the host system.

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

Kubernetes interacts with and uses the container runtime engine to create containers. Importantly, it provides the ability to define scaling requirements, replace failed containers, and schedule on a cluster of nodes, among other functions.

Hazardous areas of container technology

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

Therefore, to reap all the benefits that containers can offer (and in a safe way), security shouldn’t be an afterthought. Kubernetes provides a way to secure container orchestration, but it doesn’t just happen – we have to plan and act, otherwise shortcuts will be taken to “just make it work” and unpleasant results may be encountered.

Fortunately, there are many sources of advice on container safety, the NIST Special Publication 800-190 is one of them. It highlights five key risk areas:

  • picture,
  • registration,
  • orchestrator,
  • containers,
  • Host OS.

The training of development / engineering teams and IT architects designing systems is just as important as securing these risk areas. Our teams and colleagues need to understand that container-based systems security is out there, we need to know what to secure, why we need to secure it, and how we need to secure it.

Securing containers and orchestrating containers involves activities throughout the Software Development Lifecycle (SDLC), including:

  • plan so that the system and components are secure by design;
  • develop code with integrated security best practices;
  • ensure that constructing artifacts adequately tests the security of configurations and verifies vulnerable components;
  • ensure that deployment controls are in place to prevent compromised artifacts from reaching production;
  • Use execution monitoring to visualize and track components and configurations to assess the changing threat landscape and monitor malicious activity requiring attention.

Before we create secure containers, we need to make sure that the orchestrator and the underlying operating system that hosts it are secure. Container-optimized operating system distributions are available that are designed for this specific use case. They provide a minimal operating system image with only the tools necessary to run included containers, immutable file systems, and automated atomic upgrades.

Orchestrator security

Orchestrator security has two areas of focus:

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

The first (with a copy of a hardening guide handy) is relatively self-explanatory. The latter requires knowledge of the components of the Kubernetes architecture and the roles they play, as well as thinking about how we want to use them.

Some key areas to consider are:

  • Identity and access management, including human and programmatic accounts and the available role-based access control (RBAC) model;
  • control the security and availability of container workloads through admission, placement, and resource control policies;
  • securing the orchestrator’s internal network and exposure to external networks;
  • management of secrets;
  • cluster audit.

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


Source link

Comments are closed.