RBAC permits Pod port forwarding

Description

Access to pods/portforward allows users to open a direct communication channel to a Pod inside the cluster. This may bypass normal service exposure policies or some network controls. It does not replace the service’s own authentication.

Treat production port forwarding as sensitive access rather than just a convenience. Allow it only when necessary.

Potential impact

• Users can communicate directly with services inside Pods.
• Network isolation or restrictions on public access paths may be bypassed.
• Additional access paths to sensitive internal services may become available.

Remediation

• Remove or minimize pods/portforward access in RBAC roles.
• Allow production debugging through port forwarding only with an approved procedure.
• Prefer standard network paths and authentication policies for internal service access.

Examples

The RoleBinding that grants the role is omitted. Check whether other roles grant the same access.

Before

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-namespace
  name: allow-port-forward
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/portforward"]
    verbs: ["get", "list", "create"]

After

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-namespace
  name: allow-port-forward-neg
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "create"]

Explanation:

• Before: pods/portforward allows opening a direct channel to an internal Pod.
• After: This role no longer grants port forwarding. Pod creation remains allowed, so review whether it is needed.

References

• CWE-732
• Kubernetes RBAC reference