Configure a Security Context for a Pod or Container [page]deterministic

tasks

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to:

* Discretionary Access Control: Permission to access an object, like a file, is based on [user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).

* [Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux): Objects are assigned security labels.

* Running as privileged or unprivileged.

* [Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/): Give a process some privileges, but not all the privileges of the root user.

* [AppArmor](/docs/tutorials/security/apparmor/): Use program profiles to restrict the capabilities of individual programs.

* [Seccomp](/docs/tutorials/security/seccomp/): Filter a process's system calls.

* `allowPrivilegeEscalation`: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. `allowPrivilegeEscalation` is always true when the container:

is run as privileged, or - has `CAP_SYS_ADMIN`

* `readOnlyRootFilesystem`: Mounts the container's root filesystem as read-only.

The above bullets are not a complete set of security context settings -- please see [SecurityContext](/docs/reference/generated/kubernetes-api//#securitycontext-v1-core) for a comprehensive list.

## Set the security context for a Pod

To specify security settings for a Pod, include the `securityContext` field in the Pod specification. The `securityContext` field is a [PodSecurityContext](/docs/reference/generated/kubernetes-api//#podsecuritycontext-v1-core) object. The security settings that you specify for a Pod apply to all Containers in the Pod. Here is a configuration file for a Pod that has a `securityContext` and an `emptyDir` volume:

In the configuration file, the `runAsUser` field specifies that for any Containers in the Pod, all processes run with user ID 1000. The `runAsGroup` field specifies the primary group ID of 3000 for all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers will be root(0). Any files created will also be owned by user 1000 and group 3000 when `runAsGroup` is specified. Since `fsGroup` field is specified, all processes of the container are also part of the supplementary group ID 2000. The owner for volume `/data/demo` and any files created in that volume will be Group ID 2000. Additionally, when the `supplementalGroups` field is specified, all processes of the container are also part of the specified groups. If this field is omitted, it means empty.

Create the Pod:

```shell kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml ```

Verify that the Pod's Container is running:

```shell kubectl get pod security-context-demo ```

Get a shell to the running Container:

```shell kubectl exec -it security-context-demo -- sh ```

In your shell, list the running processes:

```shell ps ```

The output shows that the processes are running as user 1000, which is the value of `runAsUser`:

```none PID USER TIME COMMAND 1 1000 0:00 sleep 1h 6 1000 0:00 sh ... ```

In your shell, navigate to `/data`, and list the one directory:

```shell cd /data ls -l ```