Hardening empresarial de Kubernetes y AWS en producción
Configuraciones esenciales para aislar pods, mitigar escaladas de privilegios en Service Accounts y auditoría automatizada de políticas IAM restrictivas.
El error más común: confiar en el default
Un cluster EKS recién creado con la configuración por defecto no es seguro para producción. El Service Account default monta su token automáticamente en cada pod, el PodSecurityPolicy ya no existe, y la mayoría de equipos pasan directamente a desplegar workloads sin definir un PodSecurityStandard, NetworkPolicies ni un OPA/Kyverno mínimo.
Ese pod compromisible — un sidecar de logs vulnerable, una imagen base con CVE conocido — se convierte en pivote dentro del cluster en cuestión de minutos. Y desde ahí, si el IRSA está mal acotado, el atacante salta al plano AWS con permisos que nadie revisó.
Aislamiento de pods que sí aguanta una auditoría
Cuatro controles mínimos: runAsNonRoot con un UID estable, readOnlyRootFilesystem siempre que el workload lo permita, seccompProfile RuntimeDefault, y allowPrivilegeEscalation: false. Sobre esa base, NetworkPolicies default-deny por namespace y egress controlado a una lista cerrada de destinos. Sin esto, hablar de Zero Trust dentro del cluster es marketing.
apiVersion: v1
kind: Pod
spec:
automountServiceAccountToken: false
securityContext:
runAsNonRoot: true
runAsUser: 10001
seccompProfile: { type: RuntimeDefault }
containers:
- name: app
image: registry.internal/app@sha256:...
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities: { drop: ["ALL"] }IRSA bien hecho
El patrón correcto es: un Service Account por workload, un IAM Role por Service Account, y una política con acciones explícitas — nunca Action: "*". El trust policy del rol debe restringir el sub a system:serviceaccount:<ns>:<sa>, y la política debe acotar Resource con ARNs concretos, no con comodines de cuenta.
Un escaneo trimestral con AWS IAM Access Analyzer y prowler --compliance cis_2.0_aws debería ser parte del pipeline, no una tarea anual.
Detección que importa
CloudTrail con eventos de gestión y de datos habilitados, GuardDuty con findings enviados a un EventBridge bus dedicado, y reglas de detección sobre acciones IAM sensibles: CreateAccessKey, AttachUserPolicy, AssumeRole desde IPs fuera de la lista corporativa. En el cluster, Falco con un ruleset adaptado al negocio — no el default — y exfiltración bloqueada por defecto a nivel de NetworkPolicy.