Pierluigi Paganini
July 15, 2020
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:
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.
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:
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.
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.
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.
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
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, Kubernetes)
[adrotate banner=”5″]
[adrotate banner=”13″]
