Kubernetes and containers promise three things:

• Faster application development and release.
• Quicker bug fixes.
• Increased feature velocity.

However, it often comes at the cost of compromised security and that is something not acceptable in any web development technology.

To realize the state of Kubernetes security, here are two factors from a survey conducted by StackRox at the end of 2020:

• 90% of the participants of the survey reported having faced a security incident related to containers and Kubernetes in the last 12 months.
• 44% of the participants had to delay their application release due to security concerns regarding Kubernetes.

What are the most common reasons behind these security concerns?

The Most Common Security Issues Related to Kubernetes

1. Misconfigurations

Surveys have revealed that exposures caused by misconfigurations are the most prevalent risk in the security of container and Kubernetes environments.

When using Kubernetes to make containerized apps, configuration management is the greatest risk for security practitioners.

This is mainly because the market is full of vulnerability scanning tools but configuration management still largely relies on human consideration.

Here’s some advice on configuring some of the common components of a containerized app to make sure that security is not compromised.

Images:

Avoid using any software that is not absolutely necessary. This includes the likes of package managers, network tools, and clients like curl, or Unix shells.

Remember, using any software adds to the security risk. Also, only use images from trustworthy sources.

Secrets:

Avoid baking secrets into the images or otherwise exposing them unnecessarily.

As a secure practice, use trustworthy secret management tools to ensure that the deployments only mount the secrets if and when they are needed.

Namespaces:

Use namespaces generously. They act as a boundary for Kubernetes and network policies. The use of namespaces can limit the effects of an attack and can contain mistakes and attacks so that they cannot spread and cause more destruction.

Runtime Privileges:

There is only one rule of privileges: allow the least number of them to make the software the most secure.

Network Policies

According to the default settings, pods can independently talk to each other in Kubernetes. However, it is a good practice to implement network policies to limit the interaction of pods. This can prevent any threat from spreading across the container and the whole app.

Persistent Storage

You need to have proper visibility into the configuration and use of persistent storage. This is because this is the only persistent vector in an otherwise ephemeral container setup.

Control-Plane

If you are managing the Kubernetes clusters by yourself, it is very important to configure the control plane. This is because some clusters can make global decisions and if a cluster is infected that can compromise the whole ecosystem.

The best approach to mitigate these and various other configuration-related security issues is using a combination of manual and automated efforts to make sure that the configuration is done in such a way as to ensure the security of Kubernetes and consequently the software they are a part of.

2. Vulnerabilities

A number of different vulnerabilities have been found and exploited in Kubernetes and other containers over the last few years.

The most common exploits of vulnerabilities include:

• Crypto mining.
• Malware installation.
• Privilege escalation.
• Host access.

The effective approach for managing vulnerability is something that needs to go on for the lifecycle of the container and should include the following:

• Identifying and resolving vulnerabilities in images, including the ones in the installed operating system.
• Detecting and mitigating any and all vulnerabilities in the runtime libraries of the programming languages you are using.
• Taking steps to prevent images having risky vulnerabilities from getting to production-accessible container registry.
• Taking measures to contain the threats having a security risk over a certain level.
• Using third-party admission controllers in Kubernetes clusters to prevent vulnerable container components from being scheduled.

3. Runtime threats

Once you have mitigated all the issues in Kubernetes security, the runtime phase has its own unique set of security threats.

Even if you have emphasized security and minimized the risks in every possible way, there can be various threats from adversaries at runtime.

Here are some things that you can do to mitigate these threats:

Runtime Activity Monitoring:

Start the monitoring process with the most container activities the most relevant to security. This includes the likes of process activity, network communications within and across containerized services, and communication to and from the external servers and clients.

Take Advantage of the Declarative Data

Make use of the build and deploy time information to evaluate the difference between the observed and expected activity to know if there is any suspicious activity.

Keep Network Communication Limited

Runtime is the time when you can see the difference between the kind of network traffic allowed and the one needed to run the system. This is the opportunity that can be used to remove any unnecessary communication that might pose a threat to Kubernetes security.

Observe the Processes Closely

Observe the application for a period of time to know all the processes that are executed for the proper functioning of the application. Make a list of all the essential processes and check the application randomly to see if any process is being executed that is not the usual one.

4. Failed compliance audit

One of the major things that ensure Kubernetes and container security is compliance. If security is not duly stressed in the Software Development Lifecycle, it can lead to a failed compliance audit.

There are numerous compliance standards that can be used for Kubernetes and container security.

PCI-DSS, HIPAA, and SOC 2 are industry-specific compliance standards.

One of the main mistakes made in this respect is not making compliance audits a part of the SDLC from the start or only considering it at runtime. To make sure everything in the software is compliant:

• Make compliance a part of the SDLC from the very start.
• Use the industry standards for making the components of the software compliant.