Moving to the cloud remains a critical business initiative for most organizations. Indeed, the World Economic Forum once again focused on digital transformation this year, along with public sector innovation and the application of emerging technologies in government and public sector organizations. Government technology alone is expected to reach a market size of over $1 trillion by 2028, becoming the biggest software market in the world. This transformation, which also applies to the private sector, includes moving more applications and services to the cloud.
However, as organizations adopt cloud and cloud-native technologies such as Kubernetes and containers, managing security presents some new challenges. In Red Hat’s 2023 State of Kubernetes security report, 37% of respondents experienced revenue or customer loss due to a container/Kubernetes security incident. Thirty-eight percent cited security as one of their top concerns with container and Kubernetes strategies. These incidents and concerns highlight how important it is to both secure Kubernetes and track and monitor workload security over time.
Fairwinds gathered data from over 330,000 workloads and hundreds of organizations to assemble the 2024 Kubernetes Benchmark Report, analyze trends based on data gathered in 2023, and compare it to data from the previous two years. While many organizations are already using or evaluating Kubernetes, aligning to best practices can be a challenge for organizations of all sizes. Unfortunately, this lack of alignment may result in elevated security risks, unmanaged cloud costs, and decreased reliability of cloud apps and services.
For anyone trying or already deployed on Kubernetes, it’s important to remember that it is not secure out of the box. The checks below can help you ensure that your organization is configuring Kubernetes with security top of mind.
Some Linux capabilities are enabled for Kubernetes workloads by default, though few workloads need these capabilities. In the latest report, it seems as though organizations have not been as successful in limiting these insecure capabilities. In our first benchmark report (based on 2021 data), 42% of organizations were disabling insecure capabilities, while the 2023 data showed only 21% taking this key step. Ideally, most organizations need to turn off these capabilities.
The security setting readOnlyRootFilesystem controls whether a container is able to write to its filesystem. Most organizations want this setting enabled in the event of a hack, because an attacker will not be able to tamper with the application or write foreign executables to disk if it is properly set. Kubernetes workloads do not set readOnlyRootFilesystem to true by default, which requires teams to set it to true to get the most secure configuration possible. This year, 38% organizations overrode the insecure defaults for 71-100% of their workloads, down from 56% of organizations the previous year.
A container may be able to escalate its privileges under some conditions, however, if you set allowPrivilegeEscalation to false, it will set the no_new_privs flag on the container process, which prevents setuid binaries from changing the effective user ID. This is particularly important when you are using runAsNonRoot, which is also not disabled by default.
The latest benchmark shows 14% of organizations running 90% of their workloads impacted with privilege escalation, down from 29% the previous year. In addition, 22% of organizations have less than 10% of workloads impacted.
The privileged key determines whether any container in a pod can enable privileged mode. By default, an unprivileged container cannot access any devices on the host, but a privileged container has access to all devices on the host. This allows a privileged container nearly the same level of access permitted to processes running on the host, which is necessary for containers that need to use Linux capabilities, including manipulating the network stack and accessing devices. Most containers do not need this level of access.
The latest data shows that this year 84% of organizations have 0-10% of workloads impacted by a container being permitted to enable privileged mode, close to the same as it was the previous year (87%) in 2023 to 83% in 2024. There’s still room to check, however, as 16% of organizations have 11-20% of workloads impacted by the ability to run as privileges in 2024.
In general, you should not have your containers configured to run as a root user in a Kubernetes cluster. This is because malicious users could leverage root privileges to compromise the system or access sensitive data. This is an area where there’s been significant improvement in 2024; just 30% of organizations allowed 71% or more of their workloads root access compared to 44% of organizations in the previous year.
We began tracking image vulnerabilities three years ago, and in that time there has been a staggering rise in the number of organizations with more than 90% of workloads impacted — up from 9% in 2022 to 30% in 2024. Malicious actors can use vulnerabilities to compromise your environments, therefore they must be patched or remediated as quickly as possible. Organizations that regularly patch images can minimize the percentage of workloads affected by vulnerabilities and thereby reduce security risk.
Scanning container images for vulnerabilities is the only reliable way to identify problems in this area. This year, the benchmark shows 84% of organizations have less than 10% of workloads impacted by unscanned images, down from 64% in 2023. The latest analysis shows only 16% of organizations have more than 91% workloads impacted by not scanning images. There are multiple open source scanning tools available that organizations can use to scan images for vulnerabilities.
Outdated Helm charts are common in most organizations. This year, the benchmark showed that more than 70% of organizations have 11% or more workloads impacted by outdated Helm charts. Most of the add-ons running your cluster are probably installed by Helm, and each add-on has its own release cadence. Some of those updates may include critical security patches, but unless you ensure that your Helm charts are not outdated, it’s hard to know whether you’re missing an important patch. Due to the complexity of Helm chart updates, many teams may be running outdated Helm charts. You can use Nova, an open source tool, to cross-check Helm charts running in the cluster with the latest version available.
The benchmark also analyzed how many organizations are running outdated container images. This year, 46% of organizations have 90% or more of workloads impacted by outdated container images, up from 33% the previous year. You can identify outdated container images using Nova and the flag called “containers,” which reviews all container images in a Kubernetes cluster and notifies you if there is an updated version available. You can choose to update images to the latest version, the latest minor version, or the most recent patch version. Updating outdated Helm charts or container images can help you minimize some security risks.
To ensure that workloads continue to function after Kubernetes upgrades, you need to monitor for deprecated API versions. This is an important way to de-risk Kubernetes upgrades. The latest benchmark shows that most organizations are doing well at minimizing deprecated API versions; 83% of organizations have only 0-10% of workloads impacted by the issue.
Containers and using Kubernetes for container orchestration enables your organization to shift to cloud-native applications and services, bringing significant value to your organizations. However, those who adopt Kubernetes and deploy applications and services must also understand how to set configurations appropriately to reduce security risk. The 2024 Kubernetes Benchmark report helps you see common areas where configurations tend to be missed and how to make changes that ensure your deployment is as secure, reliable, and cost-efficient as possible.
Read the complete Kubernetes Benchmark Report today.
