Which Linux distro is the most secure for Kubernetes?

Security is a very hard thing to define. Something that checks all the boxes for “secure” may be vulnerable to known issues, and something that doesn’t pass scans may actually be secure from malicious actors.

Talos Linux does a lot of things differently for two reasons: to reduce maintenance and increase security. Unfortunately, doing things differently in the security space isn’t always welcome because auditing tools adapt slowly and prioritize traditional, more vulnerable software stacks.

To avoid philosophical debates, let’s align and say that “secure” distributions have a low number of known Common Vulnerabilities and Exposures (CVEs). We believe Talos Linux’s security model goes far beyond this basic metric, but let’s use it as a baseline for comparison.

We’ve already shown that Talos is the smallest HA Kubernetes deployment and it has the fewest number of binaries on a system, so now let’s look at how it stacks up in the security department.

Talos Linux provides SPDX-formatted SBOM files for all of the libraries used in our system management software and packages. We also maintain a VEX database to provide more information if CVEs are exploitable on Talos. There are a lot of CVEs that apply to very specific configurations and use cases that don’t apply to a single-purpose Linux distribution like Talos.

Because everything in Talos Linux is connected with an API, we also provide an API endpoint to get an SBOM from a >1.11.0 system. Next time you install Talos Linux, give it a try with:

talosctl get sboms

So let’s see how popular distributions compare. We’re going to be using grype for all of the scanning and comparison. We’re running these tests on 2025/09/03 with default configurations and up-to-date installations of each operating system.

CVE comparison

When looking at CVEs, grype has a few different ways to gather information and check for vulnerabilities. You can use container images, but those are not the same thing as you would run on an actual server because they exclude things such as the Linux kernel. So in this case, let’s look at grype on Talos Linux, Flatcar, Ubuntu, and Rocky.

Results are from the following command sudo grype dir:/. Because Talos Linux doesn’t have a shell we gathered CVEs from the SBOM files as described in the documentation.

You can see just how few CVEs a Talos Linux system has. Flatcar also has a very respectable low number of CVEs thanks to their aggressive patching cadence. All of the non-fixed CVEs in Talos Linux come from the Linux kernel. Talos Linux only ships with the latest, long-term supported (LTS) kernels, which bring with them some level of not-fixed CVEs.

Ubuntu and Rocky Linux don’t even come close. If you want a low-CVE Ubuntu distribution, you’ll need to pay for Ubuntu Pro. I don’t even know where to start with Rocky’s 10,808 CVEs. That sounds like a lot of work. If you’re using a meta distribution like Kairos, you’ll be inheriting many of the CVEs from these general-purpose distributions.

Above and beyond CVEs

As we said before, CVEs aren’t the only thing that make an operating system secure. There are a lot of other configurations and settings you can include, and Talos Linux does them by default.

• Kernel hardening
• Kernel module signing
• Pod security admission
• System extensions
• FIPS

Kernel hardening

Talos Linux ships with a kernel built from scratch specifically for running Kubernetes. That means we can remove a lot of unneeded configurations and apply settings out of the box that can make this easier and more secure.

The Linux Kernel Self-Protection Project (KSPP) is a set of configurations and settings recommended by the security community to keep the Linux kernel secure. Talos Linux applies these settings by default. There’s no additional kernel hardening required if your goal is aligned with KSPP standards.

Kernel module signing

Talos Linux is the only distro that requires kernel module signing. This provides an additional layer of security to know that only modules that came from a trusted source can be run at an elevated privilege level inside your operating system.

This requirement is the reason we built System Extensions and some operators and CSI storage providers don’t work on Talos Linux. Many of them dynamically build and load kernel modules on a system on the fly. No verification, no signatures. That is not secure and could easily compromise the stability of your OS.

Pod security admission

Talos Linux deploys upstream Kubernetes directly from the open source releases. It doesn’t fork Kubernetes into a special binary or remove components to change it in any way. But that doesn’t mean we deploy Kubernetes in a default, insecure way.

Kubernetes clusters running on top of Talos Linux automatically get the “baseline“ Pod Security Admission (PSA) policies applied. This prevents workloads from running that could compromise your host or other Kubernetes workloads. By making namespaces secure by default, it forces users to make a choice to disable security checks or make their workloads more secure.

Every other distribution uses the “privileged” policy, which allows any workload to run no matter if it uses an insecure configuration or not.

System extensions

System Extensions are built at the same time as the Talos Linux release with an ephemeral signing key. No one — not even Sidero ― can modify the kernel signing key after the system has been built. This couples each system extension with each release of Talos to ensure that they are compatible and tested together.

This also means we can provide SBOM information for supported System Extensions as part of the system build. When you add extensions, you also need to validate what software is included. Flatcar sysext doesn’t provide that information. It’s up to you to know which volumes you’re mounting at run time and scan the files to build and report SBOM and CVE information.

FIPS

Regulated environments need to meet certain compliance standards such as FIPS 140-3. Many operating systems will have some way to configure a FIPS “mode” that applies to specific libraries such as OpenSSL. This usually requires extra configuration and validation to make sure all of the software dependencies (e.g. SSH) comply.

Talos also provides a FIPS-compliant build that is baked into the operating system. Because all communication happens over a mutually authenticated TLS (mTLS) connection, we are able to enable FIPS-approved cryptography at build time and you just use Talos like you normally would. If you need FIPS, please reach out to our sales team at [email protected] and we’d be happy to get you started.

Conclusion

The next time you look for a secure Linux distribution, make sure you look beyond just CVE numbers. They can be a good starting point, but they’re by no means a complete picture.

Talos Linux rethinks OS security from the ground up to not only make it easier to meet compliance requirements, but also to be actually secure. If you need to secure your base infrastructure anywhere, give Talos a try and reach out to our team to make it simply secure.