¿Cómo funciona el RBAC con las ServiceAccounts, y cómo se asegura un cluster de Kubernetes?

Question

IT Interview Practice · Accepted Answer

El **RBAC (Role-Based Access Control)** gobierna *quién puede hacer qué* sobre la API. Los permisos se conceden a **sujetos** (usuarios, grupos, **ServiceAccounts**) **enlazándolos (binding)** a **Roles** que listan los verbos permitidos sobre recursos. El RBAC es una capa de una estrategia más amplia de fortificación del cluster.

## El modelo RBAC

```text
SUJETO (usuario / grupo / ServiceAccount)
   │  enlazado por
   ▼
RoleBinding ───────► Role         (namespaced: permisos dentro de UN namespace)
ClusterRoleBinding ► ClusterRole  (a nivel de cluster, o reutilizable entre namespaces)

Role/ClusterRole = un conjunto de REGLAS: "estos VERBOS sobre estos RECURSOS"
Los bindings son ADITIVOS y NO hay deny — concedes solo lo necesario.
```

## Ejemplo de Role + RoleBinding

```yaml
# Un Role: acceso de solo lectura a los Pods del namespace "app"
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Enlaza ese Role a una ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccounts: identidad para los Pods

```text
Una ServiceAccount es la IDENTIDAD que un Pod usa para hablar con el API server.
  → Todo Pod recibe una (la SA "default" del namespace si no se especifica).
  → Se monta un token proyectado en el Pod; el RBAC decide qué puede hacer ese token.
Buena práctica: dar a cada workload su PROPIA SA con RBAC de mínimo privilegio,
y poner automountServiceAccountToken: false cuando el Pod no necesita acceso a la API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # renuncia si no se necesitan llamadas a la API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # ejecuta los Pods bajo esta identidad
```

## Defensa en profundidad — más allá del RBAC

```text
AUTH        → RBAC de mínimo privilegio; ServiceAccounts por workload; auditar el acceso
NETWORK     → NetworkPolicies default-deny (los Pods no hablan salvo permiso)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop de capabilities
              perfiles seccomp; Pod Security Admission (restricted) para imponerlo
SECRETS     → cifrado en reposo para etcd; gestores de secrets externos; RBAC estricto sobre secrets
IMAGES      → escanear imágenes, usar registries de confianza, imponer con admission (p. ej. policy engines)
API/etcd    → restringir y cifrar etcd; TLS en todas partes; limitar acceso anónimo y cluster-admin
SUPPLY CHAIN→ imágenes firmadas, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # ¿qué puede hacer el usuario actual?
```

## Por qué es importante

Asegurar un cluster es una responsabilidad senior, y el RBAC con ServiceAccounts es su cimiento, así que entender ambos es conocimiento esencial de seguridad. El modelo RBAC es elegante y merece interiorizarse: los permisos son **puramente aditivos, sin deny**, concedidos **enlazando sujetos** (usuarios, grupos y, sobre todo, **ServiceAccounts**) a **Roles** (namespaced) o **ClusterRoles** (a nivel de cluster) que enumeran los **verbos permitidos sobre recursos**, lo que significa que la buena seguridad viene de conceder solo lo que cada workload necesita (**mínimo privilegio**) en lugar de apoyarse en denegaciones. Entender que una **ServiceAccount es la identidad que un Pod usa para llamar a la API** —que todo Pod recibe un token, que la SA `default` es una trampa común de exceso de privilegios, y que deberías dar a cada workload su propia SA de mínimo privilegio (y desactivar el automontaje del token cuando no se necesita acceso a la API)— es directamente práctico y una fuente frecuente de mala configuración en el mundo real. Crucialmente, un ingeniero senior sabe que el RBAC es solo una capa de **defensa en profundidad**: **NetworkPolicies** default-deny, ajustes de **securityContext** endurecidos (non-root, sistema de ficheros raíz de solo lectura, capabilities eliminadas, seccomp), **Pod Security Admission**, **cifrado en reposo** y gestores externos para los Secrets, escaneo y firma de imágenes, admission controllers (OPA/Gatekeeper, Kyverno) y acceso a etcd/API restringido se combinan para proteger un cluster. Como un cluster de Kubernetes es un objetivo de alto valor donde una sola ServiceAccount con exceso de permisos o una NetworkPolicy abierta puede llevar a un compromiso total, dominar el RBAC y el conjunto más amplio de herramientas de fortificación es fundamental para operar clusters de forma segura en producción.

El modelo RBAC

Ejemplo de Role + RoleBinding

ServiceAccounts: identidad para los Pods

Defensa en profundidad — más allá del RBAC

Por qué es importante

Preguntas relacionadas