Kubernetes Default Service Account

Pods running with the default service account inherit cluster-level RBAC permissions that are often far more powerful than the workload needs, enabling lateral movement if the pod is compromised.

How It Works

Every Kubernetes namespace has a service account named 'default' that is automatically mounted into every pod unless explicitly disabled. Cluster administrators sometimes bind broad ClusterRoles to this default account for convenience. When an attacker gains code execution inside a pod, they read the mounted token at /var/run/secrets/kubernetes.io/serviceaccount/token and use it to query the Kubernetes API. If the default account has elevated permissions, the attacker can list secrets, spawn new pods, or even escalate to cluster-admin. The fix is simple: create dedicated service accounts with minimal RBAC and disable automatic token mounting.

Vulnerable Code

# BAD: pod uses default service account with no restrictions
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: my-app:latest
  # No serviceAccountName specified -> uses 'default'
  # No automountServiceAccountToken: false -> token is mounted

Secure Code

# GOOD: dedicated service account with minimal RBAC, no auto-mount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  automountServiceAccountToken: false
  containers:
    - name: app
      image: my-app:latest

Real-World Example

In the 2021 Tesla Kubernetes cluster breach, attackers exploited a misconfigured default service account in an exposed Kubernetes dashboard to access pods that had credentials for Tesla's AWS environment. The default service account had excessive RBAC bindings, allowing the attackers to pivot from a single pod to the broader infrastructure.

How to Prevent It

Create a dedicated ServiceAccount for each workload with only the RBAC permissions it actually needs
Set automountServiceAccountToken: false on all pods and service accounts that do not need Kubernetes API access
Never bind ClusterRole or ClusterRoleBinding to the default service account in any namespace
Use OPA Gatekeeper or Kyverno policies to reject pods that use the default service account

Affected Technologies

TerraformKubernetesDocker

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities

Terraform State Exposed

critical

Your terraform.tfstate file is committed to your repository or stored in an unencrypted, publicly accessible location — it contains every secret and resource ID in your infrastructure.

CWE-312OWASP A02:2021

Terraform Provider Credentials Hardcoded

critical

AWS, GCP, or Azure credentials are hardcoded in your .tf files instead of using environment variables or instance roles, committing cloud access keys to version control.

CWE-798OWASP A02:2021

Kubernetes Privileged Container

high

Your Kubernetes pod runs with securityContext.privileged: true, giving the container full access to the host kernel and effectively bypassing container isolation.

CWE-269OWASP A05:2021

Helm Chart Secrets in Values

high

Passwords, API keys, and other secrets are hardcoded directly in Helm values.yaml files, which get committed to version control and exposed to anyone with repository access.

CWE-798OWASP A07:2021