¿Por qué Kubernetes presenta riesgos diferentes?
Kubernetes es poderoso porque automatiza la implementación, el escalado y la orquestación, pero ese mismo plano de control también amplía la cantidad de puntos en los que un error puede tener un impacto considerable. Un diseño RBAC débil puede otorgar un acceso excesivo a la infraestructura subyacente, incluidos los recursos confidenciales y, en algunos casos, el control administrativo. Una configuración permisiva del proceso de admisión puede permitir que cargas de trabajo de riesgo lleguen a producción. Una política de red demasiado permisiva puede facilitar el movimiento lateral.
Kubernetes también cambia el modelo operativo. Deben proteger una infraestructura basada en API, cargas de trabajo efímeras, complementos del clúster, cuentas de servicio, imágenes de contenedor y manifiestos de implementación que pueden cambiar constantemente.
¿Cuáles son los mayores riesgos de seguridad de Kubernetes?
Configuraciones inseguras de las cargas de trabajo: una configuración deficiente de la seguridad de los pods, contenedores privilegiados, capacidades excesivamente amplias, sistemas de archivos raíz con permisos de escritura o configuraciones predeterminadas inseguras en los manifiestos pueden exponer innecesariamente el clúster. En muchos casos, es en este punto donde el riesgo empieza a convertirse en un problema operativo.
- Permisos excesivos y errores de RBAC: si los usuarios, las cuentas de servicio o las cargas de trabajo tienen más privilegios de los que necesitan, aumenta el alcance potencial del impacto. Un diseño deficiente de los controles de acceso puede facilitar la escalada de privilegios y dificultar la recuperación.
- Vulnerabilidades en la cadena de suministro: las imágenes de contenedor pueden incluir vulnerabilidades conocidas, secretos expuestos, dependencias no confiables o componentes manipulados. El análisis de imágenes ayuda, pero la procedencia, los parches y la higiene de la imagen también son importantes.
- Aplicación deficiente de las políticas: si el clúster no valida lo que se puede implementar, las configuraciones riesgosas pueden pasar directamente a la fase de ejecución. Los controles de políticas solo son útiles cuando se aplican de manera consistente.
- Segmentación de red plana o deficiente: las redes de Kubernetes pueden facilitar el movimiento este-oeste tanto para las aplicaciones como para los atacantes si los límites entre los distintos segmentos son demasiado permisivos. La segmentación deficiente hace que la contención sea más difícil una vez que algo sale mal.
- Registro y supervisión inadecuados: si los equipos no recopilan ni revisan los registros adecuados, los atacantes pueden operar con menos probabilidades de ser detectados y los investigadores disponen de menos evidencia para analizar después del incidente.
¿Cómo se manifiestan estos riesgos en entornos reales?
En la práctica, el riesgo en Kubernetes rara vez se manifiesta como una única falla grave. Por lo general, se manifiesta como una acumulación de pequeñas debilidades subsanables: imágenes no analizadas, permisos excesivos para cuentas de servicio, políticas de espacios de nombres (namespaces) inconsistentes, propiedad de los clústeres poco clara, controles de admisión deficientes o una supervisión que se limita al nodo en lugar de abarcar la carga de trabajo.
Esta es la razón por la que la seguridad de Kubernetes es difícil desde el punto de vista operativo. Los equipos deben proteger tanto la plataforma como el modelo de entrega que la rodea. El desarrollo, la ingeniería de la plataforma, las operaciones en la nube y la seguridad influyen en el resultado.
¿Por qué persisten estos riesgos?
Persisten porque Kubernetes les ofrece a los equipos una enorme flexibilidad, y la flexibilidad siempre tiene un costo en materia de seguridad cuando las medidas de protección son insuficientes. Los equipos pueden trabajar con rapidez, realizar implementaciones frecuentes y dar soporte a aplicaciones distribuidas complejas, pero el modelo de control se vuelve más difícil de gestionar si los estándares no son consistentes entre un clúster y otro o entre un equipo y otro.
Otra razón es la fragmentación de la responsabilidad. El equipo de seguridad puede ser responsable de las políticas de seguridad; los equipos de plataforma de las operaciones del clúster; y los equipos de ingeniería de los manifiestos y los flujos de trabajo de entrega. Pero, si estos grupos no están alineados, el resultado suele ser un clúster que funciona correctamente desde el punto de vista técnico, pero presenta inconsistencias operativas en materia de seguridad.
¿A qué deberían prestar más atención los equipos?
Las áreas de enfoque de mayor valor suelen ser el control de acceso, la directiva de implementación, la configuración de la carga de trabajo y la visibilidad. En otras palabras, los equipos deberían centrarse, en primer lugar, en quién puede hacer qué, qué está permitido ejecutar, qué tan seguras están definidas las cargas de trabajo y si existe evidencia suficiente para detectar e investigar comportamientos sospechosos.
Esto es importante porque la seguridad de Kubernetes rara vez mejora con un solo panel de control más. Mejora cuando la organización ajusta las decisiones que controlan la implementación, el acceso y el comportamiento del runtime.
¿En qué se equivocan las organizaciones en materia de seguridad de Kubernetes?
Un error es centrarse demasiado en el contenedor y no lo suficiente en el clúster. Las imágenes de contenedor son importantes, pero la seguridad de Kubernetes también depende del control de admisión, el RBAC, el diseño de las cuentas de servicio, las políticas de red y la configuración de las cargas de trabajo.
Otro error consiste en asumir que la configuración predeterminada ofrece un nivel de seguridad suficiente para un entorno de producción. Kubernetes ofrece potentes controles de seguridad, pero muchos de ellos requieren un diseño y un mantenimiento deliberados.
Un tercer error consiste en desvincular en exceso la seguridad del proceso de entrega. Si las verificaciones de seguridad solo se realizan al final del proceso, las configuraciones incorrectas y las imágenes de riesgo se descubren demasiado tarde, cuando su corrección resulta más disruptiva y es menos probable que los equipos de ingeniería la acepten con agrado.
Conclusión clave
El riesgo de seguridad en Kubernetes se debe, en gran medida, a fallas en los controles a gran escala: exceso de privilegios, políticas insuficientes, configuraciones deficientes de las cargas de trabajo, segmentación débil y visibilidad limitada. Los clústeres más seguros no son los que tienen más herramientas, sino los que cuentan con medidas de protección claras que comienzan antes de la implementación y se mantienen durante la ejecución.
Refuerce la seguridad de Kubernetes con Kaspersky
El riesgo en Kubernetes suele comenzar con configuraciones incorrectas, privilegios excesivos, una aplicación deficiente de las políticas y una visibilidad limitada entre los distintos clústeres. Kaspersky Container Security ayuda a proteger los entornos de orquestación mediante verificaciones de configuración, supervisión de la autenticación y la autorización, control de procesos y de red, y visibilidad de los recursos del clúster.
Fuentes y lecturas adicionales:
