How to Address 3 important Kubernetes Security Challenges

A growing number of deployed containers means an evolving and expanding ecosystem. There are many challenges to adopt Kubernetes technology for an organization. I will address few of those challenges & give you solutions you can consider.

follow me@ Linkdin Medium

Many organizations are turning to software containers to facilitate their digital transformations, customer requirements, AI/ML adoption, and 5G technology.

As defined by Docker, containers are units of software that package an application’s code and all of its dependencies together. Containers ensure consistency: -

· by design, they have specific versions of programming languages.

· Software libraries, and all the other resources their applications need to run regardless of the underlying host infrastructures or OS versions.

These software units also virtualize at the OS level, a property which makes them lightweight, faster to start up and less costly to maintain in terms of memory storage.

Acknowledging these benefits, organizations are deploying more and more containers. The Cloud Native Computing Foundation (CNCF) found in a 2019 survey that the percentage of organizations running 250+ containers had grown by 28% since the previous year, for instance. That was the first year when more than half of surveyed organizations told to CNCF they were running so many containers.

But what are the three most common security challenges organizations encounter when working with these types of containers? And what can your business do to mitigate them?

Let’s understand.

Container Orchestration and Kubernetes

Larger numbers of containers introduce a challenge: the operational effort that’s needed to run all of those workloads and services.

Organizations can’t perform that effort manually. Doing so would be tantamount to needlessly throwing time and money at something that could be automated at a fraction of a cost.

By driving deployment, provisioning, networking and other elements of a container’s lifecycle, container orchestration simplifies the effort that organizations must expend in managing their containers. It can also help organizations to scale their containerized workloads, also it fixes the scalability issue, container management issue, and administration of containers.

CNCF found that most (78%) of organizations are specifically going with Kubernetes to meet their container orchestration needs. An open-source, extensible platform, Kubernetes enables organizations to manage their containers using declarative configuration and automation. It does this by:

There are many other solutions to run Kubernetes on Cloud such as EKS , AKS, GKE , OpenShift and many more.

My favourites are EKS, AKS and GKE due to cloud support, stability and scalability.

Kubernetes Orchestrator adoption

The platform then takes that state and adjusts the actual state of the environment back towards the controlled state, all while restarting containers that fail and/or killing containers that don’t respond to a user-defined health check.

Real time docker container challenges

The Security Hiccup

There’s just one problem: Kubernetes security incidents are on the rise. In the Fall 2020 edition of its “State of Container and Kubernetes Security” report, StackRox found that 90% of respondents had experienced a security incident involving their container and Kubernetes environments over the course of the previous year. Those experiences and the security concerns they brought up motivated close to half (44%) of survey participants to delay moving their applications into production.

Because customer simply deploy their workload to Kubernetes without considering networking, security, certificates and password management.

Let’s frame these survey findings another way: many organizations are holding back on their business goals because of their Kubernetes-related security concerns. That’s an unsupportable way to work. Organizations need to have Kubernetes work for them so that they can continue to grow their business. They can’t allow security to set them back.

The only way sustainable forward is for organizations to proactively tackle some of the most common Kubernetes security challenges. This blog post will discuss three common security challenges for Kubernetes and provide best practices that organizations can use to address them. (These challenges are not ranked but listed in alphabetical order.)

Challenge #1: Communication

The entire Kubernetes platform boils down to pods, or groups of one or more containers. Pods are the smallest deployable units that organizations can create and manage within Kubernetes. It’s therefore fitting that organizations’ Kubernetes security efforts should begin here.

To begin, there’s the issue of pod communication. Kubernetes’ documentation notes elsewhere that all pods are non-isolated by default and accept traffic from any source. This is a problem in terms of access control. Indeed, malicious actors could abuse that fact to compromise a pod and then use its communication properties to move to all other pods in the same namespace.

Understanding the Utility of Network Policies

Organizations need to shape the ways in which pod communication flows using network policies. Through these application-centric constructs, organizations can specify with which network entities their pods are allowed to communicate. This process involves the use of three identifiers:

With the help of a selector, organizations can specify what traffic is allowed to and from a pod or a group of pods. This causes the network policy to “select” those resources and reject any connections that emanate from outside the identified namespace. In doing so, the network policy isolates them from other pods within other namespaces.

It’s also important to note that network policies don’t conflict. They are additive. Therefore, if organizations select a pod for more than one network policy, that pod is allowed to communicate according to what’s allowed by the union of those policies.

Some common examples of network policies include the following:

Challenge #2: Misconfigurations

In the previously survey, 67% of respondents said that they had experienced a misconfiguration incident within the past 12 months. Another 22% of survey participants reported a major vulnerability that they needed to remediate. They were followed by those who detected a runtime incident (17%) and those who failed an audit (16%), respectively.

“In a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes — especially given that Kubernetes configuration options are complicated and security features are not enabled by default….”

Complexity is dangerous because it gives attackers the option of using misconfigured settings to establish a foothold in organizations’ environments and to leverage that access to prey upon their sensitive data. Hence the reason why organizations need to take care to properly configure their Kubernetes in a way that coheres with their security requirements. Using network policies to restrict pod communication is a key part of that, but organizations also need to securely configure the pods themselves using pod security policies (PSPs).

How Pod Security Policies Work

According to Kubernetes’ documentation, a pod security policy is a cluster-level resource that defines the conditions under which a pod is allowed to run within a system. A PSP encapsulates what are known as “security contexts,” definitions of privilege and access control for a pod or container.

These security contexts include Linux Capabilities, or whether a pod/container receives some privileges but not those of a root user, and AllowPrivilegeEscalation, which specifies whether a pod or container can obtain more privileges than its parent process.

Organizations can best wield PSPs by creating a policy that matches what’s contained in their pods. Towards this end, they can create three types of PSPs:

Challenge #3: Runtime Threats

Finally, organizations need to be aware of runtime security threats. Tripwire explains that runtime security happens in real time. Subsequently, a compromised container can execute another process that affects other containers or systems if not the larger enterprise network.

Organizations can tackle those challenges by monitoring security-relevant container activities. In particular, they should pay attention to network traffic in order to limit unnecessary or insecure communication, as specified by their network policies. They can then use what they find to tighten the conditions of their network policies even further.

But their work doesn’t end there. Organizations can partner this monitoring and visibility with process allow lists that help to identify unexpected running container processes. Moreover, they can monitor running deployments for new vulnerabilities and scan container images for existing security weaknesses in order to minimize their attack surface.

Awareness Goes a Long Way

Kubernetes does come with its fair share of security challenges. But organizations can use proper awareness and the platform’s built-in features to face these obstacles and strengthen their security.

You can check out more security related documents security documents.