Configure a Security Context for a Pod or Container

    • Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID).

    • : Objects are assigned security labels.

    • Running as privileged or unprivileged.

    • Linux Capabilities: Give a process some privileges, but not all the privileges of the root user.

    • : Use program profiles to restrict the capabilities of individual programs.

    • 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 flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has CAP_SYS_ADMIN.

    For more information about security mechanisms in Linux, see Overview of Linux Kernel Security Features

    You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using , or you can use one of these Kubernetes playgrounds:

    To check the version, enter kubectl version.

    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 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.

    Create the Pod:

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

    Verify that the Pod’s Container is running:

    1. kubectl get pod security-context-demo

    Get a shell to the running Container:

    1. kubectl exec -it security-context-demo -- sh

    In your shell, list the running processes:

    1. ps

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

    1. PID   USER     TIME  COMMAND
    2.     1 1000      0:00 sleep 1h
    3.     6 1000      0:00 sh
    4. ...

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

    1. cd /data
    2. ls -l

    The output shows that the /data/demo directory has group ID 2000, which is the value of fsGroup.

    1. drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo
    1. cd demo
    2. echo hello > testfile

    List the file in the /data/demo directory:

    1. ls -l

    The output shows that testfile has group ID 2000, which is the value of fsGroup.

    1. -rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile

    Run the following command:

    1. $ id
    2. uid=1000 gid=3000 groups=2000

    You will see that gid is 3000 which is same as runAsGroup field. If the runAsGroup was omitted the gid would remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have the required group permissions for root(0) group.

    Exit your shell:

    Set the security context for a Container

    To specify security settings for a Container, include the securityContext field in the Container manifest. The securityContext field is a object. Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap. Container settings do not affect the Pod’s Volumes.

    Here is the configuration file for a Pod that has one Container. Both the Pod and the Container have a securityContext field:

    Create the Pod:

    1. kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml

    Verify that the Pod’s Container is running:

    1. kubectl get pod security-context-demo-2

    Get a shell into the running Container:

    1. kubectl exec -it security-context-demo-2 -- sh

    In your shell, list the running processes:

    1. ps aux

    The output shows that the processes are running as user 2000. This is the value of runAsUser specified for the Container. It overrides the value 1000 that is specified for the Pod.

    1. USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    2. 2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
    3. 2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js
    4. ...

    Exit your shell:

    1. exit

    With Linux capabilities, you can grant certain privileges to a process without granting all the privileges of the root user. To add or remove Linux capabilities for a Container, include the capabilities field in the securityContext section of the Container manifest.

    First, see what happens when you don’t include a capabilities field. Here is configuration file that does not add or remove any Container capabilities:

    Create the Pod:

    1. kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml

    Verify that the Pod’s Container is running:

    1. kubectl get pod security-context-demo-3

    Get a shell into the running Container:

    1. kubectl exec -it security-context-demo-3 -- sh

    In your shell, list the running processes:

    1. USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
    2. root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
    3. root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js

    In your shell, view the status for process 1:

    1. cd /proc/1

    The output shows the capabilities bitmap for the process:

    1. ...
    2. CapPrm:    00000000a80425fb
    4. ...

    Make a note of the capabilities bitmap, and then exit your shell:

    1. exit

    Next, run a Container that is the same as the preceding container, except that it has additional capabilities set.

    Here is the configuration file for a Pod that runs one Container. The configuration adds the CAP_NET_ADMIN and CAP_SYS_TIME capabilities:

    Create the Pod:

    1. kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml

    Get a shell into the running Container:

    1. kubectl exec -it security-context-demo-4 -- sh

    In your shell, view the capabilities for process 1:

    1. cd /proc/1
    2. cat status

    The output shows capabilities bitmap for the process:

    1. ...
    2. CapPrm:    00000000aa0435fb
    3. CapEff:    00000000aa0435fb
    4. ...

    Compare the capabilities of the two Containers:

    1. 00000000a80425fb
    2. 00000000aa0435fb

    In the capability bitmap of the first container, bits 12 and 25 are clear. In the second container, bits 12 and 25 are set. Bit 12 is CAP_NET_ADMIN, and bit 25 is CAP_SYS_TIME. See for definitions of the capability constants.

    Assign SELinux labels to a Container

    To assign SELinux labels to a Container, include the seLinuxOptions field in the securityContext section of your Pod or Container manifest. The seLinuxOptions field is an object. Here’s an example that applies an SELinux level:

    1. ...
    2. securityContext:
    3.   seLinuxOptions:
    4.     level: "s0:c123,c456"

    Discussion

    The security context for a Pod applies to the Pod’s Containers and also to the Pod’s Volumes when applicable. Specifically fsGroup and seLinuxOptions are applied to Volumes as follows:

    • fsGroup: Volumes that support ownership management are modified to be owned and writable by the GID specified in fsGroup. See the for more details.

    • seLinuxOptions: Volumes that support SELinux labeling are relabeled to be accessible by the label specified under seLinuxOptions. Usually you only need to set the section. This sets the Multi-Category Security (MCS) label given to all Containers in the Pod as well as the Volumes.

    Delete the Pod:

    What’s next

    Feedback

    Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on . Open an issue in the GitHub repo if you want to report a problem or .