Support of K3s to reduce attack surface

[martinholovsky]

Hi everyone,

I'm a huge fan of Talos and its core philosophy. Focus on immutability and minimizing the attack surface by cutting out things like SSH and a general-purpose shell is exactly why I use it.

Following that same logic, I think it's worth considerering adding official support for K3s.

My main argument isn't about saving a few megs of RAM; it's about security alignment. Talos hardens the node, but we should also be thinking about hardening Kubernetes itself. This is where K3s shines. It's a conformant k8s distribution that has been aggressively stripped down, which directly reduces the attack surface of the control plane.

Here’s why it’s such a good fit:

• It guts legacy k8s features. K3s removes numerous in-tree, alpha, and non-essential features. If the code isn't there, it can't be exploited. This is the exact same principle that makes Talos great.
• It gets rid of etcd's complexity. Let's be honest, managing, securing, and backing up etcd is a major operational headache. K3s replaces it with simpler options like embedded SQLite, removing a huge piece of complex infrastructure that can be misconfigured or attacked.
• It's a single binary. The entire control plane is a single, statically-linked binary. This makes it incredibly easy to audit, scan for vulnerabilities, and verify. There are simply fewer moving parts to worry about.

Talos applies minimalism to the OS. K3s applies minimalism to Kubernetes. The combination feels like the logical endgame for anyone trying to build a truly secure, minimal stack from the metal up.

Quick Comparison: k8s vs. K3s

Feature	Standard Kubernetes (k8s)	K3s (Lightweight k8s)	Security Implication
Architecture	Multiple distributed binaries	Single, static binary	Single process to secure & monitor. Simple to audit.
Datastore	etcd (complex & critical)	Pluggable; defaults to SQLite	Eliminates a major source of operational complexity and misconfiguration risk.
Dependencies	Requires containerd to be installed separately	containerd is embedded	Tighter integration, fewer external dependencies to manage and secure.
Codebase	Includes many legacy & alpha features	Legacy/alpha features removed	This is key. A huge reduction in potential CVEs and exploitable code paths.
Control Plane RAM	2 GB+	512 MB	K3s consolidates server processes and replaces heavy etcd with a lightweight SQLite database by default.
Overall Footprint	Large & complex (1,5 GB of code!)	Dramatically reduced (75 MB!)	A smaller, more defensible footprint that's easier to understand and lock down.

I know this isn't a zero-effort change and adds a new distribution for the team to maintain. But for those of us deploying in high-security or edge environments, a Talos + K3s option would be a killer feature that delivers on the project's core promise in a way nothing else can.

What does everyone else think? Are there technical blockers I'm not seeing?

[smira]

I think your comparison compares kubeadm Kubernetes with K3s, not Talos Kubernetes with K3s.

For example:

• Talos takes care of etcd, so running it is easy, and I don't think SQLite is any great.
• Talos has latest containerd always, and no management is required.
• Talos can run controlplane with 1 GiB of RAM, even though it would be pretty limited.

Security argument is at least questionable, as removing code doesn't always lead to better security - Kubernetes has more eyes and testing, while K3s might have introduced security issues by "removing" code.

I'd say I'm not convinced :)

[martinholovsky]

Hmm, its primarily about K8s vs K3s. What modification of K8s is included in Talos OS? Is it anywhere described?

In terms of attack surface, having 95% smaller binary is quite a big attack surface reduction. It reminds me comparison of those old driver in linux kernel for devices which arent manufactured for 20 years. I remember some of them leads to escape-to-hypervizor on VMware (I think it was some floppy driver)

[smira]

Talos runs vanilla Kubernetes, except for the kubelet which is re-packaged to run in container.

Removing stuff is good as long as it is properly tested, but simply removing code doesn't mean it becomes more secure, unless it is done by people who understand consequences of such actions.

So for me running "vanilla" Kubernetes vs. running "someone decided to drop some stuff" approach doesn't lead to security immediately. If Kubernetes itself offers tested and modularized Kubernetes-lite, I would probably agree.

If you bring some example when K3s was not vulnerable to some Kubernetes CVEs as a result of removing code (vs. Kubernetes vulnerable in a default configuration), it would be nice to see.

[rothgar]

Every decision has trade-offs. I understand that K3s tries to simplify Kubernetes management by repackaging Kubernetes. Talos simplifies Linux by only running 1 thing.

SQLite has trade-offs too. I agree it is simpler to understand and I've long been a proponent that upstream Kubernetes should investigate making a local file database an option (and maybe the default option). You can't do highly available control plane nodes without additional syncing and complexity, but individuals should be able to decide if they need that. Talos supports single node CP with standard etcd.

Your comparison of resource usage might apply for single node SQLite, but if you want the option to scale to multiple CP nodes (via etcd) then Talos uses fewer resources. And if resource usage is really a concern and you are ok using a single CP node then I would suggest you look at kubesolo which reduces the footprint even further and gets rid of more code than K3s (eg no scheduler).

If you have specific CVEs that K3s mitigates that Talos doesn't we'd love to hear about them! To my knowledge K3s default configuration is still less secure that Talos no matter how much code is in the the Kubernetes distribution.

[martinholovsky]

Hi @smira & @rothgar

as you both raised similar request, here is an analysis of vulnerabilities impacting k8s and how they were or could have been mitigated automagically by k3s. Its one part of big research report so tell me in case you would like me to share full report with you.

--- here we go ---

3.1 Datastore Vulnerabilities: etcd vs. SQLite

The choice of datastore is one of the most fundamental architectural differences between K8s and K3s, leading to a completely different vulnerability profile.

• Known etcd Vulnerabilities: As a distributed network service with a gRPC API, etcd has been subject to vulnerabilities related to its specific implementation. Examples include:

  • CVE-2023-25161: A flaw in the LeaseTimeToLive API that could allow a user without read permission to discover key names associated with a lease, leading to information disclosure in clusters with authentication enabled.^1^

  • CVE-2018-1099: An improper authentication issue where, if RBAC and client-certificate authentication were enabled, a client with any valid certificate could impersonate any user whose name matched the certificate's Common Name (CN).^1^

  • These vulnerabilities are intrinsic to etcd's features and network-accessible nature.

• K3s Mitigation through Replacement: A default, single-server K3s installation is architecturally immune to the entire class of etcd-specific CVEs. By replacing etcd with an embedded SQLite database, K3s removes the vulnerable component entirely.^2^ There is no

  etcd server process running, no gRPC API to attack, and no Raft consensus protocol to exploit.

• The SQLite Security Model Trade-off: This mitigation represents a shift in the security model, not an elimination of all risk. SQLite is not a network service; it is a C library that interacts directly with a local file on the server's filesystem.^4^ Its security posture is therefore governed by different principles:

  • Threat Model: The primary threats are not remote exploits against a network protocol, but local privilege escalation on the host machine and improper file permissions.

  • CVE Context: The developers of SQLite note that the vast majority of CVEs reported against the library require the attacker to already possess the ability to execute arbitrary SQL commands.^5^ In the K3s context, this would imply a prior, total compromise of the

    k3s server process itself, at which point the attacker already has control.

  • Primary Controls: Security for the K3s datastore relies on hardening the host OS and ensuring the K3s server process runs with the least privilege necessary. Critically, the datastore directory (/var/lib/rancher/k3s/server/db/) and the database file (k3s.db) must be protected with strict filesystem permissions (e.g., 600), making them accessible only to the root user or the K3s service account.^6^

3.2 Ingress Controller Vulnerabilities: A Case Study on "IngressNightmare"

The choice of a default ingress controller provides a powerful case study in how curating an ecosystem with security-first components can prevent catastrophic vulnerabilities.

• The ingress-nginx "IngressNightmare" Vulnerability: In March 2025, a series of critical vulnerabilities were disclosed in the popular ingress-nginx controller, collectively dubbed "IngressNightmare".^7^

  • CVE-2025-1974 (CVSS 9.8 Critical): The core vulnerability allowed an unauthenticated attacker with access to the cluster's pod network to achieve Remote Code Execution (RCE) within the ingress-nginx controller pod.^9^

  • Attack Vector: The flaw resided in the ingress-nginx admission controller webhook. An attacker could craft a malicious Ingress object with specially-formed annotations (exploiting other flaws like CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514).^8^ These annotations would inject arbitrary directives into the NGINX configuration file generated by the controller. The researchers discovered that the

    ssl_engine directive could be abused to load an arbitrary shared library from the pod's filesystem. By combining this injection with a method to upload a malicious library, an attacker could achieve RCE.^7^

  • Impact: Because the ingress-nginx controller often runs with high privileges, including access to all secrets in the cluster, this RCE could be used to steal credentials and achieve a full cluster takeover.^8^

• K3s Mitigation by Default Choice: K3s is not vulnerable to IngressNightmare in its default configuration because it bundles Traefik, not ingress-nginx.^13^ SUSE, the maintainers of K3s, explicitly confirmed this, stating that the default configuration is unaffected.^14^

• Architectural Immunity of Traefik: The mitigation is not a matter of luck or a simple patch; it is a result of fundamental, security-oriented design decisions in Traefik that make it immune to this entire class of attack.^7^

  1. No Raw Configuration Templating: Unlike ingress-nginx, which uses templating to generate a raw nginx.conf text file, Traefik parses all configuration inputs (whether from Kubernetes Ingress objects or its own CRDs) into strongly-typed Go data structures. There is no string-based templating mechanism, which completely eliminates the vector for configuration injection attacks.

  2. No Vulnerable Admission Controller Logic: Traefik does not employ an admission controller that executes an external binary (like nginx -t) to validate a generated configuration. It simply reads and parses the Kubernetes resources; if they are valid, it applies the configuration internally. If they are malformed, they are ignored. No configuration is ever "executed" during validation.

  3. No Dynamic Library Loading: Traefik is written in Go and is compiled into a single, statically linked executable. It is deliberately compiled without CGO, making it impossible to load and execute code from external shared libraries. There is no equivalent to NGINX's exploitable ssl_engine directive.

This case study demonstrates a crucial point: the internal architecture of a component is as vital to security as its external function. The maintainers of K3s, by selecting Traefik as the default, curated an ecosystem with a component whose design philosophy is inherently more robust against configuration injection attacks. This represents a proactive security choice that pays significant dividends by avoiding entire classes of critical vulnerabilities.

3.3 Container Runtime Vulnerabilities: CRI-O vs. containerd

The container runtime is another area where K3s's default choice mitigates specific risks.

• Known CRI-O Vulnerabilities: CRI-O, a runtime optimized for Kubernetes, has had its own unique vulnerabilities:

  • CVE-2024-5154 (CVSS 8.1 High): A path traversal vulnerability in CRI-O that allows a malicious container to create symbolic links on the host filesystem. This could permit the container to read or write files outside of its intended boundaries, leading to information disclosure or host compromise.^12^

  • CVE-2022-2995 (CVSS 7.1 High): An issue in CRI-O related to the incorrect handling of supplementary groups. In environments where negative group permissions are used for access control, a program in a container could potentially drop its primary group and bypass these controls, leading to sensitive data access or modification.^12^

• K3s Mitigation by Default Choice: K3s defaults to using containerd as its runtime.^19^ It is therefore

  not vulnerable by default to CVEs that are specific to the CRI-O codebase. While an operator could configure K3s to use CRI-O, the out-of-the-box installation is immune. This choice ties the security of a K3s node to the containerd project's security track record.

3.4 Core Component Vulnerabilities: Shared DNA, Different Risk

Even for components that K3s shares with upstream Kubernetes, its stripped-down nature and secure defaults can alter the risk profile.

• kubelet - Deprecated Feature Vulnerability (CVE-2025-1767):

  • Vulnerability: This medium-severity flaw affects the kubelet and is specific to clusters that use the deprecated in-tree gitRepo volume type. A user with permission to create pods could craft a pod that uses a gitRepo volume to gain access to the local git repository clones of other pods on the same node.^12^

  • Mitigation Analysis: The vulnerable code exists in the upstream kubelet component, which K3s includes. Therefore, a K3s cluster is technically vulnerable if an operator explicitly uses this deprecated feature. However, K3s's entire design philosophy is based on removing such in-tree features in favor of modern, out-of-tree alternatives.^22^ The recommended mitigation is to use a policy engine (like the built-in ValidatingAdmissionPolicy) to forbid the creation of pods with

    gitRepo volumes.^20^ A properly hardened K3s cluster would not be exposed to this risk.

• kube-apiserver - Admission Control Bypass (CVE-2016-1905):

  • Vulnerability: This historical vulnerability in the kube-apiserver involved improper checking of admission control rules during a patch operation. This allowed an authenticated user to modify an object in a way that bypassed security restrictions, potentially leading to resource access escalation.^12^

  • Mitigation Analysis: While this specific CVE was patched long ago, it highlights the critical importance of admission controllers. K3s strengthens the default security posture by enabling key admission controllers like PodSecurity and NodeRestriction out of the box.^25^ This provides a more secure baseline against such flaws compared to a standard K8s installation where these might be misconfigured or inadvertently disabled.

• kube-proxy - Windows-Specific Traffic Forwarding (CVE-2021-25736):

  • Vulnerability: This flaw was specific to kube-proxy running on Windows nodes. It could cause traffic intended for a LoadBalancer service to be unintentionally forwarded to other local processes on the node that were listening on the same port.^12^

  • Mitigation Analysis: This is a clear example of mitigation by deployment context. The vulnerability is entirely irrelevant to Linux-based clusters.^28^ Since the primary use cases for K3s are often in resource-constrained IoT and Edge environments, which are overwhelmingly Linux-based, the vast majority of K3s deployments are simply not affected.^29^

CVE ID	Affected K8s Component	Vulnerability Summary	Mitigated in Default K3s?	Mitigation Mechanism	Reasoning / K3s Component
CVE-2025-1974	ingress-nginx	Critical RCE via malicious annotation injection in the admission controller, leading to potential cluster takeover. ^8^	Yes	Component Replaced	K3s bundles Traefik by default, which is architecturally immune. Traefik does not use configuration templating or an exploitable admission controller design. ^14^
CVE-2023-25161	etcd	Information disclosure of key names via the LeaseTimeToLive API to users without read permissions. ^1^	Yes	Component Replaced	K3s uses an embedded SQLite database by default, not etcd. The vulnerable component and its API do not exist in a default installation. ^2^
CVE-2024-5154	CRI-O	High-severity path traversal allowing a malicious container to create symlinks on the host, leading to arbitrary file read/write. ^12^	Yes	Component Replaced	K3s bundles containerd as its default container runtime, not CRI-O. The vulnerable runtime is not present by default. ^19^
CVE-2022-2995	CRI-O	Incorrect handling of supplementary groups, potentially leading to privilege escalation or information disclosure in specific configurations. ^12^	Yes	Component Replaced	K3s defaults to containerd. The vulnerability is specific to the CRI-O implementation and does not affect containerd. ^13^
CVE-2021-25736	kube-proxy (on Windows)	Unintentional traffic forwarding from a LoadBalancer service to local node processes on Windows. ^26^	Yes (in common deployments)	Deployment Context	The vulnerability is specific to Windows nodes. The majority of K3s deployments, especially in Edge/IoT, are Linux-based, making the CVE not applicable. ^28^
CVE-2025-1767	kubelet	Access to other pods' local git repositories via the deprecated in-tree gitRepo volume type. ^20^	Yes (with hardening)	Architectural Philosophy / Policy	K3s's design eschews in-tree features. A hardened cluster would use policy (e.g., PSA) to block this deprecated and insecure volume type. ^22^
CVE-2017-1000056	PodSecurityPolicy Admission Plugin	Privilege escalation allowing use of any existing PodSecurityPolicy object. ^32^	Yes (in modern versions)	Component Evolution / Secure Defaults	PSPs are deprecated. Modern K3s uses Pod Security Admission (PSA) by default, which has a different, more robust security model. ^25^

[smira]

I don't think any of that applies for real, it's trying to present the facts in a way it shows K3s better, but I don't think it maps to Talos.

• ingress-nginx - Talos doesn't bundle any ingress, Kubernetes doesn't either
• etcd - etcd does mutual TLS auth, so nothing can access etcd anyways. It's same as saying that one can read SQLite file on disk.
• CRI-O - not applicable at all, Talos ships containerd (not that is has no CVEs, but it doesn't compare Kubernetes to K3s).
• kube-proxy on Windows - Talos doesn't run on Windows, so irrelevant.
• kubelet - not applicable in default configuration
• PodSecurityPolicy - deprecated in Kubernetes long time ago, not being used.

None of that show that K3s is better.

[martinholovsky]

Not sure I understand you. This is not about showing that k3s is better than Talos, its misconception. Its discussion about and if Talos with k3s can be more secure than Talos with k8s.

CVEs above were just examples on how minimalistic version of kubernetes could easily avoid certain types of vulnerabilities by attack surface reduction

[rothgar]

Please don't use AI generated text to spam github discussions. It takes much more time for us to read and understand the information that it did for you to generate the text.

If you have thoughtful, actionable information about how and why security vulnerabilities apply to Talos with Kubernetes using our default configuration and how that same CVE would not apply to K3s we would be interested in hearing them, but none of the information you have provided so far backs up your claims and you've "written" over 2000 words without considering how this would actually impact users.

At this time Talos has no plans to use k3s or make it available to use k3s instead of upstream Kubernetes.

[martinholovsky]

It was AI generated, because it will take me ±one week to map and summarize all k8s specific vulnerabilities (which I don't have), but I dont think this was spam. It shows vulns of k8s and which of them could have been mitigated/avoided if k3s will be used. It wasn't intended as a comparison with Talos

With that in mind, here is my response:

• ingress-nginx: its not bundled but the most common choice as there is no default, k3s doesnt limit you to avoid usage of ingress-nginx, but coming with default Traefik so users might have avoided using ingress-nginx
• etcd - point wasnt that etcd is inherently insecure, but key architectural difference. By replacing etcd with sqlite, k3s eliminated vulns specific to etcd. It shifts also security model from network service to protection of local file only.
• CRI-O: valid point, k3s deafult to containerd as well so its equal
• kubelet: gitRepo volume vulnerability was used to show how k3s design philosophy of removing deprecated, in-tree features aligns with best practices for hardening a cluster
• PSP: yes, it took maintainers quite a while to realize that this was a wrong path (5 years)

At the end its comparison of # of weaknesses and vulnerabilities within 1,5GB of code and 75MB of code (which is fully API compatible with k8s)

[rothgar]

From their documentation "K3s has diverged from upstream Kubernetes in order to optimize for edge deployments." They have a compatible API but other things become non-standard or difficult to do based on the optimizations they made for their intended use case. If you want a Kubernetes distribution that is more aligned with upstream and broad use cases they (SUSE) recommend using RKE2 (which uses etcd).

We love being able to reduce attack surface and limit the amount of code running, but we try to balance that with broad use cases and supportability. There are lots of "single binary" Kubernetes distributions (k0s, k3s, kubesolo, etc.) and we have no plans to integrate them into Talos at this time.