RoleBinding targets the default ServiceAccount

Description

Pods without a separate account setting can share the namespace’s default ServiceAccount. Binding a Role or ClusterRole to that account gives workloads using it the same permissions. The resource scope depends on the binding type and scope.

Grant permissions narrowly to workloads that need them. Create ServiceAccounts with clear purposes and bind only required Roles.

Potential impact

New pods using the default account can receive unnecessary permissions.
Shared permissions can increase the impact of misuse and the difficulty of auditing workloads.

Remediation

Remove unnecessary RoleBindings and ClusterRoleBindings granted to the default ServiceAccount.
Create purpose-specific ServiceAccounts and bind only required permissions. Check both the subject name and namespace, and update the account used by the actual workload.

Examples

The examples assume a Role named admin in the default namespace and the target ServiceAccount in kube-system already exist. Changing to a dedicated account does not reduce the admin Role’s permissions.

Before

hcl

resource "kubernetes_role_binding" "example" {
  metadata {
    name      = "terraform-example"
    namespace = "default"
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = "admin"
  }

  subject {
    kind      = "ServiceAccount"
    name      = "default"
    namespace = "kube-system"
  }
}

After

hcl

resource "kubernetes_role_binding" "example" {
  metadata {
    name      = "terraform-example"
    namespace = "default"
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = "admin"
  }

  subject {
    kind      = "ServiceAccount"
    name      = "service-example"
    namespace = "kube-system"
  }
}

Explanation:

Before: The default ServiceAccount in kube-system receives a Role in the default namespace.
After: The same Role is granted to the dedicated service-example account instead.