Pregúntale a la mayoría de los equipos de ingeniería de PYMEs cuántas personas pueden ejecutar kubectl delete ns production en su clúster. La respuesta honesta, después de una larga pausa, suele ser: “…todos los que tienen un kubeconfig.”
Es la brecha de seguridad de Kubernetes más común que vemos en las empresas pequeñas: cluster-admin en todas partes. Un token de CI filtrado, una laptop robada, un ex-empleado descontento con un kubeconfig en caché — y un atacante tiene el mismo poder que el equipo de plataforma. Los auditores y evaluadores de SOC 2 piden cada vez más pruebas de acceso de mínimo privilegio, y la mayoría de las PYMEs no pueden presentarlas.
La buena noticia: arreglar esto es un proyecto de dos semanas, no una epopeya de ingeniería de plataforma. En esta guía auditarás tu acceso actual, construirás un modelo RBAC de mínimo privilegio, reemplazarás las credenciales de larga duración con identidad de cargas de trabajo y automatizarás el cumplimiento para que se mantenga corregido.
Audita Primero: Encuentra Cada cluster-admin Antes de Cambiar Cualquier Cosa
No puedes asegurar lo que no puedes ver. Comienza por listar cada subject (usuario o cuenta de servicio) vinculado al cluster-admin ClusterRole:
kubectl get clusterrolebinding -o json | \
jq -r '.items[] | select(.roleRef.name == "cluster-admin") |
.subjects[]? | "\(.kind):\(.name) (namespace: \(.namespace // "N/A"))"'Luego verifica qué puede hacer realmente una identidad específica — por ejemplo, la cuenta de servicio que usa tu pipeline de CI:
# What can the CI deployer service account do, cluster-wide?
kubectl auth can-i --list \
--as=system:serviceaccount:ci:deployer \
--namespace=production | head -30
# Who can create pods in production? (reverse lookup)
kubectl-who-can create pods -n production(kubectl-who-can y rbac-lookup son pequeños plugins de código abierto que convierten las reglas RBAC en respuestas de “quién puede hacer X” — invaluables para auditorías.)
Hallazgos comunes en clústeres de PYMEs: el usuario admin de bootstrap todavía en uso, cuentas de servicio con automountServiceAccountToken: true en namespaces que no necesitan acceso a la API, y credenciales de CI con permisos de todo el clúster * porque “era más fácil.” Anótalos todos — esa lista es tu backlog de trabajo.
Construye un Modelo RBAC de Mínimo Privilegio en 30 Minutos
El modelo que se ajusta a la mayoría de las PYMEs es simple: Roles limitados al namespace, tres niveles de acceso y bindings basados en grupos.
- Viewer — acceso de solo lectura para desarrolladores y dashboards.
- Developer — acceso completo dentro del(los) namespace(s) de su equipo, nada en otros lados.
- Operator/CI — los permisos limitados que tu pipeline necesita para desplegar, nada más.
Aquí tienes un nivel viewer completo — un Role y su binding:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: viewer
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "services", "configmaps", "secrets"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: production
name: viewer-binding
subjects:
- kind: Group
name: [email protected] # mapped from your OIDC IdP
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: viewer
apiGroup: rbac.authorization.k8s.ioObserva dos cosas. Primero, vincula a un grupo OIDC, no a usuarios individuales — el onboarding y offboarding ocurren entonces en tu proveedor de identidad, no en Kubernetes. Segundo, solo el viewer rol puede leer secrets; tu nivel de desarrollador no debería incluirlo. Los secrets se quedan con los operadores y el equipo de plataforma. (Y si tus secrets todavía están en manifiestos en texto plano, soluciona eso primero con nuestra guía práctica de gestión de secretos.)
Para el nivel de CI, otorga los verbos mínimos que tu pipeline realmente usa:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: deployer
rules:
- apiGroups: ["apps"]
resources: ["deployments", "statefulsets"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
- apiGroups: ["", "apps"]
resources: ["deployments/scale"]
verbs: ["get", "update", "patch"]Elimina los Kubeconfigs de Larga Duración: Identidad de Cargas de Trabajo para Pipelines y Pods
Los tokens estáticos de service account y los kubeconfigs versionados son la fuga de credenciales #1 en Kubernetes para PYMEs. La solución es tokens proyectados de corta duración — Kubernetes puede acuñar un token válido por una hora que tu pod monta como archivo:
apiVersion: v1
kind: Pod
spec:
serviceAccountName: app
containers:
- name: app
image: your-registry/app:1.4.2
volumeMounts:
- name: token
mountPath: /var/run/secrets/tokens
volumes:
- name: token
projected:
sources:
- serviceAccountToken:
path: token
expirationSeconds: 3600 # one hour, auto-refreshedEn Kubernetes gestionado, ve un paso más allá y dale a las cargas de trabajo identidades IAM cloud en lugar de tokens de Kubernetes. En EKS, un rol IAM solo puede ser asumido por una cuenta de servicio específica mediante federación OIDC:
resource "aws_iam_role" "app" {
name = "app-prod"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = {
Federated = "arn:aws:iam::123456789012:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLEOIDCID"
}
Action = "sts:AssumeRoleWithWebIdentity"
Condition = {
StringEquals = {
"oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLEOIDCID:sub" = "system:serviceaccount:production:app"
}
}
}]
})
}Tu pod entonces llama a las APIs de AWS con ese rol — sin claves de acceso en el repo, sin tokens estáticos, y el rol caduca automáticamente cuando el pod lo hace. GKE (iam.gke.io/gcp-service-account anotación) y AKS (Workload Identity con Entra ID) ofrecen el mismo patrón. El principio es idéntico en todas partes: la identidad proviene del contexto de la carga de trabajo, no de un archivo de secretos.
Automatiza el Cumplimiento y Detecta la Deriva (Drift)
Los modelos RBAC se deterioran. Alguien volverá a otorgar cluster-admin “temporalmente” durante un incidente de madrugada. Haz cumplir el modelo con policy as code para que la deriva sea rechazada en el API server, no descubierta meses después. Una constraint de Gatekeeper que prohíba nuevos cluster-admin bindings es un buen comienzo:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockClusterAdmin
metadata:
name: no-new-cluster-admins
spec:
match:
kinds:
- apiGroups: ["rbac.authorization.k8s.io"]
kinds: ["ClusterRoleBinding", "RoleBinding"]
parameters:
forbiddenRoles: ["cluster-admin"]La configuración completa de OPA Gatekeeper — incluyendo constraints para los niveles viewer/developer/operator — está cubierta paso a paso en nuestra guía de policy-as-code para Kubernetes en PYMEs.
Agrega dos verificaciones ligeras a tu pipeline de CI: kube-linter (detecta contenedores privilegiados y RBAC demasiado amplio en los manifiestos) y un cron semanal que ejecute el comando de auditoría de la primera sección y publique un diff en el chat de tu equipo. Y si ya ejecutas escaneos de seguridad en CI, extiende el mismo pipeline con los patrones DevSecOps de nuestra guía de DevSecOps para PYMEs.
Un Plan de Implementación de Dos Semanas para PYMEs
Semana 1: ejecuta la auditoría, lista cada binding riesgoso y construye el modelo RBAC de tres niveles como código. Semana 2: migra CI y pods a identidad de cargas de trabajo, habilita Gatekeeper y elimina los kubeconfigs de admin antiguos. Eso es todo — dos semanas para un clúster donde el radio de impacto de cualquier credencial filtrada es un namespace, no todo tu negocio.
¿Quieres hacer esto sin sacar a tus ingenieros del trabajo de producto? Nuestro equipo ayuda a las PYMEs a implementar seguridad en Kubernetes, RBAC e identidad de cargas de trabajo de principio a fin — book a free consultation y auditaremos tu clúster contigo.
Español 
English