Por qué Kubernetes es un objetivo prioritario
En 2024, Kubernetes fue el componente de infraestructura más citado en incidentes de cloud security según el informe de Sysdig. Las razones son claras:
- Configuraciones por defecto permisivas
- Superficie de ataque amplísima (API server, etcd, kubelet, ingress)
- Adopción masiva sin formación específica en seguridad
1. Asegurar el API Server
El API Server es el punto de entrada a todo el cluster. Configuraciones críticas:
--anonymous-auth=false— Nunca permitir acceso anónimo--authorization-mode=RBAC,Node— RBAC siempre activado--audit-log-path=/var/log/k8s-audit.log— Audit logging obligatorio--tls-min-version=VersionTLS12— TLS 1.2 como mínimo--disable-admission-plugins=AlwaysAdmit— Nunca admitir todo
2. RBAC: mínimo privilegio
El error más común: ClusterRoleBinding con cluster-admin a service accounts de aplicación.
Regla de oro: nunca uses cluster-admin en producción para nada que no sea el administrador humano del cluster.
Siempre define Roles con namespace específico y solo los verbos necesarios (get, list), nunca acceso wildcard.
3. Pod Security Standards
Con Kubernetes 1.25+, usar Pod Security Admission con el perfil restricted en namespaces de producción. Este perfil bloquea:
- Contenedores como root
- Privileged containers
- HostNetwork / HostPID / HostIPC
- Capabilities peligrosas (NET_ADMIN, SYS_PTRACE, etc.)
4. Secrets: cifrado en reposo
Por defecto, etcd almacena los Secrets en base64 (que no es cifrado). Activar EncryptionConfiguration con AES-CBC o usar un gestor externo:
- HashiCorp Vault con el CSI Secrets Store Driver
- AWS Secrets Manager o Azure Key Vault
- Sealed Secrets de Bitnami para GitOps
5. Network Policies
Sin Network Policies, todos los pods se comunican entre sí. Aplicar deny-all por defecto en cada namespace de producción, luego añadir reglas explícitas solo para los flujos necesarios.
Checklist CIS Kubernetes Benchmark
| Control | Prioridad | Estado recomendado |
|---|---|---|
| API anónimo desactivado | Crítico | ✅ Activar siempre |
| RBAC activado | Crítico | ✅ Activar siempre |
| Audit logging | Alto | ✅ Activar siempre |
| Secrets cifrados en etcd | Alto | ✅ Implementar |
| Network Policies | Alto | ✅ Deny-all por defecto |
| Imágenes firmadas (Cosign) | Medio | ⚠️ Recomendado |
| Runtime security (Falco) | Medio | ⚠️ Recomendado |
| Escaneo en CI/CD (Trivy) | Medio | ✅ Implementar |
Herramientas de auditoría
- kube-bench — Ejecuta el CIS Benchmark automáticamente
- Trivy — Escanea imágenes, manifiestos y configuraciones IaC
- Falco — Detección de amenazas en runtime
- Popeye — Sanitiza y detecta problemas de configuración
Conclusión
El hardening de Kubernetes es un proceso continuo. Empieza por los controles de alto impacto (RBAC, Pod Security Standards, Network Policies) y automatiza las auditorías en tu pipeline CI/CD. La seguridad no es un estado final, sino un proceso de mejora continua.