DevOps Glossary

Kubernetes SecurityContext is a Kubernetes setting that defines security-related runtime options for a Pod or container. In practical terms, it controls whether a workload runs as root, which Linux capabilities it gets, whether it can escalate privileges, which user ID it uses, and whether its filesystem should be read-only.

What Kubernetes SecurityContext does

A SecurityContext lets you reduce the privileges available to a workload at runtime. Platform and security teams use it to make containers safer by default, especially in shared clusters or production namespaces.

Common controls include:

• Run as a non-root user: Prevent a container process from running as UID 0.
• Set user and group IDs: Define runAsUser, runAsGroup, and fsGroup.
• Drop Linux capabilities: Remove privileges such as NET_RAW or all capabilities by default.
• Block privilege escalation: Set allowPrivilegeEscalation: false.
• Disable privileged mode: Avoid giving a container broad host-level access.
• Use a read-only root filesystem: Reduce the impact of file writes inside the container.
• Apply seccomp or SELinux settings: Limit the system calls or security labels available to the process.

How it works

You can define securityContext at two main levels:

• Pod-level securityContext: Applies settings that are shared by containers in the Pod, such as fsGroup, runAsUser, and runAsNonRoot.
• Container-level securityContext: Applies settings to a specific container, such as allowPrivilegeEscalation, capabilities, privileged, and readOnlyRootFilesystem.

Container-level settings can override Pod-level settings where both are supported. This matters for Pods with multiple containers, such as an app container plus a sidecar, where each container may need different permissions.

Simple example

This example runs a container as a non-root user, blocks privilege escalation, drops Linux capabilities, and makes the root filesystem read-only:

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001
  containers:
    - name: app
      image: example/app:1.0.0
      ports:
        - containerPort: 8080
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
        seccompProfile:
          type: RuntimeDefault

In a real service, this often means the application must listen on a non-privileged port such as 8080 instead of 80, and write temporary files to a mounted volume instead of the container root filesystem.

Common use cases

• Production workload hardening: Run APIs, workers, and internal services with the least privileges they need.
• Multi-tenant clusters: Reduce the risk that one team’s workload can affect other workloads or nodes.
• Compliance controls: Enforce non-root containers, blocked privilege escalation, and restricted capabilities.
• CI/CD standardization: Add security defaults to Helm charts, Kustomize overlays, or Terraform-managed manifests.
• Admission policy enforcement: Pair SecurityContext settings with Pod Security Admission, Kyverno, OPA Gatekeeper, or ValidatingAdmissionPolicy.

If your team manages Kubernetes manifests through infrastructure as code, SecurityContext settings should live beside the workload definition. For example, they can be included when you deploy Kubernetes resources using Terraform.

Important fields to know

runAsNonRoot

Requires the container to run as a non-root user. This is one of the most common baseline settings for application workloads.

runAsUser and runAsGroup

Set the Linux user ID and group ID for the container process. Use explicit numeric IDs where possible, such as 10001, instead of relying only on image defaults.

fsGroup

Sets a group ID for mounted volumes so the workload can read or write files as needed. This is useful for persistent volumes, but it can slow startup on large volumes because Kubernetes may need to adjust file ownership.

allowPrivilegeEscalation

Controls whether a process can gain more privileges than its parent process. For most application containers, set it to false.

privileged

Gives the container broad access to host devices and kernel features. Avoid it for application workloads. It is usually limited to low-level infrastructure components such as certain CNI, CSI, or node agents.

capabilities

Adds or drops Linux capabilities. A common secure default is to drop all capabilities and add back only what the container truly needs.

readOnlyRootFilesystem

Makes the container’s root filesystem read-only. This helps prevent unexpected writes, but your application may need writable mounts for paths like /tmp, cache directories, or log buffers.

seccompProfile

Applies a seccomp profile to restrict system calls. RuntimeDefault is a practical default for many workloads and uses the container runtime’s default seccomp profile.

SecurityContext vs Pod Security Admission

SecurityContext defines settings on an individual Pod or container. Pod Security Admission checks whether a Pod meets a security policy before Kubernetes accepts it.

For example, a namespace using the restricted Pod Security Standard may reject a Pod that runs as privileged or allows privilege escalation. The SecurityContext is where you set the values that help the Pod pass those checks.

SecurityContext vs RBAC

SecurityContext controls runtime privileges inside the container and at the node operating system level. RBAC controls what Kubernetes API actions an identity can perform, such as reading Secrets or creating Deployments.

You usually need both. A Pod can run as non-root and still have an over-permissive ServiceAccount. A Pod can also have minimal RBAC but still be risky if it runs as privileged.

Benefits

• Reduces blast radius: A compromised container has fewer permissions to abuse.
• Supports secure defaults: Platform teams can build safer base Helm charts, templates, and policy rules.
• Improves auditability: Security settings are visible in Kubernetes manifests and can be reviewed in pull requests.
• Works with policy tools: Admission controllers can require specific SecurityContext values before workloads run.

Tradeoffs and limitations

• Application compatibility can break: Some images assume they run as root or write to protected filesystem paths.
• Not every setting works on every OS: Linux-specific options do not apply the same way to Windows containers.
• It does not replace other controls: You still need RBAC, NetworkPolicies, image scanning, Secrets management, and node hardening.
• Some workloads need exceptions: Infrastructure components may require host access, extra capabilities, or privileged mode.

Practical guidance

• Set runAsNonRoot: true for normal application workloads.
• Use explicit non-root UIDs and GIDs, such as 10001.
• Set allowPrivilegeEscalation: false unless the workload has a clear need.
• Drop all Linux capabilities first, then add back only required capabilities.
• Use readOnlyRootFilesystem: true and mount writable paths where needed.
• Use seccompProfile.type: RuntimeDefault as a sensible default.
• Test changes in staging before enforcing them cluster-wide.

SecurityContext settings should also be reviewed during cluster maintenance. Kubernetes version changes, admission policy changes, and runtime updates can affect workload behavior, so include security settings in your upgrade checklist. This is especially useful when planning Kubernetes upgrades for startups where small teams own both delivery speed and production risk.

Real-world example

Suppose your team runs a web API on EKS. The container image originally runs as root, writes logs to /var/log/app, and listens on port 80. To harden it, you might:

1. Change the app to listen on port 8080.
2. Build the image with a non-root user, such as UID 10001.
3. Write logs to stdout instead of a protected file path.
4. Mount an emptyDir volume for temporary files if needed.
5. Add a SecurityContext that blocks privilege escalation and drops all capabilities.

The same approach applies to scheduled jobs, internal services, and stateful tools. For example, when you deploy Apache Airflow on AWS Elastic Kubernetes Service, SecurityContext settings can help separate what the scheduler, webserver, and workers are allowed to do at runtime.

Bottom line

Kubernetes SecurityContext is one of the main tools for applying least-privilege runtime settings to Pods and containers. It is simple to define in YAML, but it works best when your container images, volume mounts, application ports, and admission policies are designed with those restrictions in mind.