This issue was reported in the Kubernetes Security Audit Report

Description
A PodSecurityPolicy allows a cluster administrator to specify what settings a given service account should be able to provide when creating a Pod on a cluster. If a cluster operator attempts to create a Pod with a setting not allowed by the PodSecurityPolicy associated to their account, the Pod will fail to create and return a validation error.

An attacker can bypass hostPath volume mount restrictions imposed by a PodSecurityPolicy by using the HostPath type of PersistentVolumes, and mounting the PersistentVolume through the use of a PersistentVolumeClaim. This allows the attacker access to any directory of the underlying Kubernetes node host.

As currently implemented, the PodSecurityPolicy is not granular enough to provide protections for PersistentVolumeClaim volumes. The hostPath volume supports the ability to specify allowed paths for a given Pod to mount. This restriction is not available for the PersistentVolumeClaim, and does not propagate to the hostPath PersistentVolume.

The validations for PersistentVolumes currently only ensure mount options are correct, and that the provided target path does not contain ‘..’.

Exploit Scenario
Eve gains access to Alice’s Kubernetes cluster with a service account able to create PersistentVolumes, PersistentVolumeClaims, and Pods, but restricted from mounting hostPath volumes. Eve uses her access to create a hostPath PersistentVolume and a corresponding PersistentVolumeClaim. Eve then creates a Pod mounting the PersistentVolumeClaim, effectively bypassing the PodSecurityPolicy restriction and allowing Eve to gain access to the node host filesystem where the Pod was scheduled.

See Appendix C for a proof of concept for this attack.

Recommendation
Short term, document the limitations of the allowedPaths restrictions in the PodSecurityPolicy.

Long term, add support for PersistentVolumeClaim restrictions within the PodSecurityPolicy. As a whole, the PodSecurityPolicy needs more granular controls to account for resources provided by association, such as PersistentVolumeClaims to PersistentVolumes.

Anything else we need to know?:

See #81146 for current status of all issues created from these findings.

The vendor gave this issue an ID of TOB-K8S-038 and it was finding 1 of the report.

The vendor considers this issue High Severity.

To view the original finding, begin on page 21 of the Kubernetes Security Review Report

Environment:

• Kubernetes version: 1.13.4