Privilege escalation allowed in a Kubernetes container

Description

allow_privilege_escalation controls whether a process can gain permissions beyond those of its parent through executable files. Setting it to false uses Linux no_new_privs to restrict new privileges from setuid programs or file capabilities.

This does not remove permissions already held or prevent every kernel exploit. The restriction cannot be relied on for privileged containers or those with SYS_ADMIN; remove those privileges too.

Potential impact

Available privileged executables may let a process gain unintended additional permissions.
An application compromise can have a greater impact inside the container.

Remediation

Set allow_privilege_escalation = false in the security_context block.
Remove privileged mode and unnecessary capabilities, and use a least-privileged execution identity.
Apply the setting to shared Pod templates and Helm charts, and check that required executables still work.

Examples

The examples compare privilege escalation settings. The image version is historical; use a supported image for deployment.

Before

hcl

resource "kubernetes_pod" "app_pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "app-container"

      security_context {
        allow_privilege_escalation = true
      }
    }
  }
}

This setting does not restrict gaining additional privileges through executable files. Whether privileges can actually be gained depends on those files and other controls.

After

hcl

resource "kubernetes_pod" "app_pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "app-container"

      security_context {
        allow_privilege_escalation = false
      }
    }
  }
}

The no_new_privs restriction is applied. Review existing permissions and other security settings separately.