Seguridad de Kubernetes 101: aspectos básicos y mejores prácticas
Proteger Kubernetes puede parecer una tarea complicada y engorrosa. Al ser un sistema muy complejo compuesto por una serie de componentes diferentes, Kubernetes no es algo que se pueda proteger simplemente habilitando un módulo de seguridad o instalando una herramienta.
Por el contrario, la seguridad de Kubernetes requiere que los equipos contemplen todos los tipos de riesgo de seguridad que pueden afectar a las distintas capas y servicios de un clúster de Kubernetes. Por ejemplo, deben saber cómo proteger los nodos, las redes, los pods y los datos de Kubernetes, entre otros.
Además, los administradores de Kubernetes necesitan conocer qué herramientas ofrece Kubernetes de forma nativa para abordar los problemas de seguridad y qué tipos de herramientas de seguridad de terceros tendrán que integrar con sus clústeres para suplir las carencias. Este es un tema igualmente complejo porque, aunque Kubernetes no es una plataforma de seguridad, proporciona ciertos tipos de herramientas de seguridad nativas, como el control de acceso basado en roles (RBAC).
Todo esto puede parecer abrumador cuando uno es nuevo en Kubernetes y está tratando de entender cómo funciona todo el asunto, por no hablar de cómo mantenerlo seguro. Pero los conceptos son en realidad bastante sencillos si se dividen en partes más pequeñas y digeribles. Con ese fin, en este artículo repasamos las diversas facetas de la seguridad de Kubernetes y explicamos los aspectos básicos de cada una de ellas, así como las mejores prácticas para proteger Kubernetes en cada capa y nivel de servicio.
Seguridad de Kubernetes, parte por parte
Tal vez la forma más sencilla de abordar la seguridad de Kubernetes sea considerar los tipos de riesgos que afectan a cada parte de la pila de Kubernetes y luego identificar las herramientas y los recursos disponibles para ayudar a protegerlos.
Seguridad de los nodos
Los nodos son los servidores que componen los clústeres de Kubernetes. Por lo general, los nodos ejecutan alguna versión de Linux, aunque los nodos de trabajo pueden ejecutar Windows. Los nodos pueden ser máquinas virtuales o servidores bare-metal, pero la diferencia no importa realmente desde el punto de vista de la seguridad.
Para proteger los nodos de Kubernetes, es aconsejable que adopte las mismas estrategias de seguridad que utilizaría con cualquier otro tipo de servidor. Algunas de estas estrategias son:
- Eliminar aplicaciones, bibliotecas y otros componentes superfluos del sistema operativo para minimizar la superficie de ataque. Aprovisionar los nodos con distribuciones de Linux minimalistas, como Alpine Linux es una práctica recomendada.
- Eliminar las cuentas de usuario innecesarias.
- Asegurarse de que no se ejecute nada como root a menos que sea estrictamente necesario.
- Siempre que sea posible, desplegar marcos de endurecimiento (hardening) del OS, como AppArmor o SELinux.
- Recopilar y analizar los registros del OS para detectar posibles brechas.
Si tiene experiencia en la protección de servidores a nivel de sistema operativo en cualquier tipo de entorno, es probable que ya sepa cómo gestionar la seguridad de los nodos Kubernetes. A nivel de nodo, las consideraciones de seguridad que se aplican a los nodos que ejecutan Kubernetes no difieren mucho de las de cualquier tipo de servidor.
Tampoco hay diferencias significativas entre la seguridad de un nodo maestro y la de un nodo de trabajo. La seguridad del nodo maestro es un poco más importante, ya que una brecha en un nodo maestro podría causar más daño a su clúster, pero los procedimientos para asegurar el sistema operativo en un nodo maestro son los mismos que para un nodo de trabajo.
Seguridad de la API de Kubernetes
La API de Kubernetes es lo que enlaza los distintos elementos de un clúster, por lo que es uno de los recursos más importantes de Kubernetes que hay que proteger.
La API de Kubernetes está diseñada para ser segura por defecto y solo responderá a las solicitudes que pueda autenticar y autorizar adecuadamente.
Dicho esto, la autenticación y la autorización de la API se rigen por las políticas RBAC que usted haya configurado. Así pues, la API será igual de segura que sus políticas RBAC. La creación de políticas RBAC seguras que apliquen el principio de mínimo privilegio y asignen permisos de forma granular es, por tanto, una práctica básica recomendada para garantizar la seguridad de la API de Kubernetes.
Además, puede mejorar aún más la seguridad de la API utilizando los controladores de admisión. Los controladores de admisión evalúan las solicitudes después de que el servidor de la API las haya autenticado y autorizado. De esta manera, los controladores de admisión proporcionan una segunda capa opcional de defensa contra las solicitudes que no deben ser permitidas. Al habilitar y configurar los controladores de admisión, puede aplicar varias reglas de seguridad relacionadas con las solicitudes de la API. Las reglas disponibles están documentadas aquí.
Por último, las solicitudes de la API pueden protegerse a nivel de red configurando certificados seguros y exigiendo al servidor de la API que sirva las solicitudes en un puerto seguro en lugar de en localhost.
Seguridad de la red de Kubernetes
La seguridad de la red de Kubernetes es similar a la de los pods, ya que comienza con la aplicación de las mejores prácticas que se utilizarían para asegurar cualquier red.
Debe asegurarse de crear, en la medida de lo posible, una arquitectura de red que aísle las workloads de la Internet pública, a menos que necesiten interactuar con ella. También debe desplegar cortafuegos en la puerta de enlace para bloquear el tráfico de los hosts infractores. Asimismo, debe supervisar el tráfico de la red para detectar indicios de una brecha. Todos estos pasos se pueden llevar a cabo utilizando herramientas externas a Kubernetes, como una malla de servicios.
No obstante, Kubernetes también ofrece una cantidad limitada de herramientas nativas que pueden ayudarle a proteger los recursos de red. Estas herramientas están disponibles en forma de políticas de red. Aunque las políticas de red no son una característica de seguridad en sí, los administradores pueden utilizarlas para controlar cómo fluye el tráfico dentro de un clúster de Kubernetes.
De este modo, puede crear políticas de red para, por ejemplo, aislar los pods entre sí a nivel de red o filtrar el tráfico entrante.
Las políticas de red no reemplazan la seguridad de las configuraciones de red fuera de Kubernetes; considérelas más bien un recurso adicional que complementa las reglas de seguridad que incorpora en la arquitectura general de su red.
Seguridad de los pods de Kubernetes
En Kubernetes, un pod es un container o conjunto de containers que se utilizan para ejecutar una aplicación. Para asegurar sus aplicaciones, por tanto, es necesario que asegure sus pods.
Algunos aspectos de la seguridad de los pods requieren prácticas externas a Kubernetes. Es aconsejable que realice pruebas de seguridad en su aplicación antes de su despliegue y que escanee las imágenes de los containers antes de ejecutarlas. Asimismo, debería recopilar los registros de los pods y analizarlos para detectar posibles brechas o usos indebidos.
En cualquier caso, Kubernetes proporciona algunas herramientas nativas que pueden reforzar la seguridad de los pods cuando estos ya se están ejecutando. Algunas de estas estrategias son:
- Políticas RBAC, que pueden utilizarse para gestionar el acceso a los pods por parte de usuarios y servicios dentro del clúster.
- Contextos de seguridad, que definen el nivel de privilegios con el que se ejecutan los pods.
- Políticas de red, que (como se indicó anteriormente) se pueden utilizar para aislar los pods a nivel de red.
- Controladores de admisión, que pueden aplicar reglas adicionales para ampliar las reglas que usted haya establecido basándose en RBAC.
Los tipos de herramientas de seguridad de los pods que utilice y la forma de configurarlos dependerán de la naturaleza de sus workloads. No existe un enfoque único para la seguridad de los pods. Algunos pods pueden estar completamente aislados unos de otros a nivel de red, por ejemplo, mientras que otros necesitan poder comunicarse.
Sin embargo, sean cuales sean sus requisitos específicos, debe evaluar los recursos disponibles para proteger los pods de Kubernetes y asegurarse de aprovecharlos al máximo.
Seguridad de los datos de Kubernetes
Kubernetes no almacena ningún dato aparte de los datos no persistentes ubicados en los pods mientras están en ejecución y los datos de registro almacenados en los nodos. Normalmente, los datos que sus clústeres crean y/o a los acceden estarán en algún tipo de sistema de almacenamiento externo que interactúa con Kubernetes a través de un plugin de almacenamiento.
Por lo tanto, para asegurar los datos asociados a Kubernetes, le recomendamos seguir las mismas mejores prácticas que utilizaría para asegurar los datos en cualquier sistema de almacenamiento a gran escala. Cifre los datos en reposo siempre que sea posible. Utilice herramientas de control de acceso para restringir quién puede acceder a los datos. Asegúrese de que los servidores que gestionan sus grupos de almacenamiento están debidamente bloqueados. Realice copias de seguridad para protegerse contra el robo de datos o los ataques de ransomware.
Por lo que respecta a las cantidades relativamente pequeñas de datos presentes de forma nativa dentro de los pods y nodos de Kubernetes, Kubernetes no ofrece ninguna herramienta especial para protegerlos. Pero esto es algo que puede hacer protegiendo sus pods y nodos con las mejores prácticas que le hemos recomendado.
Otros recursos de seguridad de Kubernetes
Además de las prácticas de seguridad específicas de los componentes que hemos descrito, los administradores deben conocer otros recursos de seguridad para Kubernetes.
Kubernetes puede mantener opcionalmente registros granulares de las acciones realizadas en un clúster, quién las realizó y cuáles fueron los resultados. Utilizando estos registros de auditoría, puede auditar exhaustivamente sus clústeres para detectar posibles problemas de seguridad en tiempo real, así como investigar los incidentes de seguridad a posteriori.
Para utilizar los registros de auditoría, primero debe crear una política de auditoría que defina cómo Kubernetes registrará los eventos. La documentación de Kubernetes incluye información completa sobre cómo configurar políticas de auditoría.
Por otra parte, dado que Kubernetes no proporciona herramientas que le permitan analizar los registros de auditoría a gran escala, es probable que necesite transmitir los registros de auditoría a una plataforma externa de monitorización u observabilidad para que le ayude a detectar anomalías y le alerte de posibles brechas. De lo contrario, solo podrá supervisar los eventos de auditoría manualmente, lo que no es práctico a gran escala.
Namespaces
En Kubernetes, los namespaces pueden utilizarse para aislar diferentes workloads entre sí.
Aunque puede ejecutar todo dentro de un único namespace si lo desea, lo más recomendable desde el punto de vista de la seguridad es crear diferentes namespaces para cada equipo y/o tipo de workload en su clúster. Por ejemplo, es posible utilizar namespaces distintos para separar su entorno de desarrollo y prueba del de producción.
Gestionar múltiples namespaces aumenta en cierto modo la complejidad administrativa de Kubernetes, porque será necesario crear diferentes políticas RBAC para cada namespace en muchos casos (pero no en todos). De todos modos, el esfuerzo extra merece la pena teniendo en cuenta que así se minimiza el posible impacto de una brecha.
Uso de herramientas de seguridad externas con Kubernetes
A pesar de que Kubernetes dispone de ciertos tipos de herramientas que permiten reforzar la seguridad de los recursos que se ejecutan en su clúster, no está diseñado para detectar o gestionar los incidentes de seguridad.
Para gestionar la seguridad de Kubernetes a gran escala, lo más probable es que tenga que recurrir a herramientas de seguridad externas. Estas herramientas pueden realizar varias funciones de seguridad importantes como:
- Escanear sus políticas RBAC, contextos de seguridad y otros datos de configuración para identificar errores de configuración que podrían provocar problemas de seguridad.
- Proporcionar la funcionalidad de escaneo de imágenes de aplicaciones y containers, que puede utilizar para crear una pipeline con seguridad automatizada que se incluirá en sus clústeres de Kubernetes.
- Recopilar, agregar y analizar los registros de aplicaciones y de auditoría para ayudarle a detectar anomalías que puedan indicar una brecha.
Existen diversas herramientas de seguridad externas para Kubernetes, entre las que se incluye Sysdig, que fue creada para ayudar a los equipos de DevOps a asegurar todas las capas de Kubernetes y otros entornos nativos de la nube.