Es fácil pensar que, al trabajar con contenedores, la seguridad del host deja de importar. Es justo al revés: cada nodo de Kubernetes es una máquina que arranca desde una imagen, y una brecha en el host compromete todos los pods que aloja. La AMI del nodo es, por tanto, una pieza crítica de seguridad.
Tienes tres caminos: usar las AMIs optimizadas oficiales tal cual, usarlas como base y personalizarlas, o construir la tuya. Para producción seria, personalizar o construir sobre una base endurecida es lo recomendable.
Qué debe llevar una buena AMI de nodo
- Base optimizada para el runtime de contenedores, con containerd y el kubelet correctamente configurados.
- Hardening CIS del sistema operativo y, cuando aplique, del propio benchmark CIS for Kubernetes.
- Parcheo al día del kernel y de los componentes, con reconstrucción periódica.
- Agentes necesarios —logs, métricas, seguridad— preinstalados para un arranque rápido.
- Sin secretos ni credenciales horneados; identidad vía IAM Roles for Service Accounts (IRSA) o equivalente.
- Configuración mínima: elimina paquetes y servicios que un nodo no necesita.
Opciones de imagen para EKS
| Opción | Ventaja | Cuándo elegirla |
|---|---|---|
| AMI EKS optimizada (AL2023) | Oficial, mantenida por AWS | Punto de partida general |
| Bottlerocket | SO mínimo orientado a contenedores, inmutable | Máxima seguridad y menor superficie |
| AMI personalizada | Control total del hardening y los agentes | Requisitos de cumplimiento estrictos |
Elige la base de nodo según tu equilibrio entre control y comodidad.
Bottlerocket: contenedores primero
Bottlerocket es un sistema operativo minimalista de AWS pensado exclusivamente para ejecutar contenedores. Su superficie de ataque es diminuta, es inmutable y se actualiza por imagen —no por parcheo en caliente—, lo que encaja de maravilla con la filosofía de infraestructura inmutable. Si tu prioridad es la seguridad del nodo con el mínimo esfuerzo de mantenimiento, merece una evaluación seria.
Actualizar nodos sin dolor
Una AMI de nodo endurecida solo sirve si mantienes los nodos al día. El patrón inmutable brilla aquí:
- Reemplaza, no parchees: publica una nueva versión de AMI y rota los nodos.
- Rolling update del grupo de nodos: drena con cordon y drain y sustituye nodo a nodo.
- Managed Node Groups o Karpenter para automatizar el reemplazo con nuevas AMIs.
- PodDisruptionBudgets para que la rotación no afecte a la disponibilidad de tus servicios.
Errores frecuentes
- Usar la AMI optimizada por defecto durante meses sin actualizarla.
- Hornear credenciales del clúster en la imagen en lugar de usar identidad federada.
- Olvidar el hardening del propio kubelet y de los permisos del sistema de ficheros.
- No limitar el acceso SSH a los nodos: idealmente, cero SSH y acceso solo vía SSM.
Preguntas frecuentes
¿Necesito una AMI personalizada o me vale la optimizada de EKS?
Para empezar, la optimizada oficial es un buen punto de partida. Si tienes requisitos de cumplimiento o seguridad estrictos, personalízala o construye la tuya con hardening y agentes propios.
¿Bottlerocket sustituye a una AMI Linux normal?
Para nodos que solo ejecutan contenedores, sí: ofrece menor superficie de ataque y actualización inmutable. No es adecuado para cargas que necesiten un SO de propósito general.
¿Cómo actualizo los nodos cuando publico una AMI nueva?
Con un rolling update del grupo de nodos: se drenan y reemplazan de forma progresiva respetando los PodDisruptionBudgets para no afectar al servicio.
En imaxe.cloud diseñamos imágenes base endurecidas idóneas para servir de cimiento a tus nodos de Kubernetes.
