RBAC permits attaching to containers

Description

Access to pods/attach lets a user connect to a running container’s output and send input when standard input is enabled. Unlike exec, it does not start a new command, but direct interaction with a running process makes it sensitive.

Attaching to a powerful container may expose information or allow misuse of the workload. Limit production access to cases where it is necessary.

Potential impact

• Users can connect directly to a running container session.
• Sensitive output and internal activity may become visible in real time.
• Interaction with a highly privileged container may enable further misuse.

Remediation

• Remove unnecessary access to the pods/attach resource from RBAC roles.
• Use approved procedures and restricted accounts for debugging.
• Limit interactive production access to the people who require it.

Examples

The RoleBinding that grants the role to a user is omitted. Review permissions granted through other roles too.

Before

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

After

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

Explanation:

• Before: Access to pods/attach allows connecting directly to a running container session.
• After: This role no longer grants attach access. Pod creation remains allowed and needs a separate review.

References

• CWE-732
• Kubernetes RBAC reference