[{"data":1,"prerenderedAt":365},["ShallowReactive",2],{"blog-en-k3s-k8s-default-serviceaccount-automount-rbac-multi-tenant":3,"blog-related-en-k3s-k8s-default-serviceaccount-automount-rbac-multi-tenant":316,"blog-en-k3s-k8s-default-serviceaccount-automount-rbac-multi-tenant-alt":304},{"id":4,"title":5,"author":6,"body":7,"date":298,"description":299,"extension":300,"image":301,"locale":302,"meta":303,"navigation":304,"path":305,"seo":306,"stem":307,"tags":308,"__hash__":315},"blog\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant.md","K3s and Kubernetes Share the Same Default ServiceAccount Trap. What Happens When You Leave Automount Enabled in a Multi-Tenant Cluster","Kubo Team",{"type":8,"value":9,"toc":288},"minimark",[10,18,26,31,45,62,66,72,75,91,111,124,128,134,141,160,167,171,177,186,189,193,199,202,236,251,265,269,272],[11,12,13],"p",{},[14,15],"img",{"alt":16,"src":17},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection01.webp",[11,19,20,21,25],{},"In a test multi-tenant cluster, a Pod belonging to Tenant A was able to read Secrets that belonged to Tenant B. When the root cause was traced, neither tenant's Namespace had any of the special misconfigurations usually discussed in \"k3s vs k8s\" comparison articles. What was actually there was simpler: the ",[22,23,24],"code",{},"default"," ServiceAccount token, automatically created for every Namespace, had been quietly automounted into Pods the whole time, with nobody giving it a second thought.",[27,28,30],"h2",{"id":29},"_1-the-incident-the-neighboring-tenants-secrets-were-readable","1. The Incident: \"The Neighboring Tenant's Secrets Were Readable\"",[11,32,33,34,37,38,41,42,44],{},"Here is how it happened. Multiple teams shared the same K3s cluster for a test environment, and each team assumed that splitting workloads into separate Namespaces was enough for isolation. But part of a RoleBinding had been configured too broadly, tied to a ",[22,35,36],{},"ClusterRole"," through a ",[22,39,40],{},"ClusterRoleBinding",". Querying the API server with a Pod's ",[22,43,24],{}," ServiceAccount token turned out to enumerate resources in a different Namespace that should have been completely out of reach.",[11,46,47,48,55,56,61],{},"What an attacker looks for immediately after compromising a Pod is exactly this kind of credential: one that exists but is never actually used. Most Pods have no code path that ever calls the Kubernetes API, yet the token gets dutifully mounted anyway. This lateral-movement pattern is repeatedly called out from a MITRE ATT&CK perspective as well (",[49,50,54],"a",{"href":51,"rel":52},"https:\u002F\u002Fwww.redhat.com\u002Fen\u002Fblog\u002Fprotecting-kubernetes-against-mitre-attck-lateral-movement",[53],"nofollow","Red Hat's write-up","). A managed K8s platform makes it easier for operators to notice these unused, leftover credentials in the first place. An environment like ",[49,57,60],{"href":58,"rel":59},"https:\u002F\u002Fkubo.hexabase.io\u002F",[53],"Kubo",", where the cluster configuration is visible through Captain UI's dashboard, is one option for reducing this kind of \"invisible gap.\"",[27,63,65],{"id":64},"_2-compare-k3s-vs-k8s-all-you-want-the-default-serviceaccount-has-the-same-trap","2. Compare k3s vs k8s All You Want — the Default ServiceAccount Has the Same Trap",[11,67,68],{},[14,69],{"alt":70,"src":71},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection02.webp",[11,73,74],{},"This is the part that's easy to miss. When people discuss \"k3s vs k8s,\" they're usually talking about differences in CNI choice, control-plane architecture, or CI\u002FCD compatibility — not RBAC mechanics, which don't differ at all. Role, ClusterRole, RoleBinding, and ClusterRoleBinding behave identically whether you're running k3s or vanilla Kubernetes.",[11,76,77,78,80,81,84,85,90],{},"So what is different? Kubernetes automatically creates a ServiceAccount named ",[22,79,24],{}," in every Namespace, and unless a Pod spec explicitly opts out, that ServiceAccount's API credential gets automounted at ",[22,82,83],{},"\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken",". This default behavior is documented in the ",[49,86,89],{"href":87,"rel":88},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fconfigure-pod-container\u002Fconfigure-service-account\u002F",[53],"official Kubernetes documentation",", and it applies equally to k3s and plain Kubernetes.",[11,92,93,94,97,98,110],{},"There's also a precedence trap that makes this worse. Even if you set ",[22,95,96],{},"automountServiceAccountToken: false"," on the ServiceAccount, ",[99,100,101,102,105,106,109],"strong",{},"a Pod's ",[22,103,104],{},".spec"," setting of ",[22,107,108],{},"true"," takes precedence",". \"I thought I'd closed this off at the ServiceAccount level, but one particular Pod still had a hole\" is an incident that reliably recurs for anyone who doesn't know about this precedence rule.",[11,112,113,114,117,118,123],{},"k3s does add its own wrinkle, though. k3s ships with a powerful admin kubeconfig bundled at ",[22,115,116],{},"\u002Fetc\u002Francher\u002Fk3s\u002Fk3s.yaml"," right out of the box. That's convenient for testing and homelab use, but when the same mindset carries over into a multi-tenant production rollout, the habit of reaching for admin credentials instead of thinking about RBAC tends to leave behind exactly the kind of \"loose RoleBinding\" described above. In fact, ",[49,119,122],{"href":120,"rel":121},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fhardening-guide",[53],"k3s's own CIS Hardening Guide"," states plainly that NetworkPolicy and Pod Security Standards are not applied by default — they require explicit configuration per Namespace. The assumption that \"k3s is lightweight, so I can deal with this later\" leads to the same trap every time.",[27,125,127],{"id":126},"_3-this-isnt-hypothetical-what-cve-2026-61549-shows-about-externally-specified-serviceaccountname","3. This Isn't Hypothetical: What CVE-2026-61549 Shows About Externally-Specified serviceAccountName",[11,129,130],{},[14,131],{"alt":132,"src":133},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection03.webp",[11,135,136,137,140],{},"A real-world example of \"what happens when you let ServiceAccount selection come from external input\" is a 2026 vulnerability in the Kubernetes backend of the CI\u002FCD tool Woodpecker. The pipeline YAML's ",[22,138,139],{},"backend_options.kubernetes.serviceAccountName"," field was passed straight through to the Pod spec without validation.",[11,142,143,144,149,150,155,156,159],{},"As a result, anyone with push access to the connected repository could specify an arbitrary ServiceAccount within the pipeline Namespace. If a privileged ServiceAccount happened to exist in that Namespace, an attacker's pipeline Pod could obtain its token and escalate all the way to reading Secrets, enumerating cluster resources, and gaining cluster-admin privileges. The ",[49,145,148],{"href":146,"rel":147},"https:\u002F\u002Fgithub.com\u002Fadvisories\u002FGHSA-qf34-295c-26v8",[53],"GitHub Security Advisory (GHSA-qf34-295c-26v8)"," rates this as CVSS 8.2 (High), and according to a ",[49,151,154],{"href":152,"rel":153},"https:\u002F\u002Fsecurelayer7.net\u002Flab\u002Fcve-2026-61549-woodpecker-ci-kubernetes-serviceaccountname-privilege-escalation",[53],"detailed technical write-up",", every version prior to v3.16.0 was affected. The fix introduced a gate called ",[22,157,158],{},"ServiceAccountNameAllowFromStep",", disabled by default and only active when an operator explicitly sets the corresponding environment variable.",[11,161,162,163,166],{},"This isn't unique to CI\u002FCD pipelines — any design where \"ServiceAccount name is decided by some external input\" shares the same root cause as the default ServiceAccount trap. Even when running GitOps pipelines through something like ",[49,164,60],{"href":58,"rel":165},[53],"'s standard ArgoCD\u002FFlux integration, there's value in fixing ServiceAccount assignment rules at the template level rather than letting pipeline definitions choose freely.",[27,168,170],{"id":169},"_4-this-isnt-rare-its-on-the-rise-threat-statistics","4. This Isn't Rare — It's on the Rise (Threat Statistics)",[11,172,173],{},[14,174],{"alt":175,"src":176},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection04.webp",[11,178,179,180,185],{},"It's tempting to assume this only happens in unusual configurations, but the data says otherwise. According to ",[49,181,184],{"href":182,"rel":183},"https:\u002F\u002Funit42.paloaltonetworks.com\u002Fmodern-kubernetes-threats\u002F",[53],"Palo Alto Networks Unit 42's threat report",", threat-actor activity involving Kubernetes token theft increased 282% year over year, and suspicious ServiceAccount token-theft activity was detected in 22% of cloud environments. Kubernetes-related alert volume also reportedly jumped from roughly 122,000 in 2024 to about 467,000 in 2025 — nearly a 3.8x increase.",[11,187,188],{},"What these numbers show is that leaving the default ServiceAccount unattended isn't an obscure misconfiguration — it's an increasingly common target for attackers. In multi-tenant environments, a single lax Namespace can spill over to affect every other tenant.",[27,190,192],{"id":191},"_5-four-layers-that-actually-protect-a-multi-tenant-environment","5. Four Layers That Actually Protect a Multi-Tenant Environment",[11,194,195],{},[14,196],{"alt":197,"src":198},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Fsection05.webp",[11,200,201],{},"RBAC alone isn't enough. Protecting a multi-tenant environment realistically requires combining at least these four layers:",[203,204,205,212,218,224],"ul",{},[206,207,208,211],"li",{},[99,209,210],{},"Explicitly disable automountServiceAccountToken",": Set it on both the ServiceAccount and the Pod, keeping in mind that the Pod-level setting wins, and check for gaps accordingly.",[206,213,214,217],{},[99,215,216],{},"Default-deny NetworkPolicy",": The \"block everything first, then explicitly allow only the routes you actually need\" approach is effective at cutting off inter-tenant traffic.",[206,219,220,223],{},[99,221,222],{},"Resource isolation with ResourceQuota \u002F LimitRange",": Set explicit total request and limit values for CPU and memory per tenant so that one tenant can't degrade another's performance.",[206,225,226,229,230,232,233,235],{},[99,227,228],{},"Enforcement through a policy engine",": A policy engine like Kyverno can automatically patch ",[22,231,96],{}," onto the ",[22,234,24],{}," ServiceAccount created whenever a new Namespace is created, structurally preventing configuration gaps.",[11,237,238,239,244,245,250],{},"This combination is echoed in ",[49,240,243],{"href":241,"rel":242},"https:\u002F\u002Fvcluster.com\u002Fblog\u002Fbest-practices-for-achieving-isolation-in-kubernetes-multi-tenant-environments",[53],"an article on multi-tenant isolation best practices",", which lists RBAC, NetworkPolicy, and ResourceQuota together as the baseline for \"practical isolation.\" Using something like ",[49,246,249],{"href":247,"rel":248},"https:\u002F\u002Fkyverno.io\u002Fpolicies\u002Fother\u002Fdisable-automountserviceaccounttoken\u002Fdisable-automountserviceaccounttoken\u002F",[53],"Kyverno's automated mutation policy"," to apply this consistently across the whole cluster removes the human error of per-Pod configuration gaps.",[11,252,253,254,258,259,264],{},"In a managed environment like ",[49,255,257],{"href":58,"rel":256},[53],"Kubo Cloud",", Captain UI's visual dashboard keeps the cluster state from becoming a black box, which makes it easier to notice this kind of \"I thought I'd configured it\" gap. For industries with strict data-sovereignty requirements, such as finance or healthcare, an option like ",[49,260,263],{"href":261,"rel":262},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[53],"Kubo On-Premise"," lets you apply the same multi-tenant design while keeping everything under your own control.",[27,266,268],{"id":267},"summary","Summary",[11,270,271],{},"When people compare k3s and Kubernetes, the discussion tends to focus on CNI choices and control-plane architecture — but when it comes to the default behavior of RBAC and ServiceAccounts, there's no difference between the two at all. Continuing to use the default ServiceAccount as-is turns into a real risk the moment a cluster moves from a test environment into multi-tenant production. As CVE-2026-61549 shows, and as the 282% year-over-year increase in threat activity confirms, this isn't a theoretical concern — it's an attack surface that's actually growing.",[11,273,274,275,278,279,281,282,287],{},"Rather than manually checking automount settings, NetworkPolicy, ResourceQuota, and policy-engine enforcement every time a Pod is created, it's better to template these four layers into the platform itself. ",[49,276,60],{"href":58,"rel":277},[53]," is a full-featured Kubernetes distribution built on K3s that lets you build in this kind of multi-tenant design from the start, making it one option for closing this \"invisible gap.\" A good place to start is simply checking what state your own cluster's ",[22,280,24],{}," ServiceAccount is in right now. You can also reach out via our ",[49,283,286],{"href":284,"rel":285},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[53],"contact page"," to talk it through.",{"title":289,"searchDepth":290,"depth":290,"links":291},"",2,[292,293,294,295,296,297],{"id":29,"depth":290,"text":30},{"id":64,"depth":290,"text":65},{"id":126,"depth":290,"text":127},{"id":169,"depth":290,"text":170},{"id":191,"depth":290,"text":192},{"id":267,"depth":290,"text":268},"2026-10-23","Comparing k3s vs k8s doesn't change the default ServiceAccount automount trap. We cover the privilege-escalation risk in multi-tenant clusters, a real CVE, and a 4-layer defense.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant\u002Ftitle.webp","en",{},true,"\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant",{"title":5,"description":299},"blog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant",[309,310,311,312,313,314],"k3s","kubernetes","rbac","serviceaccount","multi-tenancy","security","PeDJCP6LYh6UvOT1ImRUvaC9_scz5sH4bdz9SEsPP78",[317,325,334,342,350,358],{"path":318,"title":319,"description":320,"date":321,"tags":322},"\u002Fblog\u002Fen\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64 Isn't Encryption: Why Kubernetes Secrets Pass Right Through, and the RBAC Design Traps That Make It Worse","Kubernetes Secrets are only Base64-encoded, not encrypted. Learn how plaintext-equivalent storage in etcd and over-permissioned RBAC lead to real incidents, plus the concrete Secrets management practices you need for production K3s.","2026-07-29",[310,309,323,311,314,324],"secrets-management","etcd-encryption",{"path":326,"title":327,"description":328,"date":329,"tags":330},"\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage","We Enabled Restricted and ServiceLB Died: The K3s Pod Security Admission Gap No Generic Guide Mentions","Enabling the restricted Pod Security Admission profile on K3s following standard Kubernetes guides can silently kill ServiceLB. Here's why, backed by K3s's own CIS hardening guide, and how to roll it out safely.","2026-10-16",[309,310,331,332,333,314],"pod-security-admission","pod-security-standards","servicelb",{"path":335,"title":336,"description":337,"date":338,"tags":339},"\u002Fblog\u002Fen\u002Fk3s-zero-trust-kubectl-management-access","Stop Trusting Your Corporate VPN: 3 Steps to Make K3s Management Access Boundary-Free","Are you still designing K3s cluster management access around a corporate VPN? Learn 3 practical steps to secure kubectl and Rancher dashboard access with identity instead of network perimeter, plus the pitfall most teams hit when they implement zero trust.","2026-09-05",[309,310,340,314,341],"zero-trust","rancher",{"path":343,"title":344,"description":345,"date":346,"tags":347},"\u002Fblog\u002Fen\u002Fk3s-mcp-ai-agent-rbac-permission-bypass","We Asked an AI Agent to 'Check a Pod,' and It Took Over the Entire K3s Cluster: What an MCP Server's Permission Bypass Teaches Us About RBAC Design","A real-world MCP permission bypass shows why Kubernetes\u002FK3s clusters need disciplined RBAC design and audit-log separation before letting AI agents operate them.","2026-09-03",[309,310,348,311,349],"mcp","ai-agent",{"path":351,"title":352,"description":353,"date":354,"tags":355},"\u002Fblog\u002Fen\u002Fkubernetes-certificate-management-cert-manager-process-debt","The Cert Renewal Took One Line of Code and Two Months of Meetings: Why Kubernetes Certificate Management Is a Process Problem, Not a Technical One","Kubernetes certificate management is technically a matter of days. What actually takes time is the organizational process of getting sign-off. Here's how cert-manager automates the technical side, and how to design away the operational debt that remains.","2026-08-09",[309,310,356,357,314],"cert-manager","tls",{"path":359,"title":360,"description":361,"date":362,"tags":363},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[309,310,364,349,314],"kata-containers",1792736066588]