Rancher's restricted PodSecurityPolicy does not prevent containers from running as a privileged user
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- Security bypass
- Confidentiality · integrity · availability
- —
- Fix status
- Fixed
No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-862.
Summary
### Impact The `restricted` pod security policy (PSP), provided in Rancher versions from 2.0 up to and including 2.6.3, has a deviation from the [upstream](https://github.com/kubernetes/website/blob/6d22e08903d7dd44b049c4689fa882ae07f67de9/content/en/examples/policy/restricted-psp.yaml) `restricted` policy provided in Kubernetes, in which Rancher's PSP has `runAsUser` set to `runAsAny`, while upstream has `runAsUser` set to `MustRunAsNonRoot`. This allows containers to run as any user, including a privileged user (`root`), even when Rancher's `restricted` policy is enforced on a project or at cluster level. A new `restricted-noroot` PSP was created to prevent pods from running as `root` when this policy is enforced. This new policy was introduced, instead of patching the current provided `restricted` policy, in order to avoid breaking users' workloads that are using the `restricted` PSP and that might be running as a privileged user. **Note**: Running containers as `root` increases the risk of a compromised container being used by a malicious actor as an attack platform to further exploit the user's environment. It is a security best practice to avoid running containers as a privileged user and to limit its usage to workloads where it is strictly necessary. ### Patches Patched versions include release 2.6.4 and later versions. The existing `restricted` PSP in Rancher 2.6.4 was not modified and still allows containers to run as a privileged user, as explained above. This fix was not backported to previous releases. For Rancher 2.6.4 and later releases, users using the current `restricted` PSP and that want to prevent containers from running as `root`, are advised to migrate to the new `restricted-noroot` policy. Before doing this migration, it is necessary to verify if affected workloads are currently running as a privileged user and modify them accordingly to the users' own environment to run as a non-privileged user. A redeployment of the affected workload is necessary in order for the new PSP to take effect. ### Workarounds For users running Rancher 2.6.3 and previous releases, which did not received this backport and that want to benefit from this fix, they can manually create a new `restricted-noroot` PSP on their clusters through Rancher UI. The template of the `restricted-noroot` policy provided in Rancher 2.6.4 is available in the [source code](https://github.com/rancher/rancher/blob/7410cef256c9ed22e8bf4609e5b2e9a1f63a0d05/pkg/data/management/podsecuritypolicytemplate_data.go#L101-L145). As a reminder, it is also necessary to manually verify and redeploy the running workload before enabling a more restricted pod security policy. ### References For instructions on how to configure pod security policies using Rancher, please refer to the [documentation](https://rancher.com/docs/rancher/v2.6/en/admin-settings/pod-security-policies/) page. For more information on PSPs in Kubernetes, please refer to the Kubernetes [documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/concepts/policy/pod-security-policy.md)). **Important reminder:** Pod security policies are considered deprecated since Kubernetes v1.21, and will be removed in Kubernetes v1.25. Consult Kubernetes' [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md)) regarding how to migrate from PodSecurityPolicy to Kubernetes' built-in PodSecurity Admission Controller. For the list of supported Kubernetes versions in Rancher, please consult our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/). ### For more information If you have any questions or comments about this advisory: * Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. * Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. * Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| — | github.com/rancher/rancher (Go) | 2.0.0 to before 2.6.4 | 2.6.4 | Patch available | GHSA-hwm2-4ph6-w6m5 |
- github.com/rancher/rancher (Go) Vendor— Affected 2.0.0 to before 2.6.4 Fixed in 2.6.4 Patch available GHSA-hwm2-4ph6-w6m5
Remediation
- Fix · GHSA-hwm2-4ph6-w6m5 github.com/rancher/rancher (Go) Fixed in 2.6.4 Advisory →
Timeline
- 2026-10-03 Threatist record created from GHSA-hwm2-4ph6-w6m5
References
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences