Kubernetes configuration permits unsafe sysctls

Description

Unsafe sysctls can affect Pod isolation or node stability, depending on the kernel setting. Even necessary performance tuning needs review against the Kubernetes and kernel versions and its effects on other workloads. Permitting a sysctl in a policy is different from a Pod setting its value.

PodSecurityPolicy was deprecated in Kubernetes v1.21 and removed in v1.25. Use Pod Security Admission or a policy engine to enforce restrictions on current clusters.

Potential impact

Incorrect kernel tuning can destabilize applications or nodes.
Depending on isolation, the changes may affect other Pods or node resources.

Remediation

Remove unnecessary allowed_unsafe_sysctls permissions and use only sysctls classified as safe for the applicable version in Pods.
If an exception is necessary, review the actual values and effects, then limit use with the kubelet allow-list and measures such as dedicated nodes.
Verify workload operation and policy enforcement after the change.

Examples

These partial examples show a legacy PodSecurityPolicy allow-list. They require a historical environment supporting that API and provider and are not complete policy definitions.

Before

hcl

resource "kubernetes_pod_security_policy" "policy" {
  metadata {
    name = "terraform-example"
  }

  spec {
    allowed_unsafe_sysctls = ["kernel.msg*"]
  }
}

The policy permits unsafe sysctls in the kernel.msg* family. It does not itself change their values.

After

hcl

resource "kubernetes_pod_security_policy" "policy" {
  metadata {
    name = "terraform-example"
  }

  spec {
    privileged                 = false
    allow_privilege_escalation = false
  }
}

The unsafe sysctl allowance is removed. Restrictions on privileged and allow_privilege_escalation provide separate protections.