Pod-creation permissions are too broad

Description

A bound RBAC Role or ClusterRole granting create on pods lets an identity deploy Pods within the allowed scope. Depending on the Pod configuration, it may use sensitive ServiceAccounts, Secrets, host mounts or privileged containers and enable privilege escalation. Admission policies and other controls also constrain what is allowed.

Pod creation establishes a new execution environment in the cluster. Grant it only to identities that need it.

Potential impact

Allowed Pod configurations can provide access to stronger permissions or sensitive data.
Excessive creation permissions can consume resources or weaken operational controls.

Remediation

Grant create and wildcard permissions on pods only to identities that need deployment access. Limit ordinary read access to the required get, list and watch permissions.
Combine namespace-scoped roles with Pod Security Admission or a policy engine to restrict privileges and host access. Control which ServiceAccounts may be used through a separate policy.

Examples

These examples compare the Role’s creation permissions only. Bindings that grant the Role and admission policies are configured separately.

Before

hcl

resource "kubernetes_role" "role" {
  metadata {
    name = "terraform-example"
  }

  rule {
    api_groups = [""]
    resources  = ["pods"]
    verbs      = ["create", "list", "watch"]
  }
}

After

hcl

resource "kubernetes_role" "role" {
  metadata {
    name = "terraform-example"
  }

  rule {
    api_groups = [""]
    resources  = ["pods"]
    verbs      = ["get", "list", "watch"]
  }
}

Explanation:

Before: Pod creation is included, allowing workloads to be deployed under the applicable controls.
After: Creation is removed and read permissions remain.