Kubernetes es el estándar para orquestación de contenedores, pero su configuración predeterminada está lejos de ser segura. Desde servidores API abiertos hasta pods con privilegios excesivos — las malas configuraciones son la causa número uno de brechas en Kubernetes. En este artículo cubrimos las medidas de seguridad esenciales que todo cluster debe tener.
RBAC y Pod Security Standards
El Control de Acceso Basado en Roles (RBAC) es la piedra angular de la seguridad en Kubernetes. El principio de mínimo privilegio debe aplicarse estrictamente: da a usuarios y cuentas de servicio solo los permisos que necesitan. Evita usar cluster-admin para cargas de trabajo de aplicaciones y crea roles específicos por namespace.
Los Pod Security Standards (PSS) reemplazan el obsoleto PodSecurityPolicy y definen tres niveles de seguridad: Privileged, Baseline y Restricted. Usa el perfil Restricted como predeterminado para todos los namespaces y solo haz excepciones donde sea absolutamente necesario. Esto previene que los contenedores se ejecuten como root, compartan namespaces del host o permitan escalada de privilegios.
# Pod Security Standard - Namespace Restricted
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
---
# NetworkPolicy - denegar todo por defecto
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- EgressPolíticas de red y gestión de secretos
Por defecto, cada pod en Kubernetes puede comunicarse con cualquier otro pod, independientemente del namespace. Esto hace que el movimiento lateral después de una brecha sea trivial. Las NetworkPolicies son esenciales: comienza con una política default-deny-all por namespace y luego permite solo el tráfico estrictamente necesario.
Los Secrets de Kubernetes solo están codificados en base64 por defecto y no están cifrados. Usa cifrado en reposo mediante EncryptionConfiguration y considera almacenes de secretos externos como HashiCorp Vault, AWS Secrets Manager o Sealed Secrets. Rota los secretos regularmente y nunca uses variables de entorno para datos sensibles — monta los secretos como archivos con permisos de archivo restrictivos.
- Aplica RBAC con el principio de mínimo privilegio por namespace
- Activa Pod Security Standards en nivel Restricted
- Implementa NetworkPolicies default-deny para cada namespace
- Cifra los Secrets en reposo y usa almacenes de secretos externos
- Escanea imágenes de contenedores en busca de vulnerabilidades en tu pipeline CI/CD
- Restringe el servidor API de Kubernetes a rangos de IP confiables
Seguridad en tiempo de ejecución y monitoreo
Las medidas preventivas son esenciales, pero también debes asumir que una brecha puede ocurrir. Herramientas de seguridad en tiempo de ejecución como Falco detectan comportamiento sospechoso en tiempo real: procesos inesperados en contenedores, cambios en el sistema de archivos y anomalías de red. Combina esto con un stack de logging robusto (Fluentd/Loki + Grafana) para visibilidad completa.
También implementa controladores de admisión como OPA Gatekeeper o Kyverno para aplicar políticas antes del despliegue. Estas herramientas pueden evitar que cargas de trabajo mal configuradas lleguen al cluster. Combinado con escaneo de imágenes en tu pipeline CI/CD e imágenes firmadas mediante Cosign/Sigstore, creas una estrategia de defensa en profundidad que protege tu cluster de Kubernetes en cada nivel.
Consejo Pro
Ejecuta kubectl auth can-i --list hoy para cada cuenta de servicio en tu cluster para verificar cuentas con privilegios excesivos. Activa Pod Security Standards en nivel de auditoría para todos los namespaces y revisa las advertencias en tus logs. Probablemente te sorprenderás de cuántas cargas de trabajo se ejecutan como root o tienen capabilities innecesarias.
Compartir este artículo