Seguridad y observabilidad de Kubernetes

Capítulo 1. Estrategia de Seguridad y Observabilidad

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En este capítulo, cubriremos una visión general de alto nivel de cómo puedes construir una estrategia de seguridad y observabilidad para tu implementación de Kubernetes. Los capítulos siguientes tratarán cada uno de estos conceptos con más detalle. Necesitas pensar en una estrategia de seguridad cuando estés en la fase piloto/preproducción de tu viaje por Kubernetes, así que si formas parte del equipo de seguridad, este capítulo es muy importante. Si formas parte del equipo de redes, plataformas o aplicaciones, este capítulo muestra cómo puedes formar parte de la estrategia de seguridad y analiza la importancia de la colaboración entre los equipos de seguridad, plataformas y aplicaciones.

Cubriremos los siguientes conceptos que te guiarán en tu estrategia de seguridad y observabilidad:

• En qué se diferencia la seguridad de Kubernetes de los métodos de seguridad tradicionales

• El ciclo de vida de la implementación de aplicaciones (cargas de trabajo) en un clúster de Kubernetes y las buenas prácticas para cada etapa

• Cómo debes implementar la observabilidad para contribuir a la seguridad

• Marcos de seguridad conocidos y cómo utilizarlos en tu estrategia de seguridad

Seguridad para Kubernetes: Un mundo nuevo y diferente

En esta sección destacaremos en qué se diferencia Kubernetes y por qué los métodos de seguridad tradicionales no funcionan en una implementación de Kubernetes.

A medida que las cargas de trabajo se trasladan a la nube, Kubernetes es el orquestador más común de para gestionarlas. La razón por la que Kubernetes es popular es su naturaleza declarativa: Abstrae los detalles de la infraestructura y permite a los usuarios especificar las cargas de trabajo que quieren ejecutar y los resultados deseados. El equipo de aplicaciones no tiene que preocuparse de cómo se despliegan las cargas de trabajo, dónde se ejecutan, ni de otros detalles como las redes; sólo tiene que establecer configuraciones en Kubernetes para desplegar sus aplicaciones.

Kubernetes logra esta abstracción gestionando la creación, el apagado y el reinicio de la carga de trabajo. En una implementación típica, una carga de trabajo puede programarse en cualquier recurso disponible en una red (host físico o máquina virtual) en función de los requisitos de la carga de trabajo. Un grupo de recursos en los que se ejecuta una carga de trabajo se conoce como clúster Kubernetes. Kubernetes monitorea el estado de las cargas de trabajo (que se despliegan como pods en Kubernetes) y toma las medidas correctivas necesarias (por ejemplo, reiniciar los nodos que no responden). También gestiona todas las redes necesarias para que los pods y los hosts se comuniquen entre sí. Tienes la opción de decidir la tecnología de red seleccionando entre un conjunto de complementos de red compatibles. Aunque existen algunas opciones de configuración para el plug-in de red, no podrás controlar directamente el comportamiento de la red (ni para la asignación de direcciones IP ni en las configuraciones típicas en las que el nodo está programado).

Kubernetes es un mundo diferente para los equipos de seguridad. Su método tradicional en sería construir una "red de máquinas" y luego incorporar las cargas de trabajo (aplicaciones). Como parte de la integración, el proceso consistía en asignar IP, actualizar la red según fuera necesario, y definir y aplicar reglas de control de acceso a la red. Tras estos pasos, la aplicación estaba lista para los usuarios. Este proceso garantizaba que los equipos de seguridad tuvieran un gran control y pudieran incorporar y proteger las aplicaciones con facilidad. Las aplicaciones eran fáciles de proteger, ya que eran estáticas en cuanto a las IP asignadas, el lugar de implementación, etc.

En el mundo de Kubernetes, las cargas de trabajo se construyen como imágenes de contenedor y se implementan en un clúster de Kubernetes mediante un archivo de configuración (yaml). Esto suele integrarse en el proceso de desarrollo, y la mayoría de los equipos de desarrollo utilizan la integración continua (CI) y la entrega continua (CD) para garantizar una entrega rápida y fiable del software. Lo que esto significa es que el equipo de seguridad tiene una visibilidad limitada del impacto de cada cambio en la aplicación sobre la seguridad del clúster. Añadir un paso de revisión de la seguridad a este proceso es contraproducente, ya que el único lugar lógico para añadirlo es cuando se está confirmando el código. El proceso de desarrollo después de ese punto está automatizado, e interrumpirlo entraría en conflicto con el modelo CI/CD. Entonces, ¿cómo puedes asegurar las cargas de trabajo en este entorno?

Para entender cómo proteger las cargas de trabajo en Kubernetes, es importante comprender las distintas etapas que forman parte de la implementación de una carga de trabajo.

Implementación de una carga de trabajo en Kubernetes: Seguridad en cada etapa

En la sección anterior, describimos el reto de asegurar las aplicaciones que se despliegan utilizando la canalización CI/CD. Esta sección describe el ciclo de vida de la implementación de la carga de trabajo en un clúster Kubernetes y explica cómo proteger cada etapa. Las tres etapas del despliegue de la carga de trabajo son la compilación, el despliegue y el tiempo de ejecución. A diferencia de las aplicaciones cliente-servidor tradicionales, en las que una aplicación existía en un servidor (o en un clúster de servidores), las aplicaciones en una implementación de Kubernetes están distribuidas, y la red del clúster de Kubernetes es utilizada por las aplicaciones como parte de su funcionamiento normal. He aquí algunas cosas a tener en cuenta debido a esta configuración:

• Debes tener en cuenta las buenas prácticas de seguridad a medida que se construyen las cargas de trabajo y la infraestructura. Esto es importante debido al hecho de que las aplicaciones en Kubernetes se implementan utilizando la canalización CI/CD.

• Debes tener en cuenta las buenas prácticas de seguridad cuando se implementa un clúster de Kubernetes y se incorporan las aplicaciones.

• Por último, las aplicaciones utilizan la infraestructura y la red del clúster Kubernetes para su funcionamiento normal, y debes tener en cuenta las buenas prácticas de seguridad para el tiempo de ejecución de las aplicaciones.

La Figura 1-1 ilustra las distintas etapas y aspectos a tener en cuenta a la hora de asegurar las cargas de trabajo en un entorno Kubernetes.

Figura 1-1. Fases de implementación de la carga de trabajo y seguridad en cada fase

Los recuadros que aparecen debajo de cada etapa describen diversos aspectos de la seguridad que debes tener en cuenta para esa etapa:

• La etapa de construcción es en la que se crea (build) el software para tu carga de trabajo (aplicación) y se construyen los componentes de la infraestructura (host o máquinas virtuales) para alojar las aplicaciones. Esta etapa forma parte del ciclo de desarrollo, y en la mayoría de los casos es responsabilidad del equipo de desarrollo. En esta etapa consideras la seguridad para la canalización CI/CD, implementas la seguridad para los repositorios de imágenes, escaneas las imágenes en busca de vulnerabilidades y endureces el sistema operativo anfitrión. Tienes que asegurarte de que aplicas las buenas prácticas para asegurar el registro de imágenes y evitar poner en peligro las imágenes del registro de imágenes. Esto se hace generalmente asegurando el acceso al registro de imágenes, aunque muchos usuarios tienen registros privados y no permiten imágenes de registros públicos. Por último, debes tener en cuenta las buenas prácticas para la gestión de secretos; los secretos son como contraseñas que permiten el acceso a los recursos de tu clúster. Trataremos estos temas en detalle en el Capítulo 3. Te recomendamos que, cuando consideres la seguridad de esta etapa, colabores con el equipo de seguridad para que la seguridad de esta etapa esté alineada con tu estrategia de seguridad general.

• La siguiente etapa, desplegar, es en la que configuras la plataforma que ejecuta tu implementación de Kubernetes y despliegas cargas de trabajo. En esta etapa tienes que pensar en las buenas prácticas de seguridad para configurar tu clúster de Kubernetes y proporcionar acceso externo a las aplicaciones que se ejecutan dentro de tu clúster de Kubernetes. También tienes que tener en cuenta los controles de seguridad, como las políticas para limitar el acceso a las cargas de trabajo (políticas de seguridad de los pods), las políticas de red para controlar el acceso de las aplicaciones a los componentes de la plataforma, y el control de acceso basado en roles (RBAC) para el acceso a los recursos (por ejemplo, la creación de servicios, la creación de espacios de nombres y la adición/cambio de etiquetas a los pods). En la mayoría de las empresas, el equipo de la plataforma es responsable de esta etapa. Como miembro del equipo de plataforma, tienes que colaborar tanto con el equipo de desarrollo como con el de seguridad para aplicar tu estrategia de seguridad.

• La etapa final es la de tiempo de ejecución, en la que has desplegado tu aplicación y está operativa. En esta etapa tienes que pensar en la seguridad de la red, que implica controles mediante políticas de red, defensa frente a amenazas (utilizando técnicas para detectar y prevenir la actividad maliciosa en el clúster) y controles de seguridad empresarial como el cumplimiento, la auditoría y el cifrado. El equipo de seguridad es responsable de esta fase de la implementación. Como miembro del equipo de seguridad, tienes que colaborar con los equipos de plataforma y desarrollo mientras diseñas e implementas la seguridad en tiempo de ejecución. La colaboración entre equipos (desarrollo, plataforma y seguridad) es muy importante para construir una estrategia de seguridad eficaz. Te recomendamos que te asegures de que todos estos equipos están alineados.

Ten en cuenta que, a diferencia de lo que ocurre con las estrategias de seguridad tradicionales, en las que la seguridad se aplica en un punto (como el perímetro), en el caso de un clúster de Kubernetes, tienes que aplicar la seguridad en cada etapa. Además, todos los equipos implicados (aplicación, plataforma y seguridad) desempeñan un papel muy importante en la aplicación de la seguridad, por lo que la clave para aplicar una estrategia con éxito es la colaboración entre los equipos. Recuerda, la seguridad es una responsabilidad compartida. Exploremos cada etapa y las técnicas que puedes utilizar para construir tu estrategia.

Seguridad en el tiempo de construcción: Desplazamiento a la izquierda

Esta sección te guiará a través de varios aspectos de la seguridad en tiempo de compilación con ejemplos.

Escaneado de imágenes

Durante esta etapa, tienes que asegurarte de que las aplicaciones no tienen ningún problema importante sin parchear que se divulgue como enumeraciones comunes de vulnerabilidades (CVE) en la Base de Datos Nacional de Vulnerabilidades, y de que el código de la aplicación y sus dependencias se analizan en busca de exploits y segmentos de código vulnerables. Las imágenes que se construyen y entregan como contenedores se escanean para detectar vulnerabilidades críticas o importantes no parcheadas divulgadas como CVE. Esto suele hacerse cotejando la imagen base y todos sus paquetes con una base de datos que rastrea los paquetes vulnerables. Para llevar a cabo el escaneado, existen varias herramientas, tanto de código abierto como comerciales, que están a tu disposición. Por ejemplo, Whitesource, Snyk, Trivy, Anchor e incluso proveedores en la nube como Google ofrecen escaneado de imágenes de contenedores. Te recomendamos que elijas una solución de escaneado que entienda cómo se construyen los contenedores y escanee no sólo el sistema operativo del host, sino también las imágenes base de los contenedores. Dada la naturaleza dinámica de las Implementaciones de Kubernetes, es muy importante que asegures la canalización CI/CD; el escaneado del código y de las imágenes debe formar parte de la canalización, y las imágenes que se entregan desde el registro de imágenes deben comprobarse para evitar que se vean comprometidas. Tienes que asegurarte de que se controla el acceso al registro para evitar que se ponga en peligro. El término popular para describir esta etapa es desplazar la seguridad hacia la izquierda, hacia el equipo de desarrollo, también conocido como seguridad por desplazamiento a la izquierda.

Endurecimiento del sistema operativo del host

Aquí debes asegurarte de que la aplicación que se implanta está restringida a tener los privilegios necesarios en el host donde se implanta. Para conseguirlo, debes utilizar un sistema operativo de host reforzado que admita controles que permitan restringir las aplicaciones sólo a los privilegios necesarios, como las llamadas al sistema y el acceso al sistema de archivos. Esto te permite mitigar eficazmente los ataques relacionados con la escalada de privilegios, en los que se utiliza una vulnerabilidad del software que se implementa en un contenedor para acceder al sistema operativo anfitrión.

Minimizar la superficie de ataque: Imágenes contenedor base

Te recomendamos que revises la composición de la imagen del contenedor y minimices los paquetes de software que componen la imagen base para incluir sólo los paquetes que sean absolutamente necesarios para que tu aplicación funcione. En las imágenes contenedoras basadas en Dockerfile, puedes empezar con una imagen padre y luego añadir tu aplicación a la imagen para crear una imagen contenedor. Por ejemplo, puedes empezar creando una imagen base en Docker utilizando la directiva FROM scratch, que creará una imagen mínima. A continuación, puedes añadir tu aplicación y los paquetes necesarios, lo que te dará un control total de la composición de tus imágenes contenedoras y también te ayudará con la gestión de CVE, ya que no tendrás que preocuparte de parchear CVE en paquetes de una imagen contenedor que no sean necesarios para tu aplicación. En caso de que construir una imagen desde cero no sea una opción viable, puedes considerar empezar con una imagen distroless (una imagen de distribución de Linux adelgazada) o una imagen mínima Alpine como imágenes base para tu contenedor.

Estas técnicas te ayudarán a diseñar y aplicar tu estrategia de seguridad en tiempo de compilación. Como parte del equipo de desarrollo, serás responsable de diseñar e implantar la seguridad en tiempo de compilación en colaboración con los equipos de plataforma y seguridad, para garantizar que esté alineada con la estrategia de seguridad global. Advertimos que no hay que creer el mito de que la seguridad por turnos puede ser toda tu estrategia de seguridad. Es incorrecto, y un enfoque ingenuo de la seguridad de las cargas de trabajo. Hay otros aspectos importantes, como la implementación y la seguridad en tiempo de ejecución, que también deben tenerse en cuenta como parte de tu estrategia de seguridad.

Seguridad en tiempo de implementación

La siguiente etapa para asegurar las cargas de trabajo es asegurar la implementación. Para lograrlo, tienes que endurecer tu clúster de Kubernetes donde se despliegan las cargas de trabajo. Necesitarás una revisión detallada de la configuración del clúster de Kubernetes para asegurarte de que se ajusta a las buenas prácticas de seguridad. Empieza por crear un modelo de confianza para los distintos componentes de tu clúster. Un modelo de confianza es un marco en el que revisas un perfil de amenaza y defines mecanismos para responder a ella. Debes aprovechar herramientas como el control de acceso basado en funciones (RBAC), las taxonomías de etiquetas, el gobierno de etiquetas y los controles de admisión para diseñar y aplicar el modelo de confianza. Se trata de mecanismos para controlar el acceso a los recursos y de controles y validaciones que se aplican en el momento de la creación de los recursos. Estos temas se tratan en detalle en los Capítulos 3, 4 y7. Los otros componentes críticos de tu clúster son el almacén de datos de Kubernetes y el servidor API de Kubernetes, y debes prestar mucha atención a detalles como el control de acceso y la seguridad de los datos cuando diseñes el modelo de confianza para estos componentes. Te recomendamos que utilices credenciales sólidas, infraestructura de clave pública (PKI) para el acceso, y seguridad de la capa de transporte (TLS) para el cifrado de datos en tránsito. La seguridad de la APT de Kubernetes y del almacén de datos se trata en detalle en el Capítulo 2.

Debes pensar en el clúster Kubernetes donde se despliegan las cargas de trabajo de misión crítica como una entidad y, a continuación, diseñar un modelo de confianza para la entidad. Esto requiere que revises los controles de seguridad en el perímetro, lo que supondrá un reto debido a las arquitecturas de implementación de Kubernetes; lo trataremos en la siguiente sección. Por ahora, supongamos que los productos actuales que se implementan en el perímetro, como las pasarelas de control de acceso web y los cortafuegos de nueva generación, no conocen la arquitectura de Kubernetes. Te recomendamos que abordes esta cuestión creando integraciones con estos dispositivos, que les permitan conocer el contexto del clúster de Kubernetes para que puedan ser eficaces a la hora de aplicar controles de seguridad en el perímetro. De esta forma puedes crear una estrategia de seguridad muy eficaz en la que los dispositivos de seguridad perimetral trabajen conjuntamente con la seguridad implementada dentro de tu clúster Kubernetes. Como ejemplo, digamos que necesitas que estos dispositivos conozcan la identidad de tus cargas de trabajo (dirección IP, puerto TCP/UDP, etc.). Estos dispositivos pueden proteger eficazmente los hosts que componen tu clúster de Kubernetes, pero en la mayoría de los casos no pueden distinguir entre las cargas de trabajo que se ejecutan en un mismo host. Si estás ejecutando en un entorno de proveedor en la nube, puedes utilizar grupos de seguridad, que son cortafuegos virtuales que permiten controlar el acceso a un grupo de nodos (como las instancias EC2 en Amazon Web Services) que alojan cargas de trabajo. Los grupos de seguridad están más alineados con la arquitectura de Kubernetes que los cortafuegos tradicionales y las pasarelas de seguridad; sin embargo, ni siquiera los grupos de seguridad conocen el contexto de las cargas de trabajo que se ejecutan dentro del clúster.

En resumen, cuando consideres la seguridad en tiempo de implementación, debes implantar un modelo de confianza para tu clúster Kubernetes y construir una integración eficaz con dispositivos de seguridad perimetral que protejan tu clúster.

Seguridad en tiempo de ejecución

Ahora que ya tienes una estrategia para asegurar las etapas de creación e implementación de , tienes que pensar en la seguridad en tiempo de ejecución. El término seguridad en tiempo de ejecución se utiliza para varios aspectos de la seguridad de un clúster Kubernetes, por ejemplo en un host que ejecuta software, pero cualquier configuración que proteja al host y a las cargas de trabajo de actividades no autorizadas (por ejemplo, llamadas al sistema, acceso a archivos) también se denomina seguridad en tiempo de ejecución. El Capítulo 4 tratará en detalle la seguridad en tiempo de ejecución del host y de las cargas de trabajo. En esta sección nos centraremos en las buenas prácticas de seguridad necesarias para garantizar el funcionamiento seguro de la red de clústeres de Kubernetes. Kubernetes es un orquestador que implementa cargas de trabajo y aplicaciones en una red de hosts. Debes considerar la seguridad de la red como un aspecto muy importante de la seguridad en tiempo de ejecución.

Kubernetes promete una mayor agilidad y un uso más eficiente de los recursos informáticos, en comparación con la partición y el aprovisionamiento estáticos de servidores o máquinas virtuales. Lo hace programando dinámicamente las cargas de trabajo en todo el clúster, teniendo en cuenta el uso de recursos en cada nodo, y conectando las cargas de trabajo en una red plana. Por defecto, cuando se implementa una nueva carga de trabajo, el pod correspondiente puede programarse en cualquier nodo del clúster, con cualquier dirección IP dentro de la dirección IP del pod. Si el pod se reprograma posteriormente en otro lugar, normalmente obtendrá una dirección IP diferente. Esto significa que las direcciones IP de los pods deben tratarse como efímeras. No hay ningún significado a largo plazo o especial asociado a las direcciones IP de los pods o a su ubicación dentro de la red.

Consideremos ahora los enfoques tradicionales de la seguridad de red. Históricamente, en las redes empresariales, la seguridad de la red se implementaba mediante dispositivos de seguridad (o versiones virtuales de dispositivos), como cortafuegos y routers. Las normas aplicadas por estos dispositivos se basaban a menudo en una combinación de la topología física de la red y la asignación de rangos específicos de direcciones IP a diferentes clases de cargas de trabajo.

Como Kubernetes se basa en una red plana, sin ningún significado especial para las direcciones IP de los pods, muy pocos de estos dispositivos tradicionales son capaces de proporcionar ninguna seguridad de red significativa y consciente de la carga de trabajo, y en su lugar tienen que tratar todo el clúster como una entidad única. Además, en el caso del tráfico este-oeste entre dos pods alojados en el mismo nodo, el tráfico ni siquiera pasa por la red subyacente. Así que estos dispositivos no verán este tráfico en absoluto y se limitan esencialmente a la seguridad norte-sur, que asegura el tráfico que entra en el clúster desde fuentes externas y el tráfico que se origina dentro del clúster y se dirige a fuentes fuera del clúster.

Teniendo en cuenta todo esto, debería estar claro que Kubernetes requiere un nuevo enfoque de la seguridad de la red. Este nuevo enfoque debe abarcar una amplia gama de consideraciones, entre las que se incluyen:

• Nuevas formas de aplicar la seguridad de red (qué cargas de trabajo pueden hablar con qué otras cargas de trabajo) que no dependen de significados especiales de direcciones IP o topología de red y que funcionan incluso si el tráfico no atraviesa la red subyacente; la política de red de Kubernetes está diseñada para satisfacer estas necesidades.

• Nuevas herramientas para ayudar a gestionar las políticas de red que apoyan los nuevos procesos de desarrollo y el deseo de que los microservicios aporten una mayor agilidad organizativa, como las recomendaciones de políticas, las previsualizaciones del impacto de las políticas y la puesta en escena de las políticas.

• Nuevas formas de monitorizar y visualizar el tráfico de red, que abarcan tanto vistas holísticas del clúster (por ejemplo, cómo ver fácilmente la red global y el estado de seguridad de la red del clúster) como vistas topográficas específicas para profundizar en una secuencia de microservicios y ayudar a solucionar o diagnosticar problemas de la aplicación.

• Nuevas formas de implantar la detección de intrusos y la defensa frente a amenazas, como la alerta por violación de políticas, la detección de anomalías en la red y la alimentación integrada de amenazas.

• Nuevos flujos de trabajo de reparación, para que las cargas de trabajo potencialmente comprometidas puedan aislarse de forma rápida y segura durante la investigación forense.

• Nuevos mecanismos para auditar la configuración y los cambios de política para el cumplimiento.

• Nuevos mecanismos para auditar los cambios en la configuración y las políticas, y también registros de flujo de red sensibles a Kubernetes para cumplir los requisitos de conformidad (ya que los registros de flujo de red tradicionales se basan en IP y tienen poco significado a largo plazo en el contexto de Kubernetes).

Revisaremos un ejemplo de implementación típica de Kubernetes en una empresa para comprender estos retos. La Figura 1-2 es una representación de un modelo de implementación común para Kubernetes y microservicios en un entorno multicloud. Un entorno multicloud es aquel en el que una empresa implementa Kubernetes en más de un proveedor de nubes (Amazon Web Services, Google Cloud, etc.). Un entorno de nube híbrida es aquel en el que una empresa tiene una implementación de Kubernetes en al menos un entorno de proveedor de nube y una implementación de Kubernetes in situ en su centro de datos. La mayoría de las empresas tienen una estrategia de nube dual y tendrán clústeres ejecutándose en Amazon Web Services (AWS), Microsoft Azure o Google Cloud; un mayor número de empresas también tienen algunas aplicaciones heredadas ejecutándose en sus centros de datos. Las cargas de trabajo en el centro de datos probablemente estarán detrás de una pasarela de seguridad que filtre el tráfico que entra por el perímetro. También es probable que los microservicios que se ejecutan en estas Implementaciones de Kubernetes tengan una o más dependencias de:

• Otros servicios en la nube como AWS RDS o Azure DB

• Puntos finales de API de terceros como Twilio

• Servicios SaaS como Salesforce o Zuora

• Bases de datos o aplicaciones heredadas que se ejecutan en el centro de datos

Es probable que las cargas de trabajo del centro de datos estén detrás de una pasarela de seguridad que filtre el tráfico que entra por el perímetro.

La observabilidad en Kubernetes es la capacidad de obtener información procesable sobre el estado de Kubernetes a partir de las métricas recopiladas (más sobre esto más adelante). Aunque la observabilidad tiene otras aplicaciones, como el monitoreo y la resolución de problemas, también es importante en el contexto de la seguridad de la red. Los conceptos de observabilidad aplicados a los registros de flujo correlacionados con otros metadatos de Kubernetes (etiquetas de pods, políticas, espacios de nombres, etc.) se utilizan para supervisar (y luego asegurar) las comunicaciones entre pods de un clúster de Kubernetes, detectar actividades maliciosas comparando direcciones IP con direcciones IP maliciosas conocidas, y utilizar técnicas basadas en el aprendizaje automático para detectar actividades maliciosas. Estos temas se tratan en la siguiente sección. Como puedes ver en la Figura 1-2, la implementación de Kubernetes plantea retos debido a los silos de datos en cada clúster y a la posible pérdida de visibilidad al asociar una carga de trabajo en un clúster a una carga de trabajo en otro clúster o a un servicio externo.

Figura 1-2. Ejemplo de implementación de Kubernetes en una empresa

Como se muestra en la Figura 1-2, la huella de una aplicación de microservicios suele extenderse más allá de los límites de la nube privada virtual (VPC), y asegurar estas aplicaciones requiere un enfoque diferente del enfoque tradicional de seguridad perimetral. Se trata de una combinación de controles de seguridad de red, observabilidad, defensa frente a amenazas y controles de seguridad empresarial. A continuación trataremos cada uno de ellos.

Controles de seguridad de la red

Los controles de seguridad nativos disponibles de los proveedores de la nube (por ejemplo, Grupos de seguridad de AWS o Grupos de seguridad de red de Azure) o las pasarelas de seguridad (por ejemplo, cortafuegos de nueva generación) en el perímetro de la VPC o centro de datos no comprenden la identidad de un microservicio dentro de un clúster de Kubernetes. Por ejemplo, no puedes filtrar el tráfico hacia o desde un pod o servicio Kubernetes con tus reglas de grupo de seguridad o políticas de cortafuegos. Además, en el momento en que el tráfico de un pod llega a la red de un proveedor de la nube o a un cortafuegos de terceros, el tráfico (dependiendo de la arquitectura del proveedor de la nube) tiene aplicada una traducción de dirección de red de origen (SNAT). En otras palabras, la dirección IP de origen del tráfico de todas las cargas de trabajo del nodo se establece en la IP del nodo, por lo que cualquier tipo de política de permitir/denegar, en el mejor de los casos, tendrá granularidad a nivel de nodo (la dirección IP del nodo).

Las cargas de trabajo de Kubernetes son muy dinámicas y efímeras. Supongamos que un desarrollador realiza un nuevo check-in para una determinada carga de trabajo. El flujo de trabajo automatizado CI/CD se pondrá en marcha, creará una nueva versión del pod (contenedor) y empezará a desplegar esta nueva versión de la carga de trabajo en clústeres Kubernetes. El orquestador de Kubernetes realizará una actualización continua y desplegará nuevas instancias de la carga de trabajo. Todo esto ocurre de forma automatizada, y no hay lugar para flujos de trabajo manuales o fuera de banda para reconfigurar los controles de seguridad para la carga de trabajo recién implementada.

Necesitas una nueva arquitectura de seguridad para proteger las cargas de trabajo que se ejecutan en una infraestructura de nube múltiple o híbrida. Al igual que la implementación de tu carga de trabajo en un clúster Kubernetes, la seguridad de la carga de trabajo tiene que definirse como código, en un modelo declarativo. Los controles de seguridad tienen que ser portátiles entre distribuciones de Kubernetes, nubes, infraestructuras y/o redes. Estos controles de seguridad tienen que viajar con las cargas de trabajo, de modo que si se implementa una nueva versión de la carga de trabajo en una VPC para el servicio Amazon Elastic Kubernetes (EKS), en lugar de en clústeres locales, puedes estar seguro de que los controles de seguridad asociados al servicio se aplicarán sin problemas, sin que tengas que volver a trabajar en ninguna topología de red, configuración fuera de banda de grupos de seguridad o cortafuegos de VPC/perímetro.

Los controles de seguridad de la red se implementan utilizando una solución de política de red que sea nativa de Kubernetes y proporcione controles de acceso granulares. Hay varias implementaciones conocidas de política de red (como Calico, Weave Net, Kube-router, Antrea) que puedes utilizar. Además de aplicar la política en la Capa 3/Capa 4 (TCP/IP), te recomendamos que busques soluciones que admitan la política de la capa de aplicación (como HTTP/HTTPS). También te recomendamos que elijas una solución basada en el popular proxy Envoy, ya que está ampliamente implementado para la política de capa de aplicación. Kubernetes permite la implementación de aplicaciones como microservicios (pequeños componentes que sirven a una parte de la funcionalidad de la aplicación) en una red de nodos. La comunicación entre microservicios se basa en protocolos de aplicación como HTTP. Por lo tanto, se necesitan controles de aplicación granulares que puedan implementarse mediante políticas de capa de aplicación. Por ejemplo, en una aplicación de tres niveles, puede que al microservicio del frontend sólo se le permita utilizar solicitudes basadas en HTTP GET con el microservicio de la base de datos del backend (acceso de lectura) y que no se le permita utilizar HTTP POST con el microservicio de la base de datos del backend (acceso de escritura). Todas estas solicitudes pueden acabar utilizando la misma conexión TCP, por lo que es esencial añadir un motor de políticas que admita controles a nivel de aplicación, como se describe aquí.

Controles de seguridad de la empresa

Ahora que tienes definida la estrategia para los controles de acceso a la red y la observabilidad de , debes considerar otros controles de seguridad que son importantes y frecuentes en las empresas. El cifrado de los datos en tránsito es un requisito crítico para la seguridad y el cumplimiento. Hay varias opciones a considerar para el cifrado utilizando enfoques tradicionales, como el cifrado basado en TLS en tus cargas de trabajo; TLS mutuo, que forma parte de una plataforma de malla de servicios; o un enfoque basado en VPN como Wireguard (que ofrece una VPN basada en clave criptográfica).

Te recomendamos que aproveches la recopilación de datos que forma parte de tu estrategia de observabilidad de para crear los informes necesarios que te ayuden con los requisitos de cumplimiento de normas como PCI, HIPAA, GDPR y SOC 2. También debes tener en cuenta la capacidad de garantizar el cumplimiento continuo, y puedes aprovechar la naturaleza declarativa de Kubernetes para ayudar con el diseño y la implementación del cumplimiento continuo. Por ejemplo, puedes responder a un pod que no supere una comprobación de cumplimiento utilizando el estado de cumplimiento del pod para desencadenar la acción necesaria para corregir la situación (desencadenar una actualización de la imagen).

Defensa frente a amenazas

La defensa frente a amenazas en un clúster Kubernetes es la capacidad de observar la actividad maliciosa de en el clúster y defenderlo de ella. La actividad maliciosa permite a un adversario obtener acceso no autorizado y manipular o robar datos de un clúster Kubernetes. La actividad maliciosa puede darse de muchas formas, como aprovechar una configuración insegura o explotar una vulnerabilidad en el tráfico o el código de la aplicación.

Cuando construyas tu estrategia de defensa contra amenazas, debes tener en cuenta tanto la detección como la prevención de intrusiones. La clave de la detección de intrusiones es la observabilidad; necesitas revisar los datos recopilados para buscar amenazas conocidas. En una implementación de Kubernetes, la recopilación de datos es muy difícil debido a la gran cantidad de datos que necesitas inspeccionar. A menudo hemos oído esta pregunta "¿Necesito un clúster de Kubernetes para recopilar datos para defender un clúster de Kubernetes?". La respuesta es "no". Te recomendamos que alinees tu estrategia de observabilidad con la detección de intrusos y aproveches la agregación inteligente para recopilar e inspeccionar datos. Por ejemplo, puedes considerar el uso de una herramienta que agregue los datos como grupos de pods "similares" que hablan entre sí en un puerto de destino y un protocolo determinados, en lugar de utilizar el método tradicional de agregación por la quíntuple (IP de origen, puerto de origen, IP de destino, puerto de destino, protocolo). Este enfoque ayudará a reducir significativamente los datos recopilados sin sacrificar la eficacia. Recuerda que varios pods que ejecuten la misma imagen de contenedor y se desplieguen del mismo modo generarán un tráfico de red idéntico para una transacción. Te preguntarás: "¿Y si sólo está infectada una instancia? ¿Cómo puedo detectarlo?" Es una buena pregunta. Hay algunas formas. Podrías elegir una herramienta que admita el aprendizaje automático basado en diversas métricas recopiladas, como conexiones, bytes y paquetes, para detectar cargas de trabajo anómalas. Otro enfoque es disponer de una herramienta que pueda detectar y comparar IPs y dominios maliciosos conocidos a partir de fuentes de amenazas conocidas como parte de la recopilación, o registrar flujos de red no agregados para el tráfico denegado por política. Estas son técnicas sencillas que te ayudarán a construir una estrategia. Ten en cuenta que las técnicas de defensa contra amenazas evolucionan, y necesitarás un equipo de investigación de seguridad que trabaje contigo para ayudarte a comprender tu aplicación y construir un modelo de amenazas para aplicar tu estrategia de defensa contra amenazas.

Observabilidad

La observabilidad es muy útil para el monitoreo y la seguridad de un sistema distribuido como Kubernetes. Kubernetes abstrae muchos detalles, y para monitorizar un sistema como éste, no puedes recopilar y monitorizar de forma independiente métricas individuales (como un único flujo de red, un evento de creación/destrucción de un pod o un pico de CPU en un nodo). Lo que se necesita es una forma de monitorizar estas métricas en el contexto de Kubernetes. Por ejemplo, un pod asociado a un servicio o a una implementación se reinicia y se ejecuta como un binario diferente en comparación con sus compañeros, o una actividad del pod (red, sistema de archivos, llamadas al sistema del núcleo) es diferente de la de otros pods de la implementación. Esto se vuelve aún más complejo cuando consideras una aplicación que comprende varios servicios (microservicios) que a su vez están respaldados por varios pods.

La observabilidad es útil para la resolución de problemas y el monitoreo de la seguridad de las cargas de trabajo en Kubernetes. Por ejemplo, la observabilidad en el contexto de un servicio en Kubernetes te permitirá hacer lo siguiente:

• Visualiza tu clúster Kubernetes como un gráfico de servicios, que muestra cómo se asocian los pods con los servicios y los flujos de comunicación entre servicios

• Superponer la aplicación (Capa 7) y el tráfico de red (Capa 3/Capa 4) en el gráfico de servicios como capas separadas que te permitirán determinar fácilmente los patrones de tráfico y la carga de tráfico de las aplicaciones y de la red subyacente

• Visualiza los metadatos del nodo en el que está implementado un pod (por ejemplo, CPU, memoria o detalles del SO anfitrión).

• Ver métricas relacionadas con el funcionamiento de un pod, la carga de tráfico, la latencia de la aplicación (por ejemplo, la duración HTTP), la latencia de la red (tiempo de ida y vuelta de la red) o el funcionamiento del pod (por ejemplo, políticas RBAC, cuentas de servicio o reinicios de contenedores)

• Ver la actividad DNS (códigos de respuesta DNS, latencia, carga) de un servicio determinado (pods que respaldan el servicio)

• Rastrear una transacción de usuario que necesita comunicación a través de múltiples servicios; esto también se conoce como rastreo distribuido

• Ver la comunicación en red de un determinado servicio a entidades externas

• Visualiza los registros de actividad de Kubernetes (por ejemplo, registros de auditoría) de los pods y recursos asociados a un servicio determinado.

Cubriremos los detalles de la observabilidad y ejemplos de cómo puede ayudar a la seguridad en capítulos posteriores. Para este debate, haremos una breve descripción de cómo puedes utilizar la observabilidad como parte de tu estrategia de seguridad.

Visibilidad del tráfico de red

Como ya se ha dicho, se necesita una solución que proporcione flujos de red agregados a nivel de servicio con contexto como espacios de nombres, etiquetas, cuentas de servicio o políticas de red, para monitorizar adecuadamente la actividad y los controles de acceso aplicados al clúster. Por ejemplo, hay una diferencia significativa entre informar de que IP1 se comunicó con IP2 a través del puerto 8080 e informar de que pods etiquetados como "frontend" se comunicaron con pods etiquetados como "backend" en determinados puertos o patrones de tráfico entre implementaciones de pods en un clúster Kubernetes. Estos informes te permitirán revisar la comunicación desde entidades externas y aplicar alimentaciones de amenazas basadas en direcciones IP para detectar actividad desde direcciones IP maliciosas conocidas o incluso tráfico desde ubicaciones geográficas inesperadas. Cubriremos los detalles de estos conceptos en el Capítulo 11.

Registros de actividad DNS

El Sistema de Nombres de Dominio (DNS) es un sistema utilizado para traducir los nombres de dominio en direcciones IP. En tu clúster Kubernetes, es fundamental revisar los registros de actividad DNS para detectar actividad inesperada, por ejemplo consultas a dominios maliciosos conocidos, códigos de respuesta DNS como NXDOMAIN, y aumentos inesperados de bytes y paquetes en las consultas DNS. Trataremos en detalle estos conceptos en el Capítulo 11.

Visibilidad del tráfico de aplicaciones

Te recomendamos que revises los flujos de tráfico de la aplicación en busca de actividad sospechosa en , como códigos de respuesta inesperados y cabeceras HTTP maliciosas raras o conocidas (agente de usuario, parámetros de consulta). HTTP es el protocolo más utilizado en las Implementaciones de Kubernetes, por lo que es importante trabajar con tu equipo de investigación de seguridad para monitorizar el tráfico HTTP en busca de tráfico malicioso. En caso de que utilices otros protocolos de aplicación (por ejemplo, Kafka, MySQL), también tienes que hacer lo mismo con ellos.

Registros de actividad de Kubernetes

Además de los registros de actividad de la red, también debes monitorizar los registros de actividad de Kubernetes para detectar actividades maliciosas. Por ejemplo, revisa los registros de acceso denegado para el acceso a recursos y la creación/modificación de cuentas de servicio. Revisa los registros de creación/modificación de espacios de nombres para detectar actividad inesperada. Y revisa los registros de auditoría de Kubernetes que registran las peticiones a la API de Kubernetes.

Aprendizaje automático/detección de anomalías

El aprendizaje automático es una técnica en la que un sistema es capaz de deducir patrones a partir de datos durante un periodo de tiempo. El resultado es un modelo de aprendizaje automático, que puede utilizarse para hacer predicciones y detectar desviaciones en datos reales basándose en la predicción. Te recomendamos que consideres la posibilidad de aplicar la detección de anomalías basada en el aprendizaje automático a varias métricas para detectar actividades extrañas. Una forma sencilla y eficaz es aplicar una técnica de aprendizaje automático conocida como baselining a métricas individuales. De este modo, no tienes que preocuparte de aplicar reglas y umbrales a cada métrica; el sistema lo hace por ti e informa de las desviaciones como anomalías. La aplicación de técnicas de aprendizaje automático al tráfico de red es un área relativamente nueva y está ganando adeptos entre los equipos de seguridad. Trataremos este tema en detalle en el Capítulo 6.

Hay muchas soluciones que puedes elegir para tu estrategia de observabilidad para Kubernetes (Datadog, Calico Enterprise, soluciones basadas en proveedores en la nube de Google, AWS, Azure).

Marcos de seguridad

Por último, queremos darte a conocer los marcos de seguridad que proporcionan al sector una metodología y una terminología comunes para las buenas prácticas de seguridad. Los marcos de seguridad son una forma estupenda de comprender las técnicas de ataque y las buenas prácticas para defenderte y mitigar los ataques. Deberías utilizarlos para construir y validar tu estrategia de seguridad. Ten en cuenta que estos marcos pueden no ser específicos de Kubernetes, pero proporcionan información sobre las técnicas utilizadas por los adversarios en los ataques, y los investigadores de seguridad tendrán que revisarlos y ver si son relevantes para Kubernetes. Revisaremos dos marcos bien conocidos: Mitre y Threat Matrix para Kubernetes.

MITRE

MITRE es una base de conocimientos sobre tácticas y técnicas de los adversarios basada en observaciones reales de ciberataques. La Matriz ATT&CK® de MITRE para la Empresa es útil porque proporciona las tácticas y técnicas categorizadas para cada etapa de la cadena asesina de la ciberseguridad. La cadena asesina es una descripción de las etapas de un ciberataque y es útil para construir una defensa eficaz contra un ataque. MITRE también proporciona una matriz de ataque adaptada a entornos en la nube como AWS, Google Cloud y Microsoft Azure.

La Figura 1-3 describe la Matriz ATT&CK® de MITRE para AWS. Te recomendamos que revises cada una de las etapas descritas en la matriz de ataques a medida que construyas tu modelo de amenazas para proteger tu clúster de Kubernetes.

Figura 1-3. Matriz de ataque para entornos en la nube en AWS

Matriz de amenazas para Kubernetes

El otro marco es una matriz de amenazas que es una aplicación específica para Kubernetes de la matriz de ataques genérica de MITRE. Fue publicada por el equipo de Microsoft basándose en investigaciones de seguridad y ataques del mundo real. Se trata de otro excelente recurso que puedes utilizar para construir y validar tu estrategia de seguridad.

La Figura 1-4 muestra las etapas relevantes para tu clúster Kubernetes. Se corresponden con las distintas etapas que hemos tratado en este capítulo. Por ejemplo, debes tener en cuenta las imágenes comprometidas en el registro en la etapa de acceso inicial, los recursos de la nube de acceso en la etapa de escalada de privilegios, y la red interna del clúster en la etapa de movimiento lateral para la seguridad de construcción, implementación y tiempo de ejecución, respectivamente.

Figura 1-4. Matriz de amenazas para Kubernetes

Seguridad y observabilidad

En un entorno dinámico como Kubernetes, se puede lograr una implementación segura de tus aplicaciones pensando conjuntamente en la seguridad y la observabilidad. Por ejemplo, necesitas "observar" tu clúster para encontrar la forma óptima de implementar controles para asegurar el clúster. Kubernetes como motor de orquestación tiene una fuerte adopción debido a que es de naturaleza declarativa, lo que permite a los usuarios especificar resultados de alto nivel. Kubernetes también tiene capacidades integradas para garantizar que tu clúster funciona según las especificaciones. Para ello, monitorea los distintos atributos y toma medidas (por ejemplo, el reinicio de un pod) si el atributo se desvía del valor especificado durante un periodo de tiempo. Estos aspectos de Kubernetes dificultan la implementación de la visibilidad y los controles necesarios para asegurar un clúster. Los controles que implementes deben estar alineados con las operaciones de Kubernetes. Por tanto, antes de pensar en añadir controles a Kubernetes, es importante comprender el contexto: por ejemplo, no puedes aislar un pod aplicando una política que no le permita comunicarse con nada más. Kubernetes detectará que el pod no puede comunicarse con los demás elementos (por ejemplo, el servidor API), determinará que el pod no funciona según lo especificado, y lo reiniciará y pondrá en marcha en otro lugar del clúster.

Lo que tienes que hacer es, en primer lugar, entender cómo funciona el pod y comprender cuál es su funcionamiento esperado y, a continuación, aplicar controles o detectar sucesos inesperados. Después, determinas si el suceso inesperado es un problema de operaciones o de seguridad y, a continuación, aplicas la corrección necesaria. Para ello, la observabilidad y la seguridad van de la mano: Observas para comprender lo que se espera y aplicas controles para garantizar el funcionamiento esperado, luego observas para detectar sucesos inesperados y analizarlos, y después añades los controles necesarios para remediar cualquier problema debido al suceso. Por tanto, necesitas un enfoque holístico de la seguridad y la observabilidad cuando pienses en asegurar tus clusters.

Conclusión

A estas alturas ya deberías tener una visión general de alto nivel de lo que implican la seguridad y la observabilidad de Kubernetes. Son los conceptos fundamentales que sustentan todo este libro. En pocas palabras:

• La seguridad para Kubernetes es muy diferente de la seguridad tradicional y requiere un enfoque holístico de la seguridad y la observabilidad en todas las fases de la implementación de la carga de trabajo: construcción, despliegue y tiempo de ejecución.

• Kubernetes es declarativo y abstrae los detalles de las operaciones de las cargas de trabajo, lo que significa que éstas pueden ejecutarse en cualquier lugar de una red de nodos. Además, las cargas de trabajo pueden ser efímeras, destruyéndose y volviéndose a crear en un nodo diferente. Asegurar un sistema distribuido declarativo de este tipo requiere que pienses en la seguridad en todas las etapas.

• Esperamos que comprendas la importancia de la colaboración entre los equipos de aplicaciones, plataformas y seguridad a la hora de diseñar e implantar un enfoque holístico de la seguridad.

• MITRE y la Matriz de Amenazas para Kubernetes son dos marcos de seguridad ampliamente adoptados por los equipos de seguridad.

Es importante que asimiles todo esto a la vez, porque una estrategia de seguridad y observabilidad exitosa es una estrategia holística. En el próximo capítulo, trataremos la seguridad de la infraestructura.