Bienvenido
Una guía para la seguridad de Kubernetes

Una guía para la seguridad de Kubernetes

Las organizaciones están incorporando una variedad de nuevas tecnologías a su infraestructura de IT  a medida que continúan experimentando sus transformaciones digitales. Muchos están adoptando contenedores y Kubernetes, en particular. En un informe 2020, por ejemplo, el 56% de las organizaciones encuestadas esperaban utilizar contenedores para aumentar en los próximos 12 meses, escribió The Enterprisers Project. 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.

Contenedores

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 cualquier tiempo de ejecución que requiera, las bibliotecas de aplicaciones y sistemas, 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ñaló Kubernetes en otra parte, 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 liberar rápida y fácilmente arreglos y / o nuevas funcionalidades sin tener que eliminar una aplicación completa.

Kubernetes

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.

Una plataforma de orquestación de contenedores de código abierto, Kubernetes ayuda a las organizaciones a agilizar 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 las verificaciones de estado definidas por el usuario, funcionalidad que les permite mantener sus aplicaciones y otros servicios compatibles con contenedores siempre en ejecución.

Con las nuevas tecnologías vienen nuevos riesgos

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 2020 del “Estado de la seguridad de los contenedores y Kubernetes” informó que el 2019% de la encuesta los encuestados habían experimentado un incidente de seguridad en su contenedor y entornos de Kubernetes durante los últimos 44 meses. En una nota relacionada, casi la mitad (44%) de los encuestados en esa encuesta dijeron que habían retrasado la transición 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.

Políticas de red de Kubernetes

Kubernetes explica en otra parte de su documentación que los administradores pueden usar las 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” a disposición de 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 dicha política, 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 de repente se permiten las conexiones a algunas cápsulas, 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 “por defecto-denegar todo” para cada espacio de nombres dentro del cual les gustaría aislar sus pods.

Políticas de seguridad de pod

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 las políticas de seguridad de pod (PSP), que contienen especificaciones sobre las condiciones en las que se permite que un pod 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 pod 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 pod son un poco más restringidos que privilegiados marcos. 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 pods 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 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 al usuario solicitante o la cuenta de servicio del pod de destino permitiendo el verbo “usar” en la Política de seguridad del pod de destino. De lo contrario, la regla no hará nada. Finalmente, pueden activar la política habilitando el controlador de admisión.

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

Como su nombre lo indica, los PSP solo se aplican a los pods, por lo que su cobertura es 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 la compatibilidad con 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 capacidad 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.

Solo el comienzo de la seguridad

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 proporciona 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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *