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
v1.5-v1.15
extensions/v1beta1
v1.10+
policy/v1beta1
v1.21
deprecated
Supported Controls
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
最后更新于