How to Secure Kubernetes Cluster: Vulnerabilities & Fixes

The Kubernetes cluster has many dynamic components and resources that can be exploited if vulnerabilities are unsolved. Misconfigurations, privileged containers, and Denial of Service (DoS) attacks can lay out multiple entry points for cyber attackers. A Kubernetes cluster security breach is costly and causes a lot of damage to cloud infrastructure. When cyberattackers penetrate the cluster through privileged containers they can compromise nodes which in turn terminates Pods. When Pods are not running, containerized applications experience downtime.

In this tutorial, you will learn various Kubernetes vulnerabilities and how to eliminate them. In addition, you will learn the importance of securing Kubernetes resources.

#Prerequisites

You need a functional Kubernetes cluster and kubectl is installed on your Linux machine.

#5 common Kubernetes cluster vulnerabilities

Container images can carry insecurities that spread through the cluster when the image is executed. On the other hand, privileged containers compromise the cluster when the host system gets breached. These two insecurities are high-level vulnerability status. In this section, you will learn various Kubernetes cluster insecurities that have to be eliminated before they cause destruction to cluster components.

#1. Container image vulnerabilities

Container images are mostly overlooked when it comes to how many vulnerabilities they can possess if compromised. Not every image on Docker Hub is secure. Container images get vulnerabilities when the Dockerfile used to build them has insecure configuration and outdated components. Insecure container images contain vulnerabilities such as insecure dependencies, embedded secrets, and malicious code. It is important to scan container images before use and download verified images only.

Container image vulnerabilities are dangerous because they disseminate malicious code into the cluster when exploited. This malicious code compromises the cluster causing data breaches and service disruptions. Efficient tools such as Kubescape and Trivy-operator should be used to detect container image vulnerabilities before they get exploited. Later on, this article will teach you how to use Kubescape to scan cluster vulnerabilities.

#2. Giving containers escalated privileged access to the host system

Privileged containers are necessary when executing host system-level tasks such as accessing the host system’s hardware. However, in general, the idea of giving containers privileged access to the host system is bad. When you give a container privileged access to the host system, you are exposing it to the host system's vulnerabilities. When the host system is attacked the privileged container will also be affected.

#3. Hardcoding credentials

Kubernetes secrets are just like physical car keys. You cannot leave your car keys anywhere or give them to everyone. Because if you do, your car will be stolen. Kubernetes secrets should be treated the same way people protect their car keys. Kubernetes keys comprise of; API keys, tokens, and passwords.

These passwords will be retrieved by malicious users if they are hardcoded and carelessly stored. Once stolen, these secrets are used to captivate the cluster and demand ransomware if the cluster owner wants to get the cluster functionality back.

#4. Unrestricted network access

A Kubernetes cluster that does not have network policies is a recipe for disaster. Network policies enable you to block network traffic being sent by cyberattackers. Basically, your cluster is open to any attack if no network filters are implemented. The network facilitates the transfer of data from one source to the destination. Therefore, cyberattackers will be able to send malicious data through the unsecured cluster network and corrupt select resources.

#5. Unpatched Kubernetes versions

Most of the time, developers only think about updating Kubernetes when they encounter endless errors and issues. This is a bad habit, Kubernetes has to be updated whenever there is a new version upgrade. Every software update has security patches or performance updates. So, if you are using an outdated Kubernetes version, you are using a version that has well-known insecurities and performance issues.

What is more of a concern in this situation, is that cyberattackers know what insecurities are unpatched in old software versions. They will be able to do more damage to the cluster and have easy access to the cluster through the insecurity such as unpatched container runtime vulnerabilities.

#How to secure a Kubernetes cluster

Securing a Kubernetes cluster starts with scanning Kubernetes resources to detect vulnerabilities and then eliminating the detected vulnerabilities. After securing the cluster, resources have to be monitored to fix any issue that might cause vulnerabilities later on.

#1. Scanning Kubernetes resources using Kubescape

Kubernetes has an endless number of free open-source tools that scan the cluster or a specific Kubernetes resource. One of those free cluster scanning tools is Kubescape developed by Armosec. Kubescape is a tool that detects cluster and resource vulnerabilities, generating a security report that details the severity of the detected vulnerabilities.

Use the following command to install Kubescape on Linux:

curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

After successfully installing Kubescape, use the following command to scan the entire Kubernetes cluster.

kubescape scan

Next, Kubescape will generate a comprehensive list of all the resources scanned and the detected vulnerability. Below is an image showing a snippet of the components scanned by Kubescape.

In the above image, Kubescape has reported that there are resources that have missing network policies. To get an exact Pod with missing network policies, we have to execute the following command which is stated in the view details column on the previous table.

kubescape scan control C-0260 -v

Kubescape will then output the name of the Pod with missing network Policies. The image below shows that a Pod called “first-pod” lacks network policies which are crucial for filtering malicious network traffic.

#2. Securing Kubernetes clusters

We will use the following concepts to implement Kubernetes security measures:

#RBAC

When it comes to granular resource access, Kubernetes offers Resource Based Access Control (RBAC). RBAC enables you to select specific service accounts that can access and edit certain Kubernetes resources. In Kubernetes, service accounts are used to give Pods and other resources an identity. RBAC consists of roles and role bindings. Roles define permissions that a specific service account can have when using a resource. These permissions are defined using verbs. A verb is an action that a service account can perform on a resource. A service account can be given resource permissions:

• get
• list
• watch
• create
• update
• patch
• delete

Below are examples of resources that can be controlled by RBAC:

• pods
• deployments
• ingress
• jobs
• nodes
• service accounts
• services

When creating a role you have to specify the verb you want to give to a service account. Followed by the resources that will be accessed. Use the following command to create a role using an imperative method.

kubectl create role [enter role name] --verb=[enter permissions] --resource=[resources being accessed]

Below is an example that creates a role called service-access-role.

kubectl create role service-access-role --verb=get,list --resource=services

Use the following command to check if the role was created successfully.

kubectl describe role service-access-role

You will get the following output:

To complete the RBAC mechanism, a role has to be accompanied by a rolebinding. A rolebinding attaches the permissions defined in the role to a subject which is a service account. Use the following command to create a role binding that will.

kubectl create rolebinding [enter rolebinding name] --role=[enter role name] --serviceaccount=[enter namespace]:[enter service account name]

For example:

kubectl create rolebinding service-rolebinding --role=service-access-role --serviceaccount=default:my-service-account

#Combatting misconfigurations

A Kubernetes cluster consists of endless YAML files that contain cluster configuration. The Kubernetes cluster needs the necessary specifications to run securely. When a Kubernetes YAML file has missing values or incorrect specifications it is called misconfiguration. For example, a Pod configuration has to specify resource limits, if not, one container will over consume resources starving other containers. When containers are starved of resources applications crash.

Nowadays, detecting and fixing misconfiguration is effortless because there is ValiKube, a security auditing and misconfiguration cleaning tool. ValidKube is a free online platform that allows you to insert Kubernetes YAML configurations and scan them to detect misconfigurations. You don't have to install any binaries on your host machine to run ValidKube. Just head over to ValiKube and start scanning misconfigurations.

The image below shows Validkube scanning a Pod that has misconfigurations. On the left pane of the ValidKube website, that's where the YAML configuration is inserted. On the right pane is where the results of the misconfiguration scan will be displayed. ValidKube was able to scan the Pod and detect that the YAML configuration has missing resource requests and limits as shown in the image below.

#Securing Kubernetes API keys using secret objects

In Kubernetes, Secret objects enable you to store API keys and passwords safely without having to hardcode their values. Once credentials have been stored in Secret objects they can be shared and used safely. To ensure that Secrets are fully secure they have to be encrypted. Below is an example of a Secret object:

apiVersion: v1
kind: Secret
metadata:
  name: dev-api-secret
type: Opaque
data:
  username: dXNlcm6hbWU=
  password: cGFzc3dvcmQ=

#Securing the cluster’s network traffic using network policies

Network security is the core of any software system. The network controls how data goes in and out. A secure network is one that filters out malicious traffic and data. Kubernetes offers a NetworkPolicy resource that allows you to define unwanted traffic and filter any malicious network requests. The network policy concept is a broad topic in Kubernetes that has its own prerequisites.

This section will briefly explain how you can secure the Kubernetes cluster using network policies. NetworkPolicies boost Kubernetes cluster by using ipBlock and allowing rules. ipBlock is a powerful tool that allows rules that let you specify external IP ranges for finer-grained control over network traffic.

Allow rules enable you to specify the sources or destinations for allowed traffic using from (Ingress) / to (Egress) values. For example, the configuration below shows an allow rule that only permits outgoing and incoming network traffic with the label app: testpod.

 ingress:
    - from:
      - podSelector:
          matchLabels:
            app: testpod
  egress:
    - to:
      - podSelector:
          matchLabels:
            app: testpod

NetworkPolicies also allow you to filter internal network traffic based on namespaces using a namespaceSelector. You can choose a specific namespace as the network traffic source or destination. Below is a code snippet from a NetworkPolicy that shows an ingress that only allows traffic from the 'frontend' namespace.

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend 

#The benefits of securing a Kubernetes cluster

In this section, you will learn why it is important to secure a Kubernetes cluster. We will discuss the following benefits:

#1. Complying with international security standards

International security standards such as the General Data Protection Regulation (GDPR) require software companies to follow and implement security measures such as data privacy, RBAC, and network security. Securing your Kubernetes cluster makes your company eligible to acquire a GDPR compliance certificate badge. Security compliance certificates hold the same value as customer testimonials when displayed on your website. They instill a sense of trust in customers.

#2. Reduced attack surface

Proactive security is the best defense. Every software company should anticipate security breaches. They are imminent and inevitable. Securing your Kubernetes clusters gives you the benefit of minimizing cyber breach impact.

Kubernetes security emphasizes: isolation, fewer privileges, and network filtering. These three security concepts minimize the attack surface by preventing malicious network traffic from infiltrating Kubernetes components and causing serious damage.

#3. Prevention of data breaches and minimized downtime

Data breaches cause heavy damage to the company's finances. The costs are high when taking into account all the lawsuits, infrastructure renovation, and other remedies needed to get the systems and company back in full operation.

A secure cluster ensures that resources are used optimally and the right people are given access to resources. A secure Kubernetes cluster saves costs as you will not be involved in paying ransomware, regulatory fines, and costs incurred due to prolonged downtime.

Also, a secure Kubernetes cluster ensures that Pods are running and executing containerized applications. This prevents any application downtime from occurring.

#Conclusion

Every year there is a list of new malicious technological advancements that cyberattackers invent. All of these advancements target your cluster’s vulnerabilities. So, the best way to prevent these deadly incidents is to configure a way to protect your applications' vulnerable points. This article has provided various ways to secure a Kubernetes cluster. All of the security concepts discussed are crucial and have to be implemented at the beginning when the cluster is being created.

When it comes to securing your cluster, you have to always be one step ahead. You can save the hustle and bustle of manually securing the cloud infrastructure that hosts Kubernetes clusters by moving your cloud workload to CherryServers. CherryServers provides robust cloud security solutions such as Identity & Access Management(IAM), GDPR compliant and SSH keys.