Una guía para la seguridad de Kubernetes

Las organizaciones están incorporando una variedad de nuevas tecnologías a su infraestructura de TI a medida que continúan experimentando sus transformaciones digitales. Muchos están adoptando contenedores y Kubernetes, en particular. En un informe de 2020, por ejemplo, el 56% de las organizaciones encuestadas esperaban que su uso de contenedores aumentara en los próximos 12 meses, escribió El proyecto emprendedores. Otra encuesta a la que se hace referencia en el mismo informe encontró que más de las tres cuartas partes (78%) de las organizaciones participantes usaban Kubernetes de una forma u otra.

Estos hallazgos plantean la siguiente pregunta: ¿por qué tantas organizaciones utilizan contenedores y Kubernetes? Para responder a esa pregunta, es imperativo que primero comprenda qué son los contenedores y Kubernetes. Una parte crucial de la ecuación es estar familiarizado con los beneficios que los contenedores y Kubernetes ofrecen a las organizaciones.

Kubernetes define una imagen de contenedor como un «paquete de software listo para ejecutar, que contiene todo lo necesario para ejecutar una aplicación: el código y el tiempo de ejecución que requiere, las bibliotecas del sistema y la aplicación, y los valores predeterminados para cualquier configuración esencial». Al consistir en una aplicación y todas sus dependencias, una imagen de contenedor es independiente. Eso significa que producirá el mismo comportamiento en cualquier máquina que ejecute, independientemente de la infraestructura o el sistema operativo host subyacente de esa máquina.

La portabilidad tampoco es el único beneficio que ofrecen los contenedores. Como se ha señalado en otra parte por Kubernetes, los contenedores permiten a las organizaciones dividir sus aplicaciones en porciones más pequeñas e implementar / administrar dinámicamente esas partes individuales. Dicha funcionalidad permite a los desarrolladores lanzar correcciones y / o nuevas funcionalidades de manera rápida y sencilla sin eliminar una aplicación completa.

Los contenedores no pueden seguir creciendo en número sin afectar finalmente la forma en que las organizaciones hacen negocios. En algún momento, las organizaciones terminarán con demasiados contenedores para que sus administradores los administren manualmente. Es en ese momento cuando las organizaciones podrían considerar optar por una solución como Kubernetes.

Kubernetes, una plataforma de orquestación de contenedores de código abierto, ayuda a las organizaciones a optimizar el proceso de administración de sus cargas de trabajo y servicios en contenedores. Por ejemplo, los administradores pueden usar Kubernetes para especificar el estado deseado de sus contenedores implementados eliminando contenedores existentes o incluso creando nuevos. También pueden automatizar el proceso de reemplazar contenedores que fallan o matar a otros que no cumplen con los controles de salud definidos por el usuario, funcionalidad que les permite mantener sus aplicaciones y otros servicios compatibles con contenedores siempre en ejecución.

A pesar de los beneficios mencionados anteriormente, muchas organizaciones están sufriendo incidentes de seguridad con sus implementaciones de contenedores y Kubernetes. La edición de otoño de 2020 del “Estado de la seguridad de contenedores y Kubernetes”Informó que el 90% de los encuestados había experimentado un incidente de seguridad en sus entornos de contenedor y Kubernetes durante los últimos 12 meses. En una nota relacionada, casi la mitad (44%) de los que respondieron a esa encuesta dijeron que habían retrasado el traslado de aplicaciones al desarrollo como resultado de problemas de seguridad.

Afortunadamente, hay muchas cosas que las organizaciones pueden hacer para proteger sus contenedores y las implementaciones de Kubernetes. Este artículo se centrará en el uso de las organizaciones de dos tipos diferentes de políticas: políticas de red y políticas de seguridad de pod. Luego explicará qué puede hacer cada una de estas políticas y cómo pueden proteger a las organizaciones en consecuencia.

Kubernetes explica en otra parte de su documentación que los administradores pueden usar políticas de red para especificar cómo les gustaría que un pod específico, o un grupo de uno o más contenedores que comparten recursos de red, se comuniquen con otros pods y entidades de red. Normalmente, las políticas de red constan de tres identificadores: pods permitidos, espacios de nombres y bloques de IP. Esos identificadores permiten a los administradores hacer cumplir la Política de red y, por lo tanto, dar forma al tráfico que va y emana de un pod o grupo de pods seleccionado.

Los administradores tienen motivos para considerar el uso de políticas de red en un contexto de seguridad debido a la forma en que los pods se comunican de forma predeterminada. Si se los deja solos, estos grupos de contenedores no están aislados, lo que significa que aceptan tráfico de cualquier fuente. Esto significa que un actor malintencionado podría comprometer un solo pod y luego usar la configuración predeterminada de ese pod para comunicarse con todos los demás pods y contenedores en el entorno de Kubernetes. Posteriormente, los administradores pueden utilizar las políticas de red para restringir la comunicación hacia y desde un pod o grupo de pods seleccionado.

También hay una «opción nuclear» disponible para los administradores. De hecho, pueden crear una política de red «predeterminada-denegar todo» que aísla eficazmente todos los pods. Esto significa que solo se permiten las conexiones enumeradas en otras políticas de red de Kubernetes.

StackRox escribió en 2019 sobre la justificación para adoptar tal política:

Sin una política de este tipo, es muy fácil encontrarse con un escenario en el que elimine una política de red, con la esperanza de prohibir las conexiones enumeradas en ella, pero descubra que el resultado es que todos las conexiones a algunos pods de repente se permiten, incluidas las que no estaban permitidas antes. Tal situación ocurre cuando la política de red que eliminó fue la única que se aplicó a un pod en particular, lo que significa que la eliminación de la política de red hizo que el pod se volviera «no aislado».

Sin embargo, al elaborar una regla de «denegar todo por defecto», es importante que los administradores recuerden que las políticas de red son recursos con espacios de nombres. Por lo tanto, los administradores deberán crear la misma política «predeterminada-denegar todo» para cada espacio de nombres dentro del cual les gustaría aislar sus pods.

Además de gestionar la comunicación entre los pods, los administradores también deben controlar quién puede acceder a los pods y sus contenedores. Este esfuerzo comienza con el uso de lo que se conoce como contexto de seguridad. Como explica Kubernetes en su sitio web, un contexto de seguridad especifica la configuración de control de acceso o privilegios para un pod o contenedor seleccionado. Los ejemplos de contextos de seguridad incluyen el control de acceso discrecional, que limita el permiso para acceder a un objeto en función de ID de usuario (UID) e ID de grupo (GID) específicos, así como privilegios de Linux, que asigna algunos privilegios pero no todos los superderechos que son disponible para un usuario root.

Kubernetes permite a los administradores hacer cumplir sus contextos de seguridad deseados mediante Políticas de seguridad de pod (PSP), que contienen especificaciones sobre las condiciones en las que se permite que un módulo se ejecute dentro de un sistema. Sin embargo, no todas las políticas de seguridad de los pods son iguales. Estos recursos a nivel de clúster vienen en los siguientes tres tipos:

• Privilegiado: Las políticas de seguridad de los pods no tienen restricciones. Como tal, este tipo de políticas generalmente cubren cargas de trabajo a nivel de sistema e infraestructura que caen dentro del ámbito de los usuarios privilegiados y confiables. Los administradores pueden hacer cumplir este tipo de política al no aplicar ninguna restricción en lugar de crear una política específica.
• Línea de base / Predeterminado: Estos tipos de políticas de seguridad de pods son un poco más restringidos que los marcos privilegiados. Si bien su objetivo es facilitar que los administradores ayuden a sus organizaciones a adoptar cargas de trabajo comunes en contenedores, las políticas de seguridad de pod de línea base / predeterminadas están diseñadas para evitar escaladas de privilegios conocidos. Por lo tanto, estas reglas atraen a los operadores de aplicaciones y a los desarrolladores de aplicaciones no críticas.
• Restringido: Con mucho, la categoría más restrictiva, las políticas de seguridad de pods restringidas buscan fortalecer los pods contra las amenazas digitales, incluso sacrificando algo de compatibilidad. Las políticas de seguridad de pods restringidas funcionan mejor para los operadores y desarrolladores de aplicaciones que son críticas para la seguridad. También son óptimos en los casos en que están involucrados usuarios de baja confianza.

Para usar una política de seguridad de pod, los administradores deben crear una política con ciertos contextos de seguridad en mente. Luego, deben autorizar la cuenta de servicio del pod de destino o del usuario solicitante permitiendo el verbo «usar» en la política de seguridad del pod de destino resultante. De lo contrario, la regla no hará nada. Finalmente, pueden activar la política al habilitando el controlador de admisión.

Sin embargo, las políticas de seguridad de pod no se usan tan ampliamente como antes. StackRox escribió que este panorama cambiante se reduce a ciertas deficiencias entre Políticas de seguridad de pod:

Como su nombre lo indica, los PSP solo se aplican a los pods, lo que hace que su cobertura sea limitada, y también introducen complejidad y gastos generales que deben administrarse para cada implementación. Los PSP no son tan flexibles como otras opciones como OPA Gatekeeper, que proporciona un controlador de admisión de Kubernetes en la parte superior del motor de políticas de OPA para hacer cumplir de manera flexible las políticas en los pods y otros tipos de recursos. Algunas plataformas de Kubernetes, como Azure Kubernetes Service (AKS), han optado por desaprobar el soporte para las políticas de seguridad de pod y, en su lugar, implementar la aplicación de políticas mediante OPA Gatekeeper.

Según una publicación en el blog de Kubernetes, OPA Gatekeeper abre la posibilidad de que los usuarios aprovechen las configuraciones y no el código para personalizar el control de admisión a los pods y sus respectivos contenedores. Este recurso también permite a los usuarios mirar más allá de un solo objeto en evaluación al obtener información sobre el estado de todo el clúster.

Este artículo proporciona una breve descripción general de cómo las organizaciones pueden comenzar a abordar la seguridad en sus contenedores y entornos de Kubernetes. Dicho esto, no aborda la seguridad en su totalidad. Por ejemplo, no aborda cómo las organizaciones pueden tener cuidado al extraer imágenes de otras fuentes, y no brinda orientación sobre cómo los administradores pueden escanear esas imágenes en busca de debilidades conocidas. La publicación del blog tampoco explica cómo los administradores pueden usar las configuraciones para administrar de manera efectiva los secretos dentro de sus entornos de contenedores y Kubernetes.

Para obtener más recomendaciones sobre cómo los administradores pueden proteger los contenedores y Kubernetes de sus empleadores, revise los conceptos de seguridad de Kubernetes. aquí.

Sobre el Autor: David Bisson es un escritor de seguridad de la información y adicto a la seguridad. Es un editor colaborador de Security Intelligence de IBM, el blog The State of Security de Tripwire y escritor colaborador de Bora. También produce con regularidad contenido escrito para Zix y otras empresas en el ámbito de la seguridad digital.