Pierluigi Paganini July 15, 2020

How to enhance the security across a Kubernetes Infrastructure and mitigate the risk of cyber attacks.

By David Bisson

The security risks surrounding containers are well-known. Container images suffer from vulnerabilities that malicious actors could exploit for the purpose of gaining access to the larger container environment, for instance. Containers might also be able to acquire new privileges, thereby allowing malicious actors to abuse those rights for the purpose of moving laterally in the container environment. Finally, container images might contain secrets that could expose organizations’ sensitive data if compromised.

To mitigate the risks identified above as well as other threats, organizations spend a great deal of time focusing their Kubernetes security efforts on safeguarding their containers during the build, deploy and runtime phases. But those efforts won’t keep organizations safe. Indeed, the problem is that the Kubernetes infrastructure itself presents its own security risks.

Take clusters, for instance. These elements of the Kubernetes environment pose numerous security risks. Such risks include the following:

• Kubernetes explains on its website that the Linux kernel automatically loads kernel modules from disk. Unprivileged processes could therefore cause kernel modules to load, enabling an attacker to exploit security flaws in a neglected kernel module.
• Cloud platforms’ APIs might contain cloud credentials for a node or provisioning data such as kubelet credentials. Subsequently, malicious actors could compromise a pod and abuse those credentials for the purpose of escalating privileges within the cluster or other cloud services.
• Kubernetes does not impose any restrictions on a node that might run a pod. Security members could leverage policies to control the placement of pods on nodes. In the absence of these policies, organizations might leave themselves open to attack.

There’s also the issue of vulnerabilities. As noted by Sumo Logic, these security flaws might affect the operating systems installed on Kubernetes nodes. Malicious actors could then exploit those weaknesses in order to gain access to a Kubernetes cluster.

Such flaws might affect other parts of the infrastructure, as well. Security holes in the network layer of a Kubernetes environment could allow a threat actor to escalate their attacks between clusters, for instance, while weaknesses in the Kubernetes API and Kubectl management tool could also allow instances of abuse within the cluster.

How to Secure Their Clusters and Other Kubernetes Infrastructure

As discussed above, organizations could expose themselves to multiple risks if they fail to take the security of their Kubernetes infrastructure into consideration. That’s why it’s imperative that organizations leverage best practices to secure their Kubernetes environments.

StackRox recommends that organizations follow four guidelines in particular:

Keep an updated version of Kubernetes

By regularly updating their Kubernetes version, organizations can help to ensure that they remain informed about the latest vulnerabilities affecting their environments. They can then leverage news of a vulnerability to take remediation action. Specifically, they can determine whether they should take mitigation actions or schedule a patch in accordance with their vulnerability management program.

Organizations need to remember one thing, however: Kubernetes supports only the last three versions of its software. That means only those versions will receive patches for newly disclosed vulnerabilities. If they’re running an older version of the software, organizations won’t receive a patch, and they’ll open themselves up to an attack in the process.

Configure the Kubernetes API Server

If the Kubernetes API server is not properly configured, organizations could enable malicious actors to gain unauthenticated/anonymous access to their Kubernetes environment. Those digital attackers could then leverage that access to move around the environment, compromise additional assets and expose organizations’ sensitive data.

To prevent this from happening, organizations need to make sure that they’ve disabled unauthenticated/anonymous access on their API server. They should also ensure that they’re using TLS encryption for connections between the kubelets and the API server. Doing so will further strengthen the security of their Kubernetes infrastructure.

Secure etcd

As noted in Kubernetes’ documentation, etcd is a key value store that functions as the software platform’s backing store for cluster data. Gaining access to etcd is tantamount to gaining root privileges on the cluster. Ideally, only the API should have access to etcd.

It’s therefore imperative that organizations secure their etcd by using TLS authentication to limit which nodes can access it. Beyond that, organizations should use firewall rules and security features that come with etcd to further secure this component. For instance, they can generate secure communication channels by leveraging etcd’s x509 Public Key Infrastructure (PKI) to generate a key and certificate pair.  

Secure the kubelet

Kubelets serve as the main node agents running on each node. As such, misconfiguring a kubelet could open an organization to backdoor access through the kubelet. Malicious actors could subsequently abuse that access to compromise the organization’s data. Acknowledging that possibility, organizations need to control access to the kubelet. They can do so by enabling kubelet authorization and authentication. They should also use the NodeRestriction admission controller to limit what resources a kubelet can access in an organization’s Kubernetes environment

Pierluigi Paganini

(SecurityAffairs – hacking, Kubernetes)

[adrotate banner=”5″]

[adrotate banner=”13″]