Understanding Kubernetes Security Context

Kubernetes Security Contexts allows you to control the security-related settings of your pods and containers — like which user they run as, what system privileges they have, and how they interact with the underlying host system.

We generally concentrate on creating scalable, highly available systems while deploying apps on Kubernetes. However, security is also important, particularly security within the pods themselves.

In Kubernetes, external security only goes so far. The real battle for safety is fought inside your pods and containers.

Locking down what occurs inside your containers is also necessary.
That’s where Security Contexts come into play.

Security Contexts in Kubernetes allow us to control the security-related settings of your pods and containers, like which user they run as, what system privileges they have, and how they interact with the underlying host system.

When properly implemented, Security Contexts serve as the first line of security against the attacks at the container level.

In this blog, we’ll walk through everything you need to know about Kubernetes Security Contexts.

What does a Kubernetes security context mean?

To put it simply, a Security Context specifies the access control and privileges a Container or Pod has. It enables you to define the following parameters for how a container or pod should operate:

• User and group IDs
• Privilege escalation permissions
• Read-only root file systems
• Linux capabilities
• Seccomp profiles and more

There are 2 types of security Contexts and it can be applied at both the Pod level and the Container level:

• Pod-level Security Context applies default settings for all containers in the Pod.
• Container-level Security Context allows fine-grained control per container and help in defining the permissions on the container-level

What Makes Security Context Crucial?

Without a security context that is set up correctly:

• If the pod is compromised, it could be problematic because containers may operate as the root user inside the container.
• Privilege escalation attacks could result from containers obtaining unwanted Linux capabilities.
• If the file system is writable, application files might have been accidentally altered.

In short: a badly configured security context can become the weakest link in your cluster’s security.

Key Fields in Security Context

Here are some critical fields you’ll frequently encounter:

Example 1: A Basic Security Context at Container Level

apiVersion: v1
kind: Pod
metadata:
  name: nginx-app
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      runAsNonRoot: true
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false

Here:

• The container runs as a non-root user (UID 1000 and GID 3000).
• The container cannot escalate privileges.
• The root filesystem is read-only, preventing accidental/malicious writes.

Example 2: Pod-level Security Context

Instead of repeating the same security context for every container, you can set it at the Pod level:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-app
spec:
  securityContext:
    runAsUser: 2000
    fsGroup: 2000
  containers:
  - name: nginx
    image: nginx:alpine
    command: ["sleep", "3600"]

Here:

• The entire Pod’s processes will run with user ID 2000.
• Any volume mounted into the pod will have the group ownership set to fsGroup, ensuring proper access controls.

Use Case: Image User vs Security Context: What Happens?

Case Study: What Happens When an Image Defines a User but a Security Context Also Specifies One?

Sometimes, container images are built with a default user already set (using the USER directive in a Dockerfile). Additionally, Kubernetes allows you to define a SecurityContext using attributes such as runAsGroup and runAsUser.

What would happen if both were present?

• The user defined inside the image is overridden by Kubernetes if runAsUser is set in the SecurityContext.
• Kubernetes utilizes the user specified in the container image if runAsUser is not set.
• The container may operate as root if both are absent, which is dangerous unless purposefully created.

In short:
➡️ SecurityContext takes precedence over the image’s built-in user settings.

Best Practices for Using Security Context

1. Always set runAsNonRoot: true.
2. Set a specific non-root runAsUser and runAsGroup.
3. Enable readOnlyRootFilesystem wherever possible.
4. Drop all capabilities unless explicitly needed.
5. Use Seccomp profiles to restrict syscalls.
6. Use Pod Security Standards (PSPs or their replacement like PodSecurity admission) to enforce security context policies.

Pod Security Admission (PSA): Enforcing Security Contexts

Starting from Kubernetes v1.25, PodSecurityPolicies (PSPs) are deprecated. Instead, Pod Security Admission is now used to enforce security standards like:

• Privileged: Unrestricted.
• Baseline: Minimally restricted.
• Restricted: Heavily restricted (ideal for production).

If your cluster enforces the restricted profile, it will require settings like runAsNonRoot: true , no privilege escalation, and a read-only root filesystem — all things you configure through security contexts.

Conclusion

Configuring a proper Security Context is a must-have for every Kubernetes workload, not just a “nice to have.” 🙂

It’s simple to implement but can greatly increase the security posture of your applications.

Quick Summary

✅ Use runAsNonRoot, runAsUser, and runAsGroup
✅ Drop unneeded permissions
✅ Enable readOnlyRootFilesystem
✅ Apply Seccomp profiles
✅ Align with Pod Security Standards

Simran Gera

I’m a DevOps Engineer with 3 years of experience, passionate about building scalable and automated infrastructure. I write about Kubernetes, cloud automation, cost optimization, and DevOps tooling, aiming to simplify complex concepts with real-world insights. Outside of work, I enjoy exploring new DevOps tools, reading tech blogs, and play badminton.