Cuenta de Servicio Predeterminada en Kubernetes

Los pods que corren con la cuenta de servicio predeterminada heredan permisos RBAC a nivel de cluster que generalmente son mucho mas amplios de lo que el workload necesita, permitiendo movimiento lateral si el pod es comprometido.

Cómo Funciona

Cada namespace de Kubernetes tiene una cuenta de servicio llamada 'default' que se monta automaticamente en cada pod a menos que se deshabilite explicitamente. Los administradores del cluster a veces vinculan ClusterRoles amplios a esta cuenta predeterminada por conveniencia. Cuando un atacante logra ejecucion de codigo dentro de un pod, lee el token montado en /var/run/secrets/kubernetes.io/serviceaccount/token y lo usa para consultar la API de Kubernetes. Si la cuenta predeterminada tiene permisos elevados, el atacante puede listar secrets, crear nuevos pods o incluso escalar a cluster-admin. La solucion es simple: crear cuentas de servicio dedicadas con RBAC minimo y deshabilitar el montaje automatico del token.

Código Vulnerable

# 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

Código Seguro

# 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

Ejemplo Real

En la brecha del cluster Kubernetes de Tesla en 2021, los atacantes explotaron una cuenta de servicio predeterminada mal configurada en un dashboard Kubernetes expuesto para acceder a pods que tenian credenciales del entorno AWS de Tesla. La cuenta de servicio predeterminada tenia bindings RBAC excesivos, lo que permitio a los atacantes pivotar desde un solo pod hacia la infraestructura mas amplia.

Cómo Prevenirlo

Crea un ServiceAccount dedicado para cada workload con solo los permisos RBAC que realmente necesita
Configura automountServiceAccountToken: false en todos los pods y cuentas de servicio que no necesiten acceso a la API de Kubernetes
Nunca vincules ClusterRole o ClusterRoleBinding a la cuenta de servicio predeterminada en ningun namespace
Usa politicas de OPA Gatekeeper o Kyverno para rechazar pods que usen la cuenta de servicio predeterminada

Tecnologías Afectadas

TerraformKubernetesDocker

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas

Estado de Terraform Expuesto

critical

Tu archivo terraform.tfstate está commiteado en tu repositorio o almacenado en un lugar sin cifrar y públicamente accesible — contiene cada secreto e ID de recurso en tu infraestructura.

CWE-312OWASP A02:2021

Credenciales de Proveedor Terraform Hardcodeadas

critical

Las credenciales de AWS, GCP o Azure están hardcodeadas en tus archivos .tf en lugar de usar variables de entorno o roles de instancia, commiteando claves de acceso cloud al control de versiones.

CWE-798OWASP A02:2021

Contenedor Kubernetes Privilegiado

high

Tu pod de Kubernetes corre con securityContext.privileged: true, dándole al contenedor acceso completo al kernel del host y efectivamente evitando el aislamiento del contenedor.

CWE-269OWASP A05:2021

Secretos en values.yaml de Helm Charts

high

Contrasenas, API keys y otros secretos estan hardcodeados directamente en archivos values.yaml de Helm, que se commitean al control de versiones y quedan expuestos a cualquiera con acceso al repositorio.

CWE-798OWASP A07:2021