[{"data":1,"prerenderedAt":549},["ShallowReactive",2],{"blog-en-k3s-pod-security-admission-restricted-servicelb-outage":3,"blog-related-en-k3s-pod-security-admission-restricted-servicelb-outage":499,"blog-en-k3s-pod-security-admission-restricted-servicelb-outage-alt":487},{"id":4,"title":5,"author":6,"body":7,"date":481,"description":482,"extension":483,"image":484,"locale":485,"meta":486,"navigation":487,"path":488,"seo":489,"stem":490,"tags":491,"__hash__":498},"blog\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage.md","We Enabled Restricted and ServiceLB Died: The K3s Pod Security Admission Gap No Generic Guide Mentions","Kubo Team",{"type":8,"value":9,"toc":473},"minimark",[10,22,27,34,42,56,64,152,171,175,181,202,215,222,226,232,238,260,302,309,323,327,333,336,353,366,370,376,379,427,434,438,441,444,451,460,469],[11,12,13,14,21],"p",{},"The moment many operators enable the restricted Pod Security Admission (PSA) profile on a K3s cluster, every LoadBalancer-type Service loses its external IP. They followed the ",[15,16,20],"a",{"href":17,"rel":18},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fconfigure-pod-container\u002Fenforce-standards-namespace-labels\u002F",[19],"nofollow","official Kubernetes documentation"," to the letter, labeling namespaces exactly as instructed — so why does only K3s break? This article walks through the Pod Security Admission pitfall that only shows up when you compare K3s against standard Kubernetes.",[23,24,26],"h2",{"id":25},"_1-what-pod-security-admission-is-and-why-k3s-starts-from-a-different-baseline","1. What Pod Security Admission Is — and Why K3s Starts From a Different Baseline",[11,28,29],{},[30,31],"img",{"alt":32,"src":33},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection01.webp",[11,35,36,37,41],{},"Pod Security Admission (PSA) is an admission controller that inspects every Pod creation request against a security baseline. It defines three levels — privileged (unrestricted), baseline (blocks known privilege escalations), and restricted (enforces current Pod hardening best practices) — each of which can run in enforce (block violations), audit (log violations), or warn (warn only) mode (",[15,38,40],{"href":17,"rel":39},[19],"kubernetes.io official documentation",").",[11,43,44,45,50,51,41],{},"PSA graduated to stable in Kubernetes v1.25, released in 2022, replacing the older PodSecurityPolicy (PSP), which had languished in beta for years (",[15,46,49],{"href":47,"rel":48},"https:\u002F\u002Fwww.techtarget.com\u002Fit-infrastructure\u002Fnews\u002F252524237\u002FKubernetes-security-reaches-maturity-milestone-with-v125",[19],"TechTarget's coverage","). PSP's complex binding model tied to users and service accounts made it hard to operate, and it was fully removed in v1.25 (",[15,52,55],{"href":53,"rel":54},"https:\u002F\u002Fgoteleport.com\u002Fdocs\u002Fadmin-guides\u002Fdeploy-a-cluster\u002Fhelm-deployments\u002Fmigration-kubernetes-1-25-psp",[19],"Teleport's migration guide",[11,57,58,59,63],{},"The key design point to remember: ",[60,61,62],"strong",{},"PSA enforces nothing by default."," No policy applies until an administrator explicitly labels a namespace, by design, so that existing workloads aren't broken during gradual adoption.",[65,66,71],"pre",{"className":67,"code":68,"language":69,"meta":70,"style":70},"language-yaml shiki shiki-themes tokyo-night","apiVersion: v1\nkind: Namespace\nmetadata:\n  name: production\n  labels:\n    pod-security.kubernetes.io\u002Fenforce: restricted\n    pod-security.kubernetes.io\u002Fenforce-version: v1.37\n","yaml","",[72,73,74,91,102,111,122,130,141],"code",{"__ignoreMap":70},[75,76,79,83,87],"span",{"class":77,"line":78},"line",1,[75,80,82],{"class":81},"s0U2E","apiVersion",[75,84,86],{"class":85},"sAklC",":",[75,88,90],{"class":89},"sPY7s"," v1\n",[75,92,94,97,99],{"class":77,"line":93},2,[75,95,96],{"class":81},"kind",[75,98,86],{"class":85},[75,100,101],{"class":89}," Namespace\n",[75,103,105,108],{"class":77,"line":104},3,[75,106,107],{"class":81},"metadata",[75,109,110],{"class":85},":\n",[75,112,114,117,119],{"class":77,"line":113},4,[75,115,116],{"class":81},"  name",[75,118,86],{"class":85},[75,120,121],{"class":89}," production\n",[75,123,125,128],{"class":77,"line":124},5,[75,126,127],{"class":81},"  labels",[75,129,110],{"class":85},[75,131,133,136,138],{"class":77,"line":132},6,[75,134,135],{"class":81},"    pod-security.kubernetes.io\u002Fenforce",[75,137,86],{"class":85},[75,139,140],{"class":89}," restricted\n",[75,142,144,147,149],{"class":77,"line":143},7,[75,145,146],{"class":81},"    pod-security.kubernetes.io\u002Fenforce-version",[75,148,86],{"class":85},[75,150,151],{"class":89}," v1.37\n",[11,153,154,155,158,159,164,165,170],{},"Most PSA walkthroughs written for standard kubeadm clusters are built on this \"nothing happens unless you ask\" assumption. ",[60,156,157],{},"K3s is different."," ",[15,160,163],{"href":161,"rel":162},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fhardening-guide",[19],"K3s's official CIS hardening guide"," states plainly that K3s ships with no pod security or network policies by default — and it's precisely the components K3s bundles on top of that default-open posture that create the trap described below. Chasing down this kind of configuration gap on your own, release after release, is exactly the kind of operational overhead that makes a managed K3s service like ",[15,166,169],{"href":167,"rel":168},"https:\u002F\u002Fkubo.hexabase.io\u002F",[19],"Kubo"," worth considering.",[23,172,174],{"id":173},"_2-following-the-standard-kubernetes-steps-restricted-killed-k3ss-servicelb","2. Following the Standard Kubernetes Steps, Restricted Killed K3s's ServiceLB",[11,176,177],{},[30,178],{"alt":179,"src":180},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection02.webp",[11,182,183,184,187,188,191,192,195,196,201],{},"The typical incident plays out like this: to satisfy a CIS benchmark requirement, a team applies ",[72,185,186],{},"restricted"," cluster-wide on K3s, following the official kubernetes.io steps and running ",[72,189,190],{},"kubectl label"," across every namespace. Even at the baseline level, hostPath volumes are already forbidden — ",[72,193,194],{},"spec.volumes[*].hostPath"," must be undefined (",[15,197,200],{"href":198,"rel":199},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Fpod-security-standards\u002F",[19],"official Pod Security Standards documentation",") — and restricted tightens this further.",[11,203,204,205,208,209,214],{},"Immediately after, LoadBalancer-type Services across the cluster start losing their external IPs one by one. Tracing the cause leads to K3s's bundled load balancer, ServiceLB: its ",[72,206,207],{},"svclb-*"," pods can no longer be created. ServiceLB works by scheduling a dedicated pod per Service that binds the host port directly (",[15,210,213],{"href":211,"rel":212},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fnetworking-services",[19],"K3s's official networking documentation",") — a mechanism that collides head-on with what restricted allows.",[11,216,217,218,221],{},"On a standard Kubernetes cluster, the external load balancer is typically delegated to the cloud provider, so no pod like this exists inside the cluster at all. In other words, ",[60,219,220],{},"something that's a non-issue on standard Kubernetes becomes a critical outage on K3s"," — and ServiceLB is the textbook example.",[23,223,225],{"id":224},"_3-the-root-cause-servicelb-needs-net_admin-and-unsafe-sysctls","3. The Root Cause: ServiceLB Needs NET_ADMIN and Unsafe Sysctls",[11,227,228],{},[30,229],{"alt":230,"src":231},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection03.webp",[11,233,234,237],{},[15,235,163],{"href":161,"rel":236},[19]," spells out three policy examples needed before enabling restricted:",[239,240,241,248,254],"ul",{},[242,243,244,247],"li",{},[60,245,246],{},"restricted-psp",": the standard restrictive policy",[242,249,250,253],{},[60,251,252],{},"system-unrestricted-psp",": a relaxed policy for system pods running in kube-system",[242,255,256,259],{},[60,257,258],{},"svclb-psp",": dedicated to ServiceLB, explicitly permitting:",[65,261,263],{"className":67,"code":262,"language":69,"meta":70,"style":70},"allowedCapabilities:\n  - NET_ADMIN\nallowedUnsafeSysctls:\n  - net.ipv4.ip_forward\n  - net.ipv6.conf.all.forwarding\n",[72,264,265,272,281,288,295],{"__ignoreMap":70},[75,266,267,270],{"class":77,"line":78},[75,268,269],{"class":81},"allowedCapabilities",[75,271,110],{"class":85},[75,273,274,278],{"class":77,"line":93},[75,275,277],{"class":276},"sgJMe","  -",[75,279,280],{"class":89}," NET_ADMIN\n",[75,282,283,286],{"class":77,"line":104},[75,284,285],{"class":81},"allowedUnsafeSysctls",[75,287,110],{"class":85},[75,289,290,292],{"class":77,"line":113},[75,291,277],{"class":276},[75,293,294],{"class":89}," net.ipv4.ip_forward\n",[75,296,297,299],{"class":77,"line":124},[75,298,277],{"class":276},[75,300,301],{"class":89}," net.ipv6.conf.all.forwarding\n",[11,303,304,305,308],{},"Because ServiceLB binds ports directly and manages IP forwarding, it needs the ",[72,306,307],{},"NET_ADMIN"," capability and specific unsafe sysctls — both of which restricted forbids by default. Without an explicit exception, pod creation is rejected outright.",[11,310,311,312,158,314,317,318,322],{},"What matters here is that ",[72,313,258],{},[60,315,316],{},"only appears in K3s's own documentation."," No amount of reading generic Pod Security Admission explainers, or CIS benchmark guides written for standard Kubernetes, will mention ServiceLB. When evaluating K3s as a managed K8s option, assuming \"standard Kubernetes knowledge is enough\" is exactly what causes this kind of bundled-component exception to go unnoticed. A service built on a ",[15,319,321],{"href":167,"rel":320},[19],"Kubo Cloud","-style Pure Kubernetes configuration has room to ship with these known gaps already accounted for.",[23,324,326],{"id":325},"_4-another-easy-to-miss-gap-in-k3ss-psa-rollout","4. Another Easy-to-Miss Gap in K3s's PSA Rollout",[11,328,329],{},[30,330],{"alt":331,"src":332},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection04.webp",[11,334,335],{},"ServiceLB isn't the only K3s-bundled component worth watching when rolling out PSA.",[11,337,338,339,342,343,346,347,352],{},"K3s's default storage class, ",[72,340,341],{},"local-path-provisioner",", provisions PVCs internally using a helper pod that relies on hostPath. Since application pods never mount a hostPath volume themselves, this doesn't typically trigger restricted-policy violations for app workloads directly. Still, misconfiguration here carries real risk: a vulnerability (CVE-2026-44543) was reported in which a user with write access to the ",[72,344,345],{},"local-path-config"," ConfigMap could manipulate the helper pod template to inject a privileged container or hostPath mount, and it was fixed in version 0.0.36 (",[15,348,351],{"href":349,"rel":350},"https:\u002F\u002Fosv.dev\u002Fvulnerability\u002FGHSA-7fxv-8wr2-mfc4",[19],"OSV.dev vulnerability database","). Running restricted PSA properly also narrows this kind of misconfiguration-driven attack path.",[11,354,355,356,361,362,365],{},"Separately, common monitoring DaemonSets like node-exporter need hostNetwork and hostPath to collect host-level metrics, making them non-compliant with both baseline and restricted (",[15,357,360],{"href":358,"rel":359},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-07-31-containerized-node-exporter-host-metrics\u002Fview",[19],"OneUptime's technical writeup","). This isn't K3s-specific — it happens on standard Kubernetes too — but it's worth inventorying alongside ServiceLB ",[60,363,364],{},"before"," flipping an entire K3s cluster to restricted.",[23,367,369],{"id":368},"_5-a-k3s-checklist-for-rolling-out-pod-security-admission-safely","5. A K3s Checklist for Rolling Out Pod Security Admission Safely",[11,371,372],{},[30,373],{"alt":374,"src":375},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Fsection05.webp",[11,377,378],{},"To introduce PSA safely on a K3s cluster:",[380,381,382,400,409,415,421],"ol",{},[242,383,384,387,388,391,392,394,395,399],{},[60,385,386],{},"On v1.25+, prepare a PSA configuration file",": point ",[72,389,390],{},"--kube-apiserver-arg=\"admission-control-config-file=...\""," at an AdmissionConfiguration that already includes a ",[72,393,258],{},"-equivalent exception (",[15,396,398],{"href":161,"rel":397},[19],"K3s's official hardening guide",")",[242,401,402,405,406,399],{},[60,403,404],{},"Don't jump straight to enforce",": apply warn and audit modes cluster-wide first and identify which workloads violate the policy (",[15,407,40],{"href":17,"rel":408},[19],[242,410,411,414],{},[60,412,413],{},"Treat kube-system and ServiceLB-related namespaces separately",": design exceptions for namespaces running system components instead of applying one blanket label",[242,416,417,420],{},[60,418,419],{},"Inventory hostPath\u002FhostNetwork-dependent components",": list out local-path-provisioner's helper pods, monitoring agents, and similar workloads ahead of time",[242,422,423,426],{},[60,424,425],{},"Roll out enforce gradually",": switch namespaces to enforce one at a time, starting with those that already show zero violations",[11,428,429,430,433],{},"Building this process from scratch every time, and tracking how the exception policy needs to shift with each K3s upgrade, is a non-trivial amount of ongoing operational work. A K3s-based managed service like ",[15,431,169],{"href":167,"rel":432},[19]," has room to ship a configuration that already accounts for these known gaps.",[23,435,437],{"id":436},"_6-conclusion-standard-kubernetes-knowledge-isnt-enough-on-its-own","6. Conclusion — \"Standard Kubernetes Knowledge\" Isn't Enough on Its Own",[11,439,440],{},"K3s is a CNCF-certified lightweight Kubernetes distribution that's highly compatible with standard Kubernetes at the API level. But bundled components like ServiceLB operate on fundamentally different assumptions than the cloud-dependent load balancer setup standard Kubernetes relies on. Even rolling out a \"standard Kubernetes feature\" like Pod Security Admission can trigger an outage because of this architectural gap.",[11,442,443],{},"When evaluating K3s against standard Kubernetes, it's worth going beyond feature lists and benchmark numbers to ask specifically how bundled components interact with your security policy.",[11,445,446,447,450],{},"If you'd rather hand off the ongoing work of auditing security settings and maintaining exception policies, ",[15,448,321],{"href":167,"rel":449},[19],"'s Pure Kubernetes configuration with AI-Driven Deployment is one option — you get a genuine, production-grade Kubernetes built on K3s without the cost and complexity of EKS or AKS.",[11,452,453,454,459],{},"For organizations in finance or healthcare that need data sovereignty or air-gapped environments, ",[15,455,458],{"href":456,"rel":457},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[19],"Kubo On-Premise"," offers a hardened configuration that stays entirely within your own infrastructure. Before building out CIS benchmark compliance and PSA exception policies from scratch, it's worth weighing these options first.",[11,461,462,463,468],{},"If you're actively reviewing your security posture or considering a move to K3s, feel free to ",[15,464,467],{"href":465,"rel":466},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[19],"get in touch",".",[470,471,472],"style",{},"html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html pre.shiki code .sgJMe, html code.shiki .sgJMe{--shiki-default:#9ABDF5}",{"title":70,"searchDepth":93,"depth":93,"links":474},[475,476,477,478,479,480],{"id":25,"depth":93,"text":26},{"id":173,"depth":93,"text":174},{"id":224,"depth":93,"text":225},{"id":325,"depth":93,"text":326},{"id":368,"depth":93,"text":369},{"id":436,"depth":93,"text":437},"2026-10-16","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.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage\u002Ftitle.webp","en",{},true,"\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage",{"title":5,"description":482},"blog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage",[492,493,494,495,496,497],"k3s","kubernetes","pod-security-admission","pod-security-standards","servicelb","security","nTp0FwnlC626Nd8uDzc5uCILoO8jvRzk3CCb2sZ-aKM",[500,509,518,527,535,541],{"path":501,"title":502,"description":503,"date":504,"tags":505},"\u002Fblog\u002Fen\u002Fk3s-cert-manager-servicelb-http01-challenge-renewal-failure","K3s Wouldn't Renew Its cert-manager Certificate. ServiceLB Was Stealing the HTTP-01 Challenge","cert-manager certificates on K3s stopped renewing, and neither Traefik nor cert-manager itself was the cause — ServiceLB was occupying ports 80\u002F443. Here's how the HTTP-01 challenge silently fails, and how to fix it for good.","2026-09-25",[492,493,506,496,507,508],"cert-manager","tls","lets-encrypt",{"path":510,"title":511,"description":512,"date":513,"tags":514},"\u002Fblog\u002Fen\u002Fk3s-networkpolicy-dual-stack-kube-router-ipv6-gap","\"K3s Ignores NetworkPolicy\" Was a Myth. Traffic Still Leaked Through — the ServiceLB Blind Spot","K3s enforces NetworkPolicy by default via its built-in kube-router controller. Yet traffic via LoadBalancer still leaked through — the cause was ServiceLB's implementation combined with a permanent limitation of the NetworkPolicy API. Here's how to detect and fix it.","2026-09-24",[492,493,515,496,516,517],"networkpolicy","kube-router","network-security",{"path":519,"title":520,"description":521,"date":522,"tags":523},"\u002Fblog\u002Fen\u002Fk3s-traefik-servicelb-ingress-nginx-port-conflict","You Disabled Traefik on K3s, But ingress-nginx Still Can't Grab Port 443. Meet ServiceLB, the Roommate You Forgot About","You ran the K3s disable-traefik flag but ingress-nginx still can't bind port 443. The culprit is ServiceLB (klipper-lb), another default K3s component. Here's how to diagnose it, disable it correctly, and what changes if you're running MetalLB.","2026-09-19",[492,493,524,496,525,526],"traefik","ingress-nginx","load-balancer",{"path":528,"title":529,"description":530,"date":531,"tags":532},"\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",[492,493,533,497,534],"zero-trust","rancher",{"path":536,"title":537,"description":538,"date":539,"tags":540},"\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",[492,493,506,507,497],{"path":542,"title":543,"description":544,"date":545,"tags":546},"\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",[492,493,547,548,497],"kata-containers","ai-agent",1792592638706]