ServiceAccount name is not specified

Description

A pod without a ServiceAccount name uses the default ServiceAccount in its namespace. If that account has been granted permissions, unintended workloads can use the same permissions. The default account does not always have administrative access.

Identifying each workload’s account and required permissions supports separation and operation. Naming an account alone does not reduce its permissions.

Potential impact

A workload can receive unnecessary permissions granted to the default ServiceAccount.
Permission separation and auditing can become harder across workloads with different purposes.

Remediation

Set service_account_name on pods and pod templates to an approved ServiceAccount. Prepare it in the same namespace and verify the applied variable and template values.
Bind only required permissions to the account. Disable automatic token mounting when the workload does not need a Kubernetes API token.

Examples

Prepare service-name separately in the pod’s namespace. The retained image version illustrates account configuration; choose a maintained image for actual deployment.

Before

hcl

resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    service_account_name = ""

    container {
      image = "nginx:1.7.9"
      name  = "example"
    }
  }
}

After

hcl

resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    service_account_name = "service-name"

    container {
      image = "nginx:1.7.9"
      name  = "example"
    }
  }
}

Explanation:

Before: The empty name causes the default ServiceAccount to be used.
After: The ServiceAccount is named explicitly. Its permissions still need separate review.