La migración a Kubernetes casi mata nuestra startup. Dónde estábamos: - 8 instancias EC2 - Ansible para despliegues - Aburrido pero funcionando - Factura de AWS de $1200/mes Por qué migramos: - El nuevo inversor quería 'nativo en la nube' - Los ingenieros querían experiencia en K8s - Los competidores lo estaban usando - Parecía el futuro 6 meses después: - 3 ingenieros dedicados a tiempo completo a K8s - Factura de AWS de $4500/mes - Los despliegues tardaban más que antes - Más interrupciones, no menos - El desarrollo del producto se estancó Retrocedimos: - Nos mudamos a ECS Fargate - Migración de 2 semanas - De vuelta a $1800/mes - Ingenieros de vuelta en características K8s es increíble para escalar. No estábamos en escala. La tecnología debería resolver problemas que realmente tienes.

Se añadió compresión gzip a nuestra API. El tamaño de la respuesta se redujo un 85%, la latencia se redujo un 60%. Antes de la compresión: - Respuesta promedio: 240 KB - Tiempo de transferencia: 400ms - Costo de ancho de banda: $220/mes Después de la compresión: - Respuesta promedio: 36 KB - Tiempo de transferencia: 48ms - Costo de ancho de banda: $70/mes Se añadió middleware de compresión Resultados: - Tiempo de carga: 88% más rápido - Ancho de banda: reducción del 68%

Un tester de penetración obtuvo acceso root a nuestro clúster de Kubernetes en 15 minutos. Esto es lo que explotaron. La cadena de ataque: - Encontró el panel de control de Kubernetes expuesto (nuestro error) - El panel tenía una cuenta de servicio de solo lectura (pensamos que esto era seguro) - La cuenta de servicio podía listar secretos en todos los espacios de nombres - Encontró credenciales de AWS en un secreto - Usó las credenciales de AWS para acceder al perfil de instancia de EC2 - El perfil de instancia tenía acceso completo de administrador de Kubernetes a través de IAM - Usó kubectl para crear un pod privilegiado - Escapó al nodo - Acceso root a todo el clúster Lo que pensamos que hicimos bien: - El panel era de solo lectura - Los secretos estaban cifrados en reposo - Había políticas de red en su lugar - Actualizaciones de seguridad regulares Lo que nos perdimos: - El panel no debería estar expuesto en absoluto - Las cuentas de servicio necesitan el principio de menor privilegio - Los secretos no deberían contener credenciales de AWS (usar IRSA en su lugar) - Las Políticas de Seguridad de Pods no se aplicaron - El acceso al nodo no estaba endurecido La solución tomó 2 semanas: - Se eliminó completamente el panel de control de Kubernetes - Se implementó IRSA para todo el acceso a AWS de los pods - Se aplicaron PSPs/Estándares de Seguridad de Pods estrictos - Auditoría de todos los permisos de RBAC - Pruebas de penetración regulares Costo: $24K por la prueba de penetración Valor: Prevención de lo que podría haber sido una brecha catastrófica