policy config_error ai_generated true

Error: container has runAsNonRoot and image will run as root. PodSecurityPolicy: Privileged containers are not allowed. PodSecurityPolicy: 'privileged' is not allowed.

ID: policy/kubernetes-pod-security-policy-privileged-escalation

Also available as: JSON · Markdown · 中文
80%Fix Rate
88%Confidence
1Evidence
2023-07-05First Seen

Version Compatibility

VersionStatusIntroducedDeprecatedNotes
Kubernetes 1.20-1.24 (PSP) active — — —
Kubernetes 1.25+ (PSA) active — — —
OpenShift 4.x active — — —

Root Cause

The PodSecurityPolicy (or Pod Security Admission) in the namespace denies privileged containers, but the container image requires root privileges (e.g., runs as root by default), and the pod spec does not set `runAsNonRoot: true` or `securityContext.runAsUser` to a non-root user.

generic

中文

命名空间中的 PodSecurityPolicy（或 Pod 安全准入）拒绝特权容器，但容器镜像需要 root 权限（例如默认以 root 身份运行），并且 pod 规范未设置 `runAsNonRoot: true` 或 `securityContext.runAsUser` 为非 root 用户。

Official Documentation

https://kubernetes.io/docs/concepts/security/pod-security-standards/

Workarounds

  1. 85% success Modify the container image to run as a non-root user, or use a securityContext in the pod spec to set runAsUser to a non-root user (e.g., 1000) and runAsNonRoot to true. Example YAML: `securityContext: { runAsUser: 1000, runAsNonRoot: true }`. Also ensure the image does not require root filesystem access. 
    Modify the container image to run as a non-root user, or use a securityContext in the pod spec to set runAsUser to a non-root user (e.g., 1000) and runAsNonRoot to true. Example YAML: `securityContext: { runAsUser: 1000, runAsNonRoot: true }`. Also ensure the image does not require root filesystem access.
  2. 70% success If the image cannot be changed, create a custom PodSecurityPolicy that allows privileged containers and bind it to the namespace. Use `kubectl create psp privileged-psp --privileged` and then create a RoleBinding or ClusterRoleBinding to grant the `use` verb on the PSP to the service account. 
    If the image cannot be changed, create a custom PodSecurityPolicy that allows privileged containers and bind it to the namespace. Use `kubectl create psp privileged-psp --privileged` and then create a RoleBinding or ClusterRoleBinding to grant the `use` verb on the PSP to the service account.
  3. 80% success Upgrade to Kubernetes 1.25+ and use Pod Security Admission (PSA) instead of PSP, which is deprecated. Configure the namespace with a PSA label that allows privileged pods: `kubectl label namespace my-ns pod-security.kubernetes.io/enforce=privileged`. 
    Upgrade to Kubernetes 1.25+ and use Pod Security Admission (PSA) instead of PSP, which is deprecated. Configure the namespace with a PSA label that allows privileged pods: `kubectl label namespace my-ns pod-security.kubernetes.io/enforce=privileged`.

中文步骤

  1. 修改容器镜像以非 root 用户身份运行，或在 pod 规范中使用 securityContext 将 runAsUser 设置为非 root 用户（例如 1000）并将 runAsNonRoot 设置为 true。示例 YAML：`securityContext: { runAsUser: 1000, runAsNonRoot: true }`。还要确保镜像不需要 root 文件系统访问。
  2. 如果无法更改镜像，请创建一个允许特权容器的自定义 PodSecurityPolicy 并将其绑定到命名空间。使用 `kubectl create psp privileged-psp --privileged`，然后创建一个 RoleBinding 或 ClusterRoleBinding 以向服务帐户授予对 PSP 的 `use` 动词。
  3. 升级到 Kubernetes 1.25+ 并使用 Pod 安全准入（PSA）代替已弃用的 PSP。使用允许特权 pod 的 PSA 标签配置命名空间：`kubectl label namespace my-ns pod-security.kubernetes.io/enforce=privileged`。

Dead Ends

Common approaches that don't work:

  1. 90% fail

    The PodSecurityPolicy explicitly denies privileged containers. Setting privileged=true will cause the pod to be rejected by the admission controller.

  2. 70% fail

    The error indicates that the policy requires non-root, but the image runs as root. Removing runAsNonRoot does not change the image's behavior; the pod will still be rejected because the policy checks the effective user.

  3. 80% fail

    Setting runAsUser to 0 (root) conflicts with the policy's requirement for non-root containers. The admission controller will reject the pod.