Pod Security Context: Set Security Rules for Pods
A Pod Security Context defines security settings for all containers in a Pod, like setting permissions for a user group before adding users. Use it to enforce non-root execution or manage shared volume permissions.
WHY IT EXISTS In a multi-container Pod, you often want to enforce the same security rules for all of them. Managing security settings on each container individually is repetitive and error-prone. A Pod Security Context provides a single place to define security policies that apply to the entire Pod, simplifying configuration and reducing the chance of a misconfigured, overly permissive container.
THE MENTAL MODEL Think of a Pod Security Context as the default user and group permissions for a new folder on a Linux system. Any file or sub-folder you create inside it will inherit those baseline permissions. Similarly, any container started within the Pod inherits the security settings defined in the PodSecurityContext, like which user ID to run as.
HOW IT WORKS You define a securityContext field within your Pod's specification. Inside this block, you can set various fields. For example, runAsUser and runAsGroup specify the user and group ID for all containers' processes. The fsGroup field is particularly useful: it sets a special group ID for any mounted volumes, ensuring all containers in the Pod can read and write to shared storage. The kubelet on the node reads these settings and applies them before starting the containers.
WHEN TO USE IT Use a Pod Security Context whenever you need to enforce a consistent security posture across all containers in a Pod. It's ideal for mandating that all processes run as a non-root user (e.g., runAsUser: 1001). It is also the standard way to manage permissions for shared volumes, using fsGroup to make the volume writable by all containers. You can also apply kernel-level security rules like seccomp profiles or SELinux options to the entire Pod.
WHEN NOT TO USE IT Don't rely on it if you need granular, per-container exceptions. If one container in a Pod needs a specific capability while others do not, you must define that in the individual container's securityContext. The Pod-level context is for establishing a baseline, not for managing exceptions. If every container needs a unique security configuration, a Pod-level context offers little benefit.
ONE CANONICAL EXAMPLE A common pattern is a web server Pod with a sidecar container for log shipping. Both need to access a shared log volume. By setting fsGroup in the PodSecurityContext, you ensure that the volume is owned by that group, and both the web server and the log shipper can access the files because they are both members of that supplementary group. This avoids complex permission handling inside the containers.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.