Kubernetes provides powerful mechanisms for controlling how containers run on a node. One of the most important of these mechanisms is the Security Context.
Security Contexts allow operators to define security-related settings for pods and containers, such as the user a process runs as, whether privilege escalation is allowed, or which Linux capabilities are available.
While Kubernetes can run workloads with very few restrictions, production environments often benefit from additional hardening measures that reduce the impact of application vulnerabilities and misconfigurations.
Security Contexts are an important building block of a defense-in-depth and Zero Trust security strategy.
For a broader overview, see Zero Trust in Kubernetes.
Containers are not virtual machines. Although they provide isolation, they still share the underlying Linux kernel with other workloads running on the same node.
A compromised container with excessive privileges may be able to access sensitive data, interfere with other workloads, or exploit vulnerabilities in the host operating system.
Security Contexts help reduce this risk by limiting what applications are allowed to do.
Common examples include:
These controls do not replace secure application development, but they can significantly reduce the blast radius of a security incident.
Security Contexts can be configured at both the pod and container level.
A typical hardened workload might look similar to the following:
This configuration prevents the container from running as root, disables privilege escalation, mounts the root filesystem as read-only, and removes all Linux capabilities.
While not every workload can operate with these restrictions, they are a useful starting point when hardening applications.
One of the most common Kubernetes security recommendations is to avoid running containers as the root user whenever possible.
Many modern container images already support non-root execution and can operate without elevated privileges.
For example:
This ensures Kubernetes refuses to start the container if it attempts to run as root.
Running workloads as a non-root user helps limit the impact of application vulnerabilities and reduces the likelihood of accidental access to sensitive system resources.
Running containers as a non-root user is an important security measure, but it does not completely isolate container users from the host operating system.
User namespaces provide an additional layer of isolation by mapping container user IDs to different user IDs on the host. For example, a process running as UID 0 (root) inside a container can be mapped to an unprivileged user ID outside the container.
This reduces the impact of container escape vulnerabilities and helps limit the damage that could occur if a workload is compromised.
User namespaces are configured at the pod level:
When hostUsers: false is specified, Kubernetes creates a separate user namespace for the pod and maps container users to a distinct range of host user IDs.
User namespaces complement Security Contexts but do not replace them. Even when user namespaces are enabled, running workloads as non-root users and following least-privilege principles remains a recommended best practice.
For more information, refer to the Kubernetes documentation.
Privilege escalation occurs when a process gains permissions beyond those originally assigned to it.
Most applications do not require this capability.
Disabling privilege escalation is often a simple and effective hardening measure:
This prevents processes from acquiring additional privileges during runtime.
Linux capabilities provide fine-grained control over privileged operations.
Many containerized applications do not require any additional capabilities beyond those provided by default.
A common hardening pattern is to drop all capabilities and only add back those that are explicitly required:
This approach follows the principle of least privilege and reduces the attack surface available to an attacker.
Many applications only need write access to specific mounted volumes.
When possible, configuring a read-only root filesystem prevents applications from modifying files inside the container image at runtime.
This can help prevent certain classes of attacks and make unauthorized modifications easier to detect.
Security Contexts allow you to harden individual workloads, but managing security settings across hundreds of deployments can quickly become difficult.
For example, an organization may want to ensure that no application is allowed to run as a privileged container, use host networking, or run as the root user. Enforcing these requirements manually across every deployment is error-prone and difficult to audit.
To address this, Kubernetes provides Pod Security Standards (PSS), a set of predefined security profiles that define what workloads are allowed to do within a namespace.
The three Pod Security Standards are:
For many production workloads, the Restricted profile is a good security target.
Additional information is available in the official Kubernetes documentation.
Security Contexts are frequently used as part of compliance programs and security frameworks.
Many organizations use them to demonstrate that workloads follow least-privilege principles and that unnecessary privileges are not granted by default.
They are particularly common in environments subject to:
The exact requirements vary between organizations, but Security Contexts are often one of the easiest hardening measures to adopt.
Security Contexts complement other Kubernetes security controls such as RBAC, Network Policies, mTLS, and audit logging.
While those controls focus on authentication, authorization, encryption, and network access, Security Contexts focus on restricting what workloads can do after they start running.
Together, these controls create multiple layers of defense that help reduce risk throughout the platform.
Syself Autopilot provides a secure Kubernetes foundation, but application-level security remains the responsibility of the workloads deployed into the cluster.
Security Contexts are typically configured by application operators as part of their deployment manifests.
Before enforcing restrictive policies across production environments, organizations should validate that their workloads are compatible with the chosen security settings.
Hardening Kubernetes workloads often requires balancing security requirements with application compatibility.
The Syself team can help review deployments, identify unnecessary privileges, define security baselines, and design workload hardening strategies for production environments.
If you would like assistance improving the security posture of your Kubernetes applications, contact the Syself team.