NSA y CISA: aquí se explica cómo mejorar la seguridad de su clúster de Kubernetes

La Agencia de Seguridad Nacional (NSA) y la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) han publicado una guía actualizada sobre cómo fortalecer Kubernetes para administrar aplicaciones de contenedores.

Kubernetes es un sistema de código abierto que automatiza la implementación, el escalado y la gestión de aplicaciones que se ejecutan en contenedores.

La guía actualizada actualiza el primer Informe técnico de ciberseguridad de las dos agencias con respecto a la guía de refuerzo de Kubernetes de agosto de 2021. CISA dice que la actualización contiene detalles y explicaciones adicionales basados ​​en los comentarios de la industria, incluida información más detallada sobre el registro y la detección de amenazas, además de otras aclaraciones.

VER: ¿Qué es la computación en la nube? Todo lo que necesitas saber sobre la nube explicado

Algunas de las actualizaciones son sutiles pero importantes para quienes protegen los clústeres de Kubernetes. NSA y CISA no enumeran cuáles son los cambios en la guía actualizada, pero las recomendaciones iniciales no se cumplieron con la aprobación universal.

Por ejemplo, NCC Group señaló que los consejos sobre la autenticación de Kubernetes eran «en gran parte incorrectos cuando afirman que Kubernetes no proporciona un método de autenticación de forma predeterminada», mientras que la mayoría de las implementaciones de clientes que NCC Group había revisado «admiten autenticación de token y certificación, las cuales son compatible de forma nativa». NCC Group desaconsejó ambos para cargas de producción porque Kubernetes no admite la revocación de certificados, lo que puede ser un problema si un atacante obtuvo acceso a un certificado emitido para cuentas privilegiadas. La guía actualizada ahora dice que «varios mecanismos de autenticación de usuarios son compatibles pero no están habilitados de forma predeterminada».

De lo contrario, los puntos clave del documento original parecen no haber cambiado. Examina el endurecimiento dentro del contexto de los diseños de clúster típicos de Kubernetes que incluyen el plano de control, los nodos de trabajo (para ejecutar aplicaciones en contenedores para el clúster) y los pods para contenedores alojados en estos nodos. Estos clústeres suelen estar alojados en la nube y en múltiples nubes en AWS, Azure, Google y otros lugares.

Las agencias sostienen que Kubernetes es comúnmente objeto de robo de datos, robo de energía computacional o denegación de servicio. Históricamente, se han utilizado fallas en Kubernetes y varias dependencias, así como configuraciones incorrectas, para implementar criptomineros en la infraestructura de la víctima.

También sostiene que Kubernetes está expuesto a importantes riesgos en la cadena de suministro porque los clústeres a menudo tienen dependencias de software y hardware creadas por desarrolladores externos.

Por ejemplo, los analistas de seguridad advirtieron el año pasado sobre ataques contra clústeres de Kubernetes a través de motores de flujo de trabajo de contenedores Argo Workflows mal configurados para clústeres K8.

Además de los riesgos de la cadena de suministro, otros actores clave en el modelo de amenazas de las agencias incluyen amenazas internas y externas maliciosas. Estos ayudan a definir sus recomendaciones de endurecimiento.

Por ejemplo, existe un caso común en la nube en el que las cargas de trabajo que no administra un clúster de Kubernetes determinado comparten la misma red física. En ese caso, una carga de trabajo puede tener acceso al kubelet y a los componentes del plano de control, como el servidor API. Por lo tanto, las agencias recomiendan el aislamiento a nivel de red.

Las agencias brindan consejos sobre cómo garantizar un aislamiento estricto de la carga de trabajo entre los pods que se ejecutan en el mismo nodo en un clúster, dado que Kubernetes no garantiza esta separación de forma predeterminada.

Al anunciar la guía actualizada, la NSA dice: «Las acciones principales incluyen el escaneo de contenedores y pods en busca de vulnerabilidades o configuraciones incorrectas, ejecutar contenedores y pods con los menos privilegios posibles y usar separación de red, firewalls, autenticación sólida y auditoría de registros».

Las agencias también recomiendan revisiones periódicas de la configuración de Kubernetes y análisis de vulnerabilidades para garantizar que se tengan en cuenta los riesgos adecuados y se apliquen los parches de seguridad.

VER: Hay una escasez crítica de mujeres en ciberseguridad y debemos hacer algo al respecto.

Pero parchear no es fácil en el contexto de Kubernetes. CISA publica periódicamente alertas sobre nuevas vulnerabilidades relacionadas con Kubernetes. En febrero, por ejemplo, advirtió sobre una falla crítica en la escalada de privilegios (puntuación de gravedad de 8,8 sobre 10), CVE-2022-23652, que afectó al proxy inverso del proxy de cápsula para Capsule Operator.

Pero como señala NCC Group: «parchar todo es difícil», en parte debido a la presión de evitar el tiempo de inactividad, pero también porque las vulnerabilidades abarcan Kubernetes, Containerd, runc, el kernel de Linux y más.

«Esto es algo con lo que Kubernetes puede ayudar, ya que todo el concepto de orquestación tiene como objetivo mantener los servicios en funcionamiento incluso cuando los nodos se conectan y desconectan. A pesar de esto, todavía vemos clientes que ejecutan nodos a los que no se les han aplicado parches en varios meses. , o incluso años. (Como sugerencia, el tiempo de actividad del servidor no es una insignia de honor tanto como solía ser; es más probable que indique que está ejecutando un kernel obsoleto) «, señaló NCC Group.

Deja un comentario