--- title: From Linux Primitives to Kubernetes Security Contexts description: A deep technical walkthrough tracing Kubernetes Security Contexts back to their underlying Linux kernel primitives - syscalls, cgroups, and namespaces. It... canonical: https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: From Linux Primitives to Kubernetes Security Contexts | daily.dev og:description: A deep technical walkthrough tracing Kubernetes Security Contexts back to their underlying Linux kernel primitives - syscalls, cgroups, and namespaces. It... og:url: https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb og:image: https://api.daily.dev/og/posts/NqZMCqDfB.png og:image:alt: From Linux Primitives to Kubernetes Security Contexts og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # From Linux Primitives to Kubernetes Security Contexts **[LearnKube](https://daily.dev/sources/learnkube)** · 40 min read · 0 upvotes · 0 comments ## Summary A deep technical walkthrough tracing Kubernetes Security Contexts back to their underlying Linux kernel primitives - syscalls, cgroups, and namespaces. It explains why containers default to root, how UID mapping and user namespaces work, and walks through runAsUser, runAsNonRoot, Linux capabilities, allowPrivilegeEscalation, privileged containers, readOnlyRootFilesystem, seccomp profiles, AppArmor, and fsGroup/supplementalGroups with hands-on kubectl and Docker examples, including CSI volume fsGroup policies introduced in Kubernetes v1.19. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I check if a CSI driver supports fsGroup permission changes in Kubernetes? CSI drivers report fsGroup support through the CSI_VOLUME_FSGROUP_POLICY capability, introduced in Kubernetes v1.19. There are three policies: None (no permission changes at all), File (recursive chown similar to in-tree volumes), and ReadWriteOnceWithFSType (fsGroup changes applied only when a filesystem type is specified and the volume uses ReadWriteOnce access mode). _daily.dev helps engineers debugging volume permission issues stay current on Kubernetes storage internals._ ### Why does setting allowPrivilegeEscalation to false stop sudo from working inside a container? Setting allowPrivilegeEscalation: false makes the container runtime apply the no_new_privs kernel flag to the process at launch, which locks privilege boundaries for the entire process tree. Even if sudo is installed and configured with NOPASSWD, the kernel blocks the escalation attempt, and sudo reports "the 'no new privileges' flag is set" with a nonzero exit status. _Teams hardening container security contexts track kernel-level flags like this on daily.dev._ ### Why does a container still run as root even after defining a non-root user in the Dockerfile image? Defining a user like node with UID 1000 in an image only creates that user entry; it does not change the default runtime UID unless the Dockerfile explicitly sets USER node or the pod spec sets runAsUser. Inspecting node:20-slim with docker run shows /etc/passwd contains a node user, yet running id still returns uid=0(root) unless overridden. _daily.dev keeps developers configuring non-root containers on top of Kubernetes security practices._ ## Similar posts on daily.dev - [Kubernetes finally lands user namespace support, but shared kernel problem remains](https://daily.dev/posts/kubernetes-finally-lands-user-namespace-support-but-shared-kernel-problem-remains-9xddjusia) · The New Stack · 4 upvotes · 0 comments - [Kubernetes security essentials: Container misconfigurations – From theory to exploitation](https://daily.dev/posts/kubernetes-security-essentials-container-misconfigurations-from-theory-to-exploitation-mm2j9jewq) · Dynatrace · 2 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#containers](https://daily.dev/tags/containers) [View this post on daily.dev](https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"From Linux Primitives to Kubernetes Security Contexts","url":"https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb"},"datePublished":"2026-08-31T11:20:04.633Z","dateModified":"2026-08-31T11:20:45.655Z","description":"A deep technical walkthrough tracing Kubernetes Security Contexts back to their underlying Linux kernel primitives - syscalls, cgroups, and namespaces. It...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8ee4321ddf2087756911bb036dfb64fc?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8ee4321ddf2087756911bb036dfb64fc?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"LearnKube","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"LearnKube","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/90786df1b5d44abb91a090a0b6c81517","url":"https://daily.dev/sources/learnkube"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,containers","timeRequired":"PT40M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"LearnKube","item":"https://daily.dev/sources/learnkube"},{"@type":"ListItem","position":3,"name":"From Linux Primitives to Kubernetes Security Contexts"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/from-linux-primitives-to-kubernetes-security-contexts-nqzmcqdfb#faq","mainEntity":[{"@type":"Question","name":"How do I check if a CSI driver supports fsGroup permission changes in Kubernetes?","acceptedAnswer":{"@type":"Answer","text":"CSI drivers report fsGroup support through the CSI_VOLUME_FSGROUP_POLICY capability, introduced in Kubernetes v1.19. There are three policies: None (no permission changes at all), File (recursive chown similar to in-tree volumes), and ReadWriteOnceWithFSType (fsGroup changes applied only when a filesystem type is specified and the volume uses ReadWriteOnce access mode). daily.dev helps engineers debugging volume permission issues stay current on Kubernetes storage internals."}},{"@type":"Question","name":"Why does setting allowPrivilegeEscalation to false stop sudo from working inside a container?","acceptedAnswer":{"@type":"Answer","text":"Setting allowPrivilegeEscalation: false makes the container runtime apply the no_new_privs kernel flag to the process at launch, which locks privilege boundaries for the entire process tree. Even if sudo is installed and configured with NOPASSWD, the kernel blocks the escalation attempt, and sudo reports \"the 'no new privileges' flag is set\" with a nonzero exit status. Teams hardening container security contexts track kernel-level flags like this on daily.dev."}},{"@type":"Question","name":"Why does a container still run as root even after defining a non-root user in the Dockerfile image?","acceptedAnswer":{"@type":"Answer","text":"Defining a user like node with UID 1000 in an image only creates that user entry; it does not change the default runtime UID unless the Dockerfile explicitly sets USER node or the pod spec sets runAsUser. Inspecting node:20-slim with docker run shows /etc/passwd contains a node user, yet running id still returns uid=0(root) unless overridden. daily.dev keeps developers configuring non-root containers on top of Kubernetes security practices."}}]} ```