RoleBinding targets a default ServiceAccount

Description

A Pod without an explicitly selected ServiceAccount is assigned its namespace’s default ServiceAccount. A RoleBinding or ClusterRoleBinding for that account can make permissions available to multiple workloads that do not need them.

Prefer dedicated ServiceAccounts with permissions tailored to each workload. Keep default ServiceAccounts at minimal privilege or without additional application permissions.

Potential impact

Multiple Pods may unexpectedly share the same permissions.
New Pods may also receive access through the default ServiceAccount.
Shared identities can make it harder to identify which workload misused a permission.

Remediation

Do not attach unnecessary RoleBindings to a default ServiceAccount.
Create dedicated ServiceAccounts for applications and grant only the permissions they need.
Review subjects with subjects.kind: ServiceAccount and subjects.name: default, including their namespace.

Examples

The example assumes a pod-reader Role exists in the default namespace. The ServiceAccount subject is the default account in kube-system; distinguish that namespace from the binding’s namespace.

Before

yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
  - kind: ServiceAccount
    name: default
    namespace: kube-system
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

After