SecurityContext

The primary goal of Security Context is to restrict the behavior of untrustworthy containers, shielding the system and other containers from their potential impact.

There are three methods provided by Kubernetes to configure Security Context:

  • Container-level Security Context: Applied solely to the specified container

  • Pod-level Security Context: Implemented on all containers and Volume within the Pod

  • Pod Security Policies (PSP): Applied across all Pods and Volumes within the cluster

The Nitty-Gritty of Container-level Security Context

Container-level Security Context only applies to the assigned container, impacting the Volume not. For instance, setting a container to run in privileged mode can be done like this:

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
spec:
  containers:
    - name: hello-world-container
      # The container definition
      # ...
      securityContext:
        privileged: true

Digging into Pod-level Security Context

Pod-level Security Context is applied to all containers inside a Pod, and it also influences the Volume, including fsGroup and selinuxOptions.

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
spec:
  containers:
  # specification of the pod's containers
  # ...
  securityContext:
    fsGroup: 1234
    supplementalGroups: [5678]
    seLinuxOptions:
      level: "s0:c123,c456"

Understanding Pod Security Policies (PSP)

Pod Security Policies (PSP) serve as cluster-level Pod security strategies, automatically setting the Security Context for Pods and Volumes within the cluster.

Operating PSP requires the API Server to enable extensions/v1beta1/podsecuritypolicy, and to configure the PodSecurityPolicy admission controller.

Note: Due to a lack of flexibility, an imperfect authentication model, and cumbersome configuration updates, PodSecurityPolicy was officially deprecated in v1.21 and will be removed from the codebase in v1.25. Users currently using PodSecurityPolicy are suggested to migrate to Open Policy Agent.

API Version Comparison Table

Kubernetes VersionExtension Version

v1.5-v1.15

extensions/v1beta1

v1.10+

policy/v1beta1

v1.21

deprecated

Supported Controls

ControlDescription

privileged

Operate privileged containers

defaultAddCapabilities

Capabilities that can be added to the container

requiredDropCapabilities

Capabilities that will be deleted from the container

allowedCapabilities

Allowed list of Capabilities

volumes

Control which volumes a container can use

hostNetwork

Allows the use of the host network

hostPorts

Allowed host port list

hostPID

Use the host PID namespace

hostIPC

Use the host IPC namespace

seLinux

SELinux Context

runAsUser

user ID

supplementalGroups

Allowed supplementary user group

fsGroup

volume FSGroup

readOnlyRootFilesystem

Read-only root file system

allowedHostPaths

Allowed list of paths for the hostPath plugin

allowedFlexVolumes

Allowed list of flexVolume plugins

allowPrivilegeEscalation

Allow container processes to set no_new_privs

defaultAllowPrivilegeEscalation

Default permission for privilege escalation

Example

To restrict a container's host port range to 8000-8080, you can do this:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: permissive
spec:
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  hostPorts:
  - min: 8000
    max: 8080
  volumes:
  - '*'

To allow only the use of lvm and cifs etc. flexVolume plugins:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: allow-flex-volumes
spec:
  fsGroup:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
    - flexVolume
  allowedFlexVolumes:
    - driver: example/lvm
    - driver: example/cifs

A Closer Look at SELinux

SELinux (Security-Enhanced Linux) is an implementation of mandatory access control. It operates under the principle of least privilege, using Linux Security Modules within the Linux kernel. Emmy award-winning SELinux was primarily developed by the United States National Security Agency, and was released to the open source developer community on December 22, 2000.

The security policy for processes can be set using runcon, while the - Z parameter in ls and ps can inspect the security policy applied to files or processes.

How to Enable or Disable SELinux?

You can edit the / etc/selinux/config file:

  • Enable: SELINUX=enforcing

  • Disable: SELINUX=disabled

Or use the command for temporary changes:

  • Enable: setenforce 1

  • Disable: setenforce 0

To check SELinux status:

$ getenforce

Example

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
spec:
  containers:
  - image: gcr.io/google_containers/busybox:1.24
    name: test-container
    command:
    - sleep
    - "6000"
    volumeMounts:
    - mountPath: /mounted_volume
      name: test-volume
  restartPolicy: Never
  hostPID: false
  hostIPC: false
  securityContext:
    seLinuxOptions:
      level: "s0:c2,c3"
  volumes:
  - name: test-volume
    emptyDir: {}

This generates the following HostConfig.Binds for the docker container:

/var/lib/kubelet/pods/f734678c-95de-11e6-89b0-42010a8c0002/volumes/kubernetes.io~empty-dir/test-volume:/mounted_volume:Z
/var/lib/kubelet/pods/f734678c-95de-11e6-89b0-42010a8c0002/volumes/kubernetes.io~secret/default-token-88xxa:/var/run/secrets/kubernetes.io/serviceaccount:ro,Z
/var/lib/kubelet/pods/f734678c-95de-11e6-89b0-42010a8c0002/etc-hosts:/etc/hosts

The appropriate Volume also has SELinux properly set:

$ ls -Z /var/lib/kubelet/pods/f734678c-95de-11e6-89b0-42010a8c0002/volumes
drwxr-xr-x. root root unconfined_u:object_r:svirt_sandbox_file_t:s0:c2,c3 kubernetes.io~empty-dir
drwxr-xr-x. root root unconfined_u:object_r:svirt_sandbox_file_t:s0:c2,c3 kubernetes.io~secret

Additional Reading

最后更新于