Default Pod security policies in MKE¶

By default, the two Pod security policies defined within MKE are privileged and unprivileged. Additionally, to ensure backward compatibility after an upgrade, there is a ClusterRoleBinding that gives every user access to the privileged policy. By default, any user can create any Pod.

Note

PSPs do not override security defaults built into the MKE RBAC engine for Kubernetes Pods. These security defaults prevent non-admin users from mounting host paths into Pods or starting privileged Pods.

To review the default PSPs:

kubectl get podsecuritypolicies

Expected output:

NAME           PRIV    CAPS   SELINUX    RUNASUSER   FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
privileged     true    *      RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *
unprivileged   false          RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *

The following specification is for the privileged policy:

allowPrivilegeEscalation: true
allowedCapabilities:
- '*'
fsGroup:
  rule: RunAsAny
hostIPC: true
hostNetwork: true
hostPID: true
hostPorts:
- max: 65535
  min: 0
privileged: true
runAsUser:
  rule: RunAsAny
seLinux:
  rule: RunAsAny
supplementalGroups:
  rule: RunAsAny
volumes:
- '*'

The following specification is for the unprivileged policy:

allowPrivilegeEscalation: false
allowedHostPaths:
- pathPrefix: /dev/null
  readOnly: true
fsGroup:
  rule: RunAsAny
hostPorts:
- max: 65535
  min: 0
runAsUser:
  rule: RunAsAny
seLinux:
  rule: RunAsAny
supplementalGroups:
  rule: RunAsAny
volumes:
- '*'

The privileged options include pods with any of the following defined in the PodTemplate:

Privileged option	Description
`PodSpec.hostIPC`	Prevents users from deploying a pod in the host IPC namespace.
`PodSpec.hostNetwork`	Prevents users from deploying a pod in the host network namespace.
`PodSpec.hostPID`	Prevents users from deploying a pod in the host PID namespace.
`SecurityContext.allowPrivilegeEscalation`	Prevents a child process of a container from gaining more privileges than its parent.
`SecurityContext.capabilities`	Prevents users from adding Linux capabilities to a pod.
`SecurityContext.privileged`	Prevents users from deploying a privileged container.
`Volume.hostPath`	Prevents users from mounting a path from the host into the container. This can be a file, directory, or the Docker socket.

The privileged options also include persistent volumes that use the following storage class:

StorageClass	Description
`Local`	Prevents users from creating a persistent volume with the `Local` StorageClass. The `Local` `StorageClass` allows users to mount directories from the host into a pod. This could be a file, directory, or the Docker socket.

Note

If an administrator creates a persistent volume with the Local` ``StorageClass, a non-administrator can consume this with a persistent volume claim.

If a user without a cluster-admin role tries to deploy a pod with any of these privileged options, an error similar to the following example displays:

Error from server (Forbidden): error when creating "pod.yaml":
pods "mypod" is forbidden: user "<user-id>" is not an admin
and does not have permissions to use privileged mode for
resource

Granting the cluster-admin ClusterRole to normal users does not allow them to deploy privileged pods.